That seems like a good start. I do agree there needs to be a better way to promote engagement among other members.
Perhaps I can do my next LinkedIn show describing the review process, how Apache works, how to get started, and what NOT to do when submitting a PR. This will likely translate into a good list and set of pages for the docs. Or an update to some existing ones. Would you like to join me for an episode and perhaps we can bring on a PMC member or two of anyone is interested? On Thu, Apr 4, 2024 at 8:14 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Brian, > > Yeah, I agree with your points. That's why I would like to create a PR > as a discussion base (that we can update thanks to everyone's > comments). > > 1. I think we already have a consensus about "stale issue/PR" reminder. > 2. The concern is more about "assign/reviewer list". Rethinking this > point, actually, we can address this with the 1: if we have reminder > in stale PR, then someone can engage. > > So, I propose to start with 1, and experiment/see how it works. > > Regards > JB > > On Thu, Apr 4, 2024 at 1:26 PM Brian Olsen <bitsondata...@gmail.com> > wrote: > > > > I think you both (JB and Ryan) have valid points. > > > > JB there absolutely is a need to address the scalability issue and we > need to come up with a solution. I doubt there’s any disagreement that > rising stale issues in the project should be ignored. > > > > Ryan’s concern also has merit from a different angle that could lead to > similar outcomes (stale PRs) with the current proposed solution, as > ownership while establishing and growing responsibility, could lead to > fiefdoms. > > > > There’s clearly some support for a solution and so submitting the > proposal as a more tangible PR is a good idea. At that point we can further > revise this solution to account for both concerns. This also would be a > good one to discuss in realtime at a community sync. > > > > Thanks for the edited here! > > > > Bits > > > > On Thu, Apr 4, 2024 at 4:12 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> > >> Anyway, I'm preparing a PR to illustrate the proposal. > >> > >> Regards > >> JB > >> > >> On Thu, Apr 4, 2024 at 10:59 AM Ajantha Bhat <ajanthab...@gmail.com> > wrote: > >> > > >> > 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 >
