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. >
