Hi devs, Recently, a discussion about how to drive FLIPs towards consensus has taken place on the private@ mailing list. While many PMC members have already shared their opinions, we believe for this topic the opinions of other committers / contributors are equally important. Therefore, we are moving the discussion to the dev@ mailing list for a wilder involvement.
### Background Flink Improvement Proposal (FLIP) [1], the process for proposing, discussing, reviewing and voting on major changes to Flink, plays an important role in driving the project forward. According to the process, *consensus*[2] is required for any proposal to be accepted. This means objections from any single committer can block the process. It has been observed many times that a FLIP is long blocked on a disapproving committer. In most cases, this is necessary for addressing technical concerns. However, there are also cases that after raising concerns the committer becomes unresponsive (due to other works, personal vacation plans, etc.), leaving the FLIP blocked for an unnecessarily long time. The purpose of this discussion is to come up with some conventions on preventing FLIPs from being long blocked on unresponsive reviewers. ### Summary of the previous discussion on private@ - Most people agree that the progress of a FLIP should not be long blocked on an unresponsive reviewer. When a reviewer blocks the progress of a FLIP, he/she should be responsive to the subsequent replies, or at least provide a reasonable estimated time of response. - As for how long we should wait for the responses, there’s a tendency towards relying on the judgement of individuals while also having a typically recommended time (1 week). - Committers should use their veto rights with care. Per the ASF policy [3], vetos must be provided with a technical justification showing why the change is bad. They should not be used for simply blocking the process so the voter has more time to catch up. - We’d also encourage the FLIP proposers to actively reach out to the interested parties (e.g., previous contributors of the relevant part) early. It helps expose and address the potential concerns early and also leaves more time for other parties to respond while the proposer works on the FLIP. - We’d like to work on trust rather than heavy rules and processes. All above, if agreed, should be conventions among the community. We would not formally change the FLIP process. Looking forward to your opinions. Best, Xintong [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals [2] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Approvals [3] https://www.apache.org/foundation/voting.html#Veto
