Hi Matt, On 6.01.2026 18:10, Matt Sicker wrote: > I’ve been contributing to Log4j since 2013. This project has > oftentimes been my creative outlet for where I can work on problems > (or do some soothing refactoring such as porting tests from JUnit v4 > to v5 or cleaning up areas of code identified by static analysis > tools as concerning). This outlet has come in handy during the > various points of my career where I would be stuck across multiple > parallel lines of work waiting for PR reviews in order to make > further progress (whether those be from co-workers or from upstream > OSS projects I contributed patches to), and the only place I could > work on things without having to wait multiple days or weeks to make > progress on was Log4j. > > However, once we began requiring PR reviews, Log4j became an > extension of $WORK rather than a passion project. As such, I pivoted > to getting buy-in at $WORK to contribute to the project. By the time > I had all the approvals and had started planning on some ideas of > what to work on, Log4j had reached its current state where there are > approximately two maintainers active on it, both of whom insist on > PR reviews even from committers and PMC members. The long time > contributors who were extremely active back in the early 2010’s have > all faded from the project, most of them since about a year or two > after Log4shell. I suspect that the overly formal code review > process for committers has contributed to this decline; I know it > has had a major impact on myself. In fact, over the past couple > years, I’ve found entirely new hobbies to replace the time I used to > spend working on Log4j on nights and weekends.
Sorry for the delayed response. I encouraged you to share this perspective on dev@logging, because I genuinely find it interesting and valuable, but the last two weeks were exceptionally busy, and I didn’t have the time to respond properly. As you know, I started contributing to Log4j in January 2022. Like all external contributors, I began with PRs and, for the most part, I’ve continued working that way. At the time, I didn’t have peer review in my day job, so the PR-based workflow felt constructive and even motivating. Because Log4j evolved very rapidly in earlier years (largely using CTR, as you described), there are areas where coherence is lacking: subtle differences between components, patterns that drifted over time, and so on. Addressing those issues was one of the things that initially drew me in. For me, RTC helped ensure I wasn’t missing something important or introducing yet another variation by accident. Even when my PRs stayed open for weeks, I personally never ran out of independent issues to work on and that pool is still far from empty. I also don’t fully share the view that PRs necessarily interrupt creative flow. Once a PR is opened, most of the creative work is done, and it’s possible to move on to another task while someone else reviews it. When feedback does come in, it can be useful to reassess earlier decisions: enthusiasm and momentum are great, but they aren’t always the best guides for long-term maintainability. In this thread, both you and Gary are strongly advocating for the ability to merge your own PRs. - In principle, I could be persuaded, but I honestly struggle to see what the concrete gain would be in your case. Yes, it would allow you to land changes directly on `2.x` rather than a branch, and reduce the duration of interaction around a change. However, given your long history with the project (since 2013), I don’t see prolonged engagement as an unreasonable burden. - On the other hand, I’m not comfortable with allowing PRs to be merged while reviewer comments remain unaddressed. As I’ve said before, “addressing” feedback doesn’t mean accepting it: it’s perfectly fine to explain why a suggestion doesn’t apply or isn’t appropriate. What matters to me is that the discussion is acknowledged and closed. Where I think we may have a deeper issue is in defining what is and isn’t appropriate to ask for during a review: - Asking for tests is generally accepted. - Asking to expand the scope of a PR for broader consistency, as in Gary’s example, seems to be received much less positively. ;-) Perhaps this is an area where clearer, shared expectations would help. There are established review standards (for example, Google’s [1]) that might be worth looking at as a reference point, even if we don’t adopt them wholesale. Piotr [1] https://google.github.io/eng-practices/review/reviewer/standard.html
