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
