Hi Ferenc, Thanks for kicking off the discussio for this. We'll continuously add new built-in PTFs and some guidelines around this will definitely be useful for future discussions.
I agree your first and last point. Regarding the second one, I'd be fine with both optional parameters being added with or without a discussion. Common sense is required depending on the change, and a short discussion is always the safer option, as we're doing with TO_CHANGELOG. New required parameters ones are breaking changes, thus fall into the backwards-incompatible changes bucket and require a mailing list discussion. Kind regards, Gustavo On Thu, 1 Oct 2026 at 15:28, Ferenc Csaky via dev <[email protected]> wrote: > Hello devs, > > While reviewing a proposed change to TO_CHANGELOG [1], we ran into a > broader > process question: what level of community discussion should we require for > adjustments to the built-in process table functions (PTFs) after their > original > FLIP has been approved? > > The specific change is additive and backward-compatible, but it would add a > new user-facing parameter. The question is therefore not limited to this > function: as we gain operational experience with the first built-in PTFs, > we > should have a shared and predictable rule for similar changes. > > My initial thought is: > > - Implementation changes, documentation fixes, and bug fixes that do not > change the public API or its intended semantics can proceed through the > normal PR review process. > - A user-visible API or semantic change to a built-in PTF, including an > additive optional parameter, should at least have a short mailing list > discussion. > - Backward-incompatible changes, or changes that revise a decision central > to > the original FLIP should follow the normal FLIP process. > > The TO_CHANGELOG design itself is intentionally being discussed separately. > > Best, > Ferenc > > [1] https://github.com/apache/flink/pull/29102 >
