Hi JB This is a great topic and worth spending time on. Naturally, we want to move fast and get things out quickly, but it’s also important that everyone has a chance to weigh in on changes. This is easy to miss when we’re spread across so many time zones and some groups are working while others are sleeping.
I agree with all points, with the caveat that real actual bug fixes should be able to be checked in before two days. I would also propose that interface changes or other substantial changes should be proposed in an issue and optionally a proposal doc. Some of the existing interfaces are natural extension points so some users will already have their own customizations. Interface changes, changes development tool (e.g., the integration tests structure, the build configuration), and the application structure all warrant some heads up to users who may have a stake in these changes. Personally, I like a lot of the activity I see going on (those black box tests are 🔥), but I wish I understood some of the decision making that was going on before a PR is posted and merged. I think friction for getting changes in needs to be low so that people are incentivized to make contributions, but we also have to balance that with ensuring everyone feels they have a chance to have a say. Maybe we need to codify some of these ideas in the Contributing guidelines? Mike On Thu, Jan 16, 2025 at 8:56 PM 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 >
