Hi Fokko I think combining Dan's proposal about "proposal process" and this proposal about "PR flows" would be helpful for the project (to track the proposals and avoid "stale" PRs/proposals).
If PMC members are OK, I'm ready to help to set this up :) Thanks Regards JB On Wed, Mar 20, 2024 at 12:27 PM Fokko Driesprong <fo...@apache.org> wrote: > > Hey everyone, > > This is a gentle bump from my end on this thread since I like the idea. > Several people have already approved Dan's PR about formalizing the proposal > process. Are there any questions or concerns from the PMC before adopting > this? > > Kind regards, > Fokko Driesprong > > Op wo 13 mrt 2024 om 13:17 schreef Renjie Liu <liurenjie2...@gmail.com>: >> >> Hi, JB: >> >> Your proposal looks great to me. We should definitely have a vote for a >> proposal impacting the spec, and the model is great. >> >> On Tue, Mar 12, 2024 at 10:55 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >>> >>> Hi >>> >>> I think a vote would be necessary only if we don't have consensus on a >>> proposal. If anyone is OK with the proposal (no clear "concern" in the >>> doc and/or the GitHub issue), a vote is not required. >>> That said, any proposal impacting a spec should be voted (as part of >>> the spec proposal). >>> >>> I think it's fair to identify a proposal vote as a "code modification" vote. >>> It means that it follows this model: a negative vote constitutes a >>> veto , which the voting group (generally the PMC of a project) cannot >>> override. Again, this model may be modified by a lazy consensus >>> declaration when the request for a vote is raised, but the full-stop >>> nature of a negative vote does not change. Under normal (non-lazy >>> consensus) conditions, the proposal requires three positive votes and >>> no negative votes in order to pass; if it fails to garner the >>> requisite amount of support, it doesn't. Then the proposer either >>> withdraws the proposal or modifies the code and resubmits it, or the >>> proposal simply languishes as an open issue until someone gets around >>> to removing it. >>> >>> We can link to https://www.apache.org/foundation/voting.html. >>> >>> Regards >>> JB >>> >>> On Tue, Mar 12, 2024 at 2:21 AM Renjie Liu <liurenjie2...@gmail.com> wrote: >>> > >>> > Hi, Daniel: >>> > >>> > Thanks for this summary. >>> > >>> > I think one thing missing is that do we need a vote for the proposal to >>> > be accepted or rejected? If required, what should the voting process be? >>> > >>> > On Tue, Mar 12, 2024 at 9:04 AM Daniel Weeks <dwe...@apache.org> wrote: >>> >> >>> >> Hey everyone, I synced up with JB about the proposal process and wanted >>> >> to see if we could make some initial progress. >>> >> >>> >> Based on some of the earlier discussions, we want to leverage as much of >>> >> the informal process as possible, but improve discoverability and a >>> >> little structure. This probably means using github for tracking, google >>> >> docs where possible for the early proposal implementation comments, and >>> >> the dev list for discussion threads, awareness and voting. >>> >> >>> >> That said, I propose we adopt the following: >>> >> >>> >> 1. A simple issue template for initiating a proposal and applying a >>> >> 'proposal' label to the issue >>> >> 2. Use a github search link to document current proposals (based on the >>> >> 'proposal' label) >>> >> 3. Continue using google docs for proposals documentation/comments >>> >> (referenced from the github issue) >>> >> 4. Continue to create DISCUSS threads on the dev list for communication >>> >> 4. Backfill current proposals by creating issues for them >>> >> >>> >> I've created this PR to capture the initial template and docs. >>> >> >>> >> I think we want to introduce this with as little overhead as possible. >>> >> Please follow up with questions/comments so we can close this out. >>> >> >>> >> Thanks, >>> >> Dan >>> >> >>> >> >>> >> On Sun, Mar 10, 2024 at 11:30 PM Jean-Baptiste Onofré >>> >> <j...@nanthrax.net> wrote: >>> >>> >>> >>> Hi Manu >>> >>> >>> >>> Yup, it's on my TODO. Thanks for the reminder, I will be back on this >>> >>> one this week :) >>> >>> >>> >>> Regards >>> >>> JB >>> >>> >>> >>> On Mon, Mar 11, 2024 at 4:07 AM Manu Zhang <owenzhang1...@gmail.com> >>> >>> wrote: >>> >>> > >>> >>> > Hi JB, >>> >>> > >>> >>> > Are you still working on this nice proposal? >>> >>> > >>> >>> > Regards, >>> >>> > Manu >>> >>> > >>> >>> > On Thu, Jan 4, 2024 at 3:35 PM Fokko Driesprong <fo...@apache.org> >>> >>> > wrote: >>> >>> >> >>> >>> >> Nice! I fully agree with the abovementioned. I originally set up the >>> >>> >> stalebot for the issues because I noticed that there were many >>> >>> >> issues around old Spark versions that weren't even maintained >>> >>> >> anymore. I feel it is better to either close or take action on an >>> >>> >> issue. For me, it makes sense to extend this to PRs as well. >>> >>> >> >>> >>> >> Same as Amogh said, always feel free to ping me when either a PR or >>> >>> >> issue lingering and you need some eyes on it. >>> >>> >> >>> >>> >> Kind regards, >>> >>> >> Fokko >>> >>> >> >>> >>> >> Op do 4 jan 2024 om 07:42 schreef Jean-Baptiste Onofré >>> >>> >> <j...@nanthrax.net>: >>> >>> >>> >>> >>> >>> Hi >>> >>> >>> >>> >>> >>> That's also the purpose of the reviewers file: having multiple >>> >>> >>> reviewers per tag. >>> >>> >>> >>> >>> >>> Thanks guys for your feedback, I will move forward with the PR :) >>> >>> >>> >>> >>> >>> Regards >>> >>> >>> JB >>> >>> >>> >>> >>> >>> On Thu, Jan 4, 2024 at 6:38 AM Ajantha Bhat <ajanthab...@gmail.com> >>> >>> >>> wrote: >>> >>> >>> > >>> >>> >>> > +1, >>> >>> >>> > >>> >>> >>> > Some of my PRs have been open for a long time and sometimes it >>> >>> >>> > doesn't get the attention it requires. >>> >>> >>> > Notifying both the reviewer and the author can help expedite the >>> >>> >>> > review process and facilitate quicker handling of new >>> >>> >>> > contributions. >>> >>> >>> > I think having more than one committer assigned for PR can also >>> >>> >>> > definitely help in speeding up the process if one of the >>> >>> >>> > committer is busy or on holiday. >>> >>> >>> > >>> >>> >>> > But we also need to think on the next steps. What if we still >>> >>> >>> > don't receive the necessary response even after sending >>> >>> >>> > notifications? >>> >>> >>> > Should we have a slack channel for those PRs to conclude by >>> >>> >>> > discussing (or some guidelines on how to take it further). >>> >>> >>> > >>> >>> >>> > We can have a trial run for some days and see how it goes. >>> >>> >>> > >>> >>> >>> > Thanks, >>> >>> >>> > Ajantha >>> >>> >>> > >>> >>> >>> > On Thu, Jan 4, 2024 at 8:19 AM Amogh Jahagirdar >>> >>> >>> > <am...@tabular.io> wrote: >>> >>> >>> >> >>> >>> >>> >> +1, I think this is a step in the right direction. One other >>> >>> >>> >> consideration I wanted to bring up was dependabot and if there's >>> >>> >>> >> any unique handling we want to do there because I've noticed >>> >>> >>> >> that PRs from dependabot tend to pile up. I think with the >>> >>> >>> >> proposal we won't really need to do anything unique and just >>> >>> >>> >> treat it as a normal PR (it would be a build label with its own >>> >>> >>> >> set of reviewers) and we'll get notified the same way. >>> >>> >>> >> >>> >>> >>> >> I'll also say for reviews (speaking for myself, but I think many >>> >>> >>> >> others probably feel this way as well), always feel free to ping >>> >>> >>> >> on Slack and follow up :) But overall I do like having more of a >>> >>> >>> >> mechanism.
