Thanks Becket, that makes sense. One follow-up question: for cases where someone drafts a proposal in a Google Doc with a FLIP-XXX title (following the wiki template <https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-CreateyourOwnFLIP>), but hasn’t had a number formally assigned yet and hasn’t copied it to the FLIP Confluence page - would we treat those as FLIPs needing status tracking, or are they still considered ad-hoc discussions?
Best, Weiqing On Sun, Jul 13, 2025 at 11:36 PM Becket Qin <becket....@gmail.com> wrote: > Thanks for the comment Weiqing. > > The example you raised was actually a FLIP case. There was a FLIP doc and > discussion thread. Regarding ad-hoc disussions, at this point we do not > have process to track the ad-hoc discussion mail threads without FLIPs. We > may not need such a process as the overhead might be high. FLIPs are a > little different because the author need to spend significant more time in > writing the proposal doc and we have defined status for FLIPs (DRAFT, UNDER > DISCUSSION, ACCEPTED, RELEASED, etc). So, we need to properly maintain > their status to avoid confusion. In practice, if someone is serious about > an ad-hoc disucssion, maybe they will write a FLIP or create a Jira. > > That said, I agree that similar etiquette can be applied to ad-hoc > discussions. Although we do not have formal process for ad-hoc discussions, > the emails can still be searched via the mail archive. So, one can still > search and see if anything similar has been discussed before. This is > encouraged but not required. People can also just send email for any > project related ideas / questions without searching past emails. > > Best, > > Jiangjie (Becket) Qin > > > > > > > > On Tue, Jul 8, 2025 at 11:34 PM Weiqing Yang <yangweiqing...@gmail.com> > wrote: > > > +1 on the overall proposal. I think these guidelines make sense for > > reducing confusion and respecting contributors’ work. > > > > One scenario I'd also like to discuss is when there's a discussion thread > > with a proposal document but no FLIP created yet - so it's still in the > > early discussion phase. In practice, this can happen often (for example, > > *this > > thread <https://lists.apache.org/thread/pg8k70lxmxnvrmft2vs57cj6hxgp4hh8 > > >*), > > and these “proto-FLIPs” can also become dormant. > > > > Perhaps we can adopt a similar approach: > > > > - > > > > If there’s been no activity on such a discussion for a long time (e.g. > > 3–6 months), and the proposal still makes sense, committers or > > contributors > > (anyone interested in the proposal) can follow up to see if the author > > plans to formalize it as a FLIP. > > - > > > > If there’s no response after a ping, we could consider the thread > > “closed,” and others can create a new thread to continue the topic if > > they’re interested. Or, if there has been offline discussion with the > > author to clarify the proposal’s status - and they don’t want to > > continue > > the follow-up - someone else can update the old discussion thread > > accordingly. > > > > That way, future contributors know it’s not an active proposal but can > > still revive it if needed. This might help keep the mailing list cleaner > > and avoid repeated “Did this go anywhere?” questions in the future. > > > > Best, > > Weiqing > > > > On Tue, May 27, 2025 at 8:57 PM Becket Qin <becket....@gmail.com> wrote: > > > > > Hi Folks, > > > > > > In a recent discussion of reviving FLIP-313, I realized that we do not > > have > > > an established convention in handling dormant FLIPs (FLIPs without > > > interaction for months, even years) or FLIPs addressing the same > issues. > > > > > > To give a more concrete context, let's take a look at the example case > of > > > FLIP-313 and FLIP-498. > > > May 23, 2023 - the discussion of FLIP-313 > > > <https://lists.apache.org/thread/7vk1799ryvrz4lsm5254q64ctm89mx2l> was > > > started. > > > Jun 13, 2023 - the vote thread > > > <https://lists.apache.org/thread/7g5n2vshosom2dj9bp7x4n01okrnx4xx> was > > > started. However, somehow there was no vote casted. And there have been > > no > > > activities on that FLIP since then. > > > Jan 2, 2025 - the discussion of FLIP-498 > > > <https://lists.apache.org/thread/kgbpj96b4lw1c39gq5p0j0t8b1ssm368> was > > > started. It tries to address the exact same problem of FLIP-313, with a > > > difference that it proposes config-based options instead of hint-based > > > options. > > > Jan 31, 2025 - the vote of FLIP-498 > > > <https://lists.apache.org/thread/hckpyl24oqdqvfcrhfkjx2j37dtbyfg7> was > > > concluded with acceptance. > > > > > > In a retrospective, I feel that there are a few things worth > discussing, > > > and my thoughts are following. > > > > > > *1. What we should do if a vote is open for long (e.g. over a month) > > > without conclusion (accepted or rejected)? * > > > I think we can > > > - treat that vote thread as discarded. > > > - The FLIP itself will be back to the under discussion status. > > > > > > Periodically, we (the committers) can sweep the dormant FLIPs and see > if > > > they should be abandoned. Note that not all the dormant FLIPs should be > > > abandoned. If the proposal still makes sense from technical > perspective, > > or > > > the targeted issue is still valid, we can keep the FLIP open until > > someone > > > else picks it up. The decision is still based on the case by case > > > judgement. For example, in this particular case, FLIP-313 seems still > > > relevant. Hence, we may want to keep it open. > > > > > > If we decide to abandon a dormant FLIP, as a courtesy, we should reply > in > > > the discussion thread to ping the contributor. If there is no response > > > after a week, we can abandon the FLIP. An abandoned FLIP should have > its > > > status properly updated, so that there is no confusion. > > > > > > *2. What should we do when a new FLIP overlaps with a dormant open > FLIP?* > > > If both FLIPs are targeting the same problem. Preferably, we should > > revive > > > the earlier FLIP, and close the new one as duplicate. This helps keep a > > > serialized history of the discussion and avoid the confusion caused by > > > multiple FLIPs with the same targeted issue. > > > In case we found there is a significant difference between the new FLIP > > and > > > the old one, we can let the new FLIP subsume the old FLIP. If so, > > > - again as a courtesy, we should ping the contributor in the > discussion > > > thread of the old FLIP. > > > - include the subsumption as a part of the new FLIP vote, and update > > the > > > status of the old FLIP accordingly. For example, in this particular > case, > > > if FLIP-313 is subsumed by FLIP-498, we need to update the FLIP-313 > > status > > > to reflect that when FLIP-498 passes. > > > > > > > > > The goal of the proposed convention is to make sure 1) we respect the > > work > > > from all the Flink contributors, and 2) avoid confusions on the FLIP > > status > > > as much as possible. > > > Once we have the convention agreed, we can add them to the FLIP process > > > page. > > > > > > Thoughts and feedback are welcome. > > > > > > Thanks, > > > > > > Jiangjie (Becket) Qin > > > > > >
