Thanks Xintong for initiating and sharing the discussion! The agreement described in the summary looks pretty good. In particular, it is great to know that ASF already has guidance requiring "voter must provide with the veto a technical justification showing why the change is bad". This is exactly what we need. This is an important step towards making our FLIP discussion process more collaborative and productive :)
While I agree it is important to work on trust, it is probably still useful to document the agreement described above in the wiki, so that new Flink contributors can follow this guidance easily rather than having to read this email thread. For example, we can probably have something like this <https://cwiki.apache.org/confluence/display/FLINK/Merging+Pull+Requests> guideline that specifies what MUST be done and what SHOULD (preferred but not required) be done to merge PR. The use of MUST vs. SHOULD could help us achieve a balance between trust and rules. I guess the guidance can include something like this: - Voter *must* provide with the veto a technical justification showing why the change is bad. - The discussion thread *must* last for at least 5 days (excluding weekends and national holidays). - The voting thread *must* last for at least 3 days (excluding weekends and national holidays). - The discussion thread *should* allow 5 days for the reviewer to reply. I am wondering what other contributors think regarding putting the agreement in the wiki. Cheers, Dong On Sat, Jan 28, 2023 at 12:26 PM 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 >
