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.
