I found a pro-RTC message I did in another community. Here it is below just barely updated for here:
--- 1) Number One With A Bullet: It puts committers and non-committer-contributors on closer to equal footing. If I'm participating in the project and I haven't been blessed with a commit bit, what am I supposed to do after my [lazy consensus period] of having my patch sit around? 2) Community interaction. [...] having the communal norm of reviews means that folks are more likely to see more of the code. 3) Everyone has a bad day. I totally identify with committership being a sign of "I trust you" to project participants. But everyone has one of those days where you're in a rush either because of work or life. Having even a cursory additional set of eyes on things markedly increases the quality of the overall code base over a long enough time line (at least in my experience contributing to open source projects). So for me, the trust is largely "to follow the rules" and "to provide feedback in reviews". If we end up with some part of the code that isn't getting reviews, I'd rather the PMC fix that problem instead of backslide on the three points above. --- I still think these three points are true for the majority of the open source work I've participated in. That said, if I'm going to give CTR another try anywhere I'd rather it be here in Apache Yetus. So please consider my -0 changed to +1. On Mon, Dec 3, 2018 at 10:46 PM Sean Busbey <[email protected]> wrote: > > I don't know if CTR is the norm at the ASF but I know there are some > pretty big adherents to it. > > I'm normally an advocate of RTC and I think it's actually more > important when a community is small. I'm low on spare time right now > so let me see if I can find one of my old write ups to see if I still > believe what it says. The short version is that below a certain level > of activity we'll end up with essentially no community interaction. > Encouraging that interaction is part of why I've supported us taking > reviews from anyone as binding for RTC (rather than just committers). > > FWIW I'd say right now I'd be -0 on going to CTR. I know you've got > some big changes you've been working through and my once-a-month or > whatever volunteer time to look at Yetus stuff isn't going to help > enough for that. If we decide to go the lazy consensus route, 24 hours > seems like too short of a window. E.g. we often see 72 hour windows on > ASF projects to try to account for timezone and work schedules. > On Thu, Nov 29, 2018 at 11:35 PM Allen Wittenauer > <[email protected]> wrote: > > > > > > I propose moving the Apache Yetus project to a Commit-then-Review model. > > It's been evident for a very long time now that patch reviews are lacking > > sufficient resources to move the project forward. As a result, patches may > > sit there for a very long time. > > > > I believe the only way to improve the situation is to make Apache Yetus > > easier to use for those outside the ASF bubble to draw more interest in the > > project. The only way to do that is to change some of the core assumptions > > of the code, write documentation to the website, and so on. To do those > > things in a way the whole project benefits is to commit them to the source > > tree. However, accomplishing those things cannot be done if patches are > > left to rot. Thus, we are in a chicken-and-egg scenario. > > > > Going to CTR would mean that the usual quality checks would happen either > > post-commit, during release, or perhaps we have a window by which patches > > may be committed lacking any input (say, 24 hours). > > > > Incidentally, reading through > > https://www.apache.org/dev/new-committers-guide.html#guide-for-new-committers > > it would appear that CTR is the norm in the ASF. > > > > Thoughts?
