I'd love to start using the github PR workflow for our contributions. I've been using them for my changes for a while and find it much easier than running a full build locally to verify each change on my development system. While we've historically used "commit then review", I find it much easier to consolidate review and discussion on pull requests, which results in cleaner history, and clearer historical context in one place when changes are requested. The downside is that it means merging changes is blocked on other committers, so we must be cognizant of that when PRs are opened, keeping a balance of timely reviews and patience.
While this isn't an issue for our own changes, we may need to figure something out to improve the experience of adding changelog entries for third-party contributions, however those are a minority and I wouldn't block on solving that problem. Carter On Wed, Jan 26, 2022, at 15:25, Volkan Yazıcı wrote: > According to the OSSF Scorecards <https://github.com/ossf/scorecard>, we > are missing two check marks (LOG4J2-3260 > <https://issues.apache.org/jira/browse/LOG4J2-3260>) there: > > 1. Require code review (every change goes into a PR and requires at > least one reviewer) > 2. Require a CI status check > > Even though I admit with the convenience of freedom we have right now, I > personally find it difficult to keep track of what is going in and out. > This convention does not aim to obstruct the development progress, but > rather improve the overall code quality and spread the know-how in a > scalable way. Hence, I want to implement this feature on `release-2.x` and > `master` branches. Thoughts? >
