Thanks all for the valuable information. It is a great step to make the FLIP running more smoothly.
I'd like to share two additional suggestions: 1. Veto with care - Voter should present her-/him-self and give a veto with her/his own technical justification. No veto is allowed only based on someone else's opinion. 2. Vacation or holiday seasons - It is a personal choice to join a discussion and voting process during the vacation and holiday season. The focus should be on the FLIP process to avoid blocking it. If the voter decides to get involved, especially with a veto, then she/he should be responsive and responsible during the vacation time. Or, she/he could enjoy the vacation, stay on the sideline and trust others who participate. All improvements wrt the FLIP process should be formally documented and will be referenced if any FLIP got blocking issues in the future. Best regards, Jing On Mon, Jan 30, 2023 at 10:20 AM Matthias Pohl <matthias.p...@aiven.io.invalid> wrote: > Thanks Xintong for summarizing the PMC discussion here. I agree that > working on trust instead of imposing more rules is the right thing to do. > But I see Dong's point on documenting such an agreement in some way to give > guidance to new contributors. > > One thing that I think might be helpful to include is holiday. When and for > how long someone decides to go on holiday is an individual decision. > Therefore, dealing with it on a per-case basis and being transparent about > it in FLIP discussions is reasonable and should be encouraged. > > That said, there are major holiday seasons. I guess, for the Flink > community, Chinese New Year and Christmas (but maybe also the summer > months) are times where it's more likely for people to plan their vacation. > I'm not proposing to disallow FLIP discussions during that time but adding > a reminder that these vacation periods exist. ...if we decide to move this > into some form of documentation. Just to raise awareness and make FLIP > creators be considerative of these times of the year when planning the > work. > > Of course, this should be formulated in an inclusive manner since there are > also contributors from other parts of the world. > > Best, > Matthias > > On Sat, Jan 28, 2023 at 10:26 AM Dong Lin <lindon...@gmail.com> wrote: > > > 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 > > > > > >
