I have a follow-up message to this topic which I previously shared to the private@ list regarding personal context around this situation.
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. > On Oct 16, 2025, at 12:43 PM, Matt Sicker <[email protected]> wrote: > > When we decided to try out RTC, I had accepted the idea with the caveat that > I’d only be alright with it if there is prompt PR review. Some of my PRs > since then have indeed been reviewed or approved within a day or two (good), > but some of them have sat for months without a single comment. Seeing as how > we’ve disabled committing to main and 2.x directly, I can’t merge my own PR. > I’m bringing this issue up once again to see if we can resolve it. > > This makes it much harder to make simple code changes such as typo fixes, > documentation updates, small refactoring, and similar chore work simply too > complicated with unnecessary procedures. There are some other reasons why > this RTC flow doesn’t seem to match this PMC: > > * RTC tends to be used in highly active codebases with dozens or hundreds of > regular contributors. > * RTC works best when reviewers have sufficient time available every week > (estimate; thinking of the 72-hour style feedback window at ASF). > * RTC can technically be accomplished by having a coworker review the code > before making a PR (assuming both are on the same PMC), which gives undue > advantage to full-time contributors compared to part-time contributors. > * RTC seems to think that the ideal time to go over architectural design and > other planning details is at the time of proposing the code change; ideally, > non-trivial changes will document and discuss the proposed feature via mail > and issue tracking. > * RTC is a flow optimized for accepting contributions from third parties; > being invited to be a committer is supposed to trust that person with the > responsibility to know what they feel comfortable committing directly versus > what may benefit from peer review ahead of merging. > > If you wonder how it is or was possible to manage this project using CTR, I > point to the past when it was CTR. Before we enabled Dependabot, I used to be > able to follow the commits@ mailing list where I could asynchronously review > code as it was added to a main branch. Replying to those emails would default > to dev@, so the conversation went somewhere meaningful. When we used CTR, I > would oftentimes post to dev@ with details about what I was planning to > implement or change. We had also configured CI to post an email about test > failures in the main branch(es) so that if they were broken, we were alerted > to the need to fix it right away (which was even more useful in the past when > our build/test time was much longer than it is now).
