Thank Xintong for starting the discussion in PMC and bringing the summary here.
The summary looks good to me. Unresponsive reviewing has happened numerous times in the previous FLIPs. I think the conventions are very valuable for the community to move forward efficiently and avoid potential conflicts in the future. Best, Jark On Sat, 28 Jan 2023 at 12:26, Xintong Song <tonysong...@gmail.com> wrote: > 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 >
