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).
