Hi Dmitri It's not a problem to have several people working on the same feature.
By duplicate PRs, I mean that you open a PR, where you get comments, changes requested, etc. Then, you close this PR to open a new one (on the same topic). So, I mean by a single person. I'm more in favor of refactoring an existing PR, instead of closing PR #1 to open PR #2 with the refactoring. On some projects, I saw contributors closing the PR #1, creating PR #2 just to get approval and merge (loosing the discussion on #1). Regards JB On Wed, Jan 22, 2025 at 6:30 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > > 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 > >
