Good point, Renjie I believe we've always followed the code modification vote procedure with 3 PMC votes required and no lazy consensus, but we should probably be explicit about that process.
I'll update the docs to reflect that. -Dan On Mon, Mar 11, 2024, 6:23 PM 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 <https://github.com/apache/iceberg/pull/9932> 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. >>> >>
