The discussion has been open for quite some time and there seems not to be more inputs.
Thanks all for the discussion. I have updated the Flink Improvement Proposals wiki page [1] with the discussed conventions. Best, Xintong [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals On Tue, Jan 31, 2023 at 11:15 AM Xintong Song <tonysong...@gmail.com> wrote: > 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 >> > > > >> > > >> > >> >
