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
