Additionally, I propose allocating a brief 5-10 minute segment during each Iceberg community sync. During this time, attendees can highlight any pull requests needing attention. In cases where a pull request has become stagnant due to a lack of reviews, committers can step forward to offer assistance by conducting reviews and aiding in its resolution.
- Ajantha On Wed, Mar 27, 2024 at 12:06 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > By the way, I worked on a Python program that generate a report containing: > - GitHub Issues > - Created since more than 6 months > - Without assignee > - Without activity (comment) since more than 7 days > - GitHub PRs > - Created since more than 6 months > - Without reviewer > - With a single reviewer > - Without activity (comment, etc) since more than 7 days > > The report is a HTML page. I will send it on this thread today or > tomorrow for review. > > For now, I only generate the HTML (locally on the machine), but it > would be possible to publish on website or automatically (cron) send > on the dev mailing list. > > Regards > JB > > On Wed, Mar 27, 2024 at 6:57 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > Adding a group of people as reviewers doesn't block others from help > > and review (and it doesn't change what we do now). I don't see how > > it's different to today, just having default people reviewing, adding > > new people. > > Actually, we clearly have today a bunch of PRs stale just due to lack > > of reviewers. From a community standard, I'm also concerned that a lot > > of PR is waiting for review from the same people: that is a concern > > for community engagement. If we have 3 persons that should > > review/approve 90% of the PRs, it doesn't scale, it doesn't engage the > > community, other committers/PMC members might be feeling "untrusted". > > > > So the idea is actually to grow the community: the group of reviewers > > can invite other people to review (having default reviewers on some > > modules doesn't block adding others). We have several examples of > > Apache projects where it works fine (Apache Beam is an example, we > > increased the community engagement thanks to feedback from reviewer > > pretty quickly instead of stale for a while and contributors give up > > due to no response). > > > > Anyway, I propose to update my proposal this way: > > 1. I update the stale PR periodical reminder (every week) > > 2. I don't add reviewers yml, but if a PR doesn't have reviewer after > > a week, I send a report on the dev mailing list listing all stale and > > no review started PRs) > > > > Regards > > JB > > > > On Tue, Mar 26, 2024 at 5:03 PM Ryan Blue <b...@tabular.io> wrote: > > > > > > Sorry, I'm a strong -1 for having owners or standard reviewers. > > > > > > In this community, we've always taken the stance that anyone should be > able to jump in and help. Having assigned owners may seem like a good idea, > but it actually prevents other people from volunteering and getting > involved. This is also why we don't assign issues to individuals -- they > often don't end up submitting a PR and it prevents other people from > contributing. Having an assigned owner gives the impression that the > responsibility is on a particular individual, making other people that are > capable of reviewing not pay attention. I think this will slow down the > community and I don't think it is a good idea. > > > > > > Ryan > > > > > > On Tue, Mar 26, 2024 at 6:36 AM Ajantha Bhat <ajanthab...@gmail.com> > wrote: > > >> > > >> +1 for having multiple PR review owners per module/label. > > >> > > >> Having module owners can accelerate PR processing. For instance, I'm > awaiting feedback on a Spark action for computing partition stats ( > https://github.com/apache/iceberg/pull/9437). Currently, only Anton is > reviewing, which may cause delays if he's occupied. In my opinion, having > multiple module owners would enable developers to seek feedback more > efficiently. > > >> > > >> - Ajantha > > >> > > >> On Thu, Mar 21, 2024 at 11:11 PM Jean-Baptiste Onofré < > j...@nanthrax.net> wrote: > > >>> > > >>> 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. > > > > > > > > > > > > -- > > > Ryan Blue > > > Tabular >
