Hi folks Now that we have the proposal process "merged", I will create the PR about reviewers and update stale job.
I should have the PR tomorrow for review. Thanks ! Regards JB On Thu, Mar 21, 2024 at 9:55 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi Dan > > Yes, I saw you merged it, that's great. > > I will move forward on the "stale bot" stuff. > > Thanks ! > Regards > JB > > On Wed, Mar 20, 2024 at 8:48 PM Daniel Weeks <dwe...@apache.org> wrote: > > > > Hey JB, apologies for combining these two things in the same thread, but we > > got enough eyes on the first PR and I went ahead and merged i > > > > If you want to put together the PR for your proposed changes, we can get > > looking at that. > > > > We'll also need to backfill the existing proposals and update the website > > to have a link to the label. (Will work with you and Bits on that) > > > > Thanks, > > -Dan > > > > > > > > On Wed, Mar 20, 2024 at 10:01 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > >> > >> 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.
