This is really good essay on the whole topic. I don't think I've seen a post on any asf list which uses both "existential threat" and "desiderata". I also like the implication that RTC is a function of the complexity of the team, rather than just the code. Every project I've worked on —open or closed— had some bit of source that we were all scared of breaking. Those bits need their oversight, no matter how —and it's recognition of that need that matters more than how the changes are managed.
+1 for encouraging CTR on startup, especially for projects starting out with almost no code or people contributing. > On 26 Nov 2015, at 01:12, Chris Douglas <cdoug...@apache.org> wrote: > > RTC is regulation. That's not a synonym for control when it's > conflated with suspicion of people. Regulation is a set of deliberate > checks on a system. > > Good regulation estimates (or reacts to) a system's natural excesses, > then attempts to constrain existential threats. It isn't a lack of > trust, but how trust is scaled. RTC can encourage review (where > oversight might be weak), throttle the pace of change (where sheer > volume might discourage volunteers and exclude individuals), and > identify code with a discouraging "bus factor" for attention or > removal (where an isolated contributor can't solicit any feedback). > Todd, Steve, Andrew, and others already covered other, intended > desiderata. > > Bad regulation erroneously classifies the power structure as part of > the system, and threats to powerful people as existential threats to > the system. It preserves privilege at the expense of individual > initiative. RTC can mire committers in review, throttle the pace of > change artificially, and entrench project members behind an inertial > default. These unintended consequences create new existential threats > to a project, which either require subsequent regulation/monitoring or > they prove RTC to be worse than the diseases it remedied.[1] > > In practice, RTC does all these simultaneously, and the community is > responsible for ensuring the implementation is effective, efficient, > and just. That balance isn't static, either. One chooses RTC not > because the code has some property (complexity, size, etc.), but > because the community does, at the time. > > All that said: many, maybe most projects entering incubation should > try CTR, and adopt RTC if there's some concrete reason that justifies > added governance. If the culture requests reviews, enforces tests/CI, > members can keep up with changes, etc. then most probably won't bother > with RTC. If the project already has an RTC culture and they want to > keep it, we've seen that work, too. -C > > > [1] RTC/CTR isn't the last policy choice the project makes, either. > Allowing feature branches to work as CTR (complemented by branch > committers) can dampen the shortcomings of enforcing RTC on > trunk/release branches. Policies allowing non-code changes, etc. have > been mentioned elsewhere in the thread. > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
