Hi Mike Yes agree to fix bug faster than 2 days. I was more thinking about improvements or new stuff.
If we have a consensus, I’m happy to create a PR to update the contributing guide. Thanks ! Regards JB Le ven. 17 janv. 2025 à 06:20, Michael Collado <collado.m...@gmail.com> a écrit : > 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 > > >
