Thanks all for the feedback.
@Dong, I fully agree that we should document the agreements on wiki. However, I'd hesitate about the MUST / SHOULD phrasing. I personally would consider these conventions, except for the one quoted from the ASF policy, as empirical inputs for individual judgements, where MUST / SHOULD might be a bit too strong. @Matthias, Adding a reminder about holiday seasons makes sense to me. I'd suggest to narrow this down to public holidays only, excluding personal vacations. At the moment, I'm not aware of any public holidays other than Christmas and Chinese New Year that need to be noticed in this context. Pardon me for my unfamiliarity with the diverse cultures. And of course we can add other holidays, if proposed, to the list. @Jing, I generally agree with your two suggestions. Actually, I think they are already been implied by the proposed conventions. It might be nice to keep the documented conventions concise. And just to clarify, the proposal here is to provide some suggestions / guidance on how to drive FLIPs towards consensus, rather than formally change / improve the FLIP process. Best, Xintong On Mon, Jan 30, 2023 at 8:16 PM Jing Ge <j...@ververica.com.invalid> wrote: > 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 > > > > > > > > > >
