Hi JB, What do you mean by "No duplicated PRs is allowed (in order to keep history and comments)"?
Maybe a terminology gap on my part :) but what is a "duplicated PR"? Do you mean multiple people working on the same feature? Or people submitting multiple PRs with alternative implementations? How can we practically disallow that? Requesting permission to "work" may be an overkill. I'd suggest identifying conflicting "feature" implementations at review time and then figuring out the sequence of merges that works for all parties. Of course, contributors are encouraged to become familiar with the list of outstanding PRs before making new ones. WDYT? Thanks, Dmitri. On Wed, Jan 22, 2025 at 7:44 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi folks, > > Thanks to your feedback and comments (in PRs, this thread, and the > other one regarding main branch stability), I'm updating the proposal > as follow: > * Changes on public interfaces/extension points (potentially used by > parties) should be discussed and approved on the dev mailing list (a > vote can be used if needed). The discussion on the dev mailing list (a > proposal document can be attached) should happen before any PR/change > * The original author of a code should be tagged in a PR comment > (something like "@author this PR changed a code you are the original > author, can you please take a look ?") as background/context can be > provided and valuable review made. It would be possible to "enforce" > that in the .asf.yaml but it would also need a much more detailed > .github/CODEOWNERS file. So, I propose to do it "explicitly" by the PR > author. > * No duplicated PRs is allowed (in order to keep history and comments) > * All discussions in PRs should be removed before merging (see > https://github.com/apache/polaris/pull/840) > * We wait at least 2 working days to comment/review. It doesn't mean > that the review should be completed in 3 working days, it simply means > that you have time to comment and start discussion. If there's no > comment/concern after 3 working days, we can consider a lazy consensus > and merge the PR (if approved). > * If it's hard to find a consensus on a PR, the discussion should be > bring on the dev mailing list to be discussion globally with the > community > > Thoughts ? > > If we agree on the proposal, I will create a PR to update the > Contributing Guide (to be clear for any contributor). > > NB: in order to facilitate PR "triage", I created > https://github.com/apache/polaris/pull/839 to run renovate only once a > day and add the "renovatebot" label to easily filter the PRs/emails. > > Regards > JB > > JB > > On Fri, Jan 17, 2025 at 5:55 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > Hi folks, > > > > It's great to see soooo much activity on Apache Polaris right now ! > > > > By experience, this high activity can introduce frustration in the > > community because contributors might be "lost" or have the feeling of > > missing important changes/proposals. > > > > I propose some good practices we could use to improve our > > collaboration and facilitate team work: > > 1. GH Issues & PRs should be descriptive and accurate, especially the > > description should describe a minimum the purpose and the labels > > should be meaningful (a bug is a breaking change, an improvement is a > > change on existing, etc). > > 2. We should avoid duplicating PRs (like creating a new PR and closing > > another one on the same topic), else we lose the history and comments. > > 3. All discussions in a PR should be resolved before merging, > > 4. I propose to wait 2 working days before merging PR to give a chance > > to contributors to take a look. > > 5. It's good to take the time for discussion in PR. If you think this > > discussion needs to move on the dev mailing list (to include the whole > > community) that's also fine. > > > > Regarding 3 and 4, I think I can update the .asf.yaml to enforce that. > > > > Thoughts ? > > > > Regards > > JB >
