On Wed, Nov 25, 2015 at 05:12PM, Chris Douglas 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
And that goes, as always, to the question "Who makes the decision about the _right_ level of trust". And, of course, how to make sure the governing body is corruption-proof. In other words: there are no such thing as 'good externalized regulation' because sooner or later it gets abused one way or another. And I dare you to prove me wrong on this ;) > 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] Supposedly, regulations are introduced as a reaction to failures, if I read what you're saying correctly. Empirically, majority of the failures in the self-regulating systems are a result of ill-conceived interventions from the last time. And we are going into a self-perpetuating cycle where a bad idea leads to an even worst one and so on, until the system grinds to a halt or collapse. And you're right - there are always unintended consequences to artificial limitations of any sort. One can not create a perfect set of fixed rules to address all possible future permutations. After all, this is exactly how the complex dynamic systems work. In this respect, it is wiser to let the system find the equilibrium by letting it go, and make small, localized tweaks when/if they needed. In our case, CTR relies on actors' best judgement with postponed negative feedback if something goes wrong or deemed incorrect. Such systems prove to be the most effective when compared with the rigidness of N-pager guidelines document for every step along the way. Cos > 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. > > > On Wed, Nov 25, 2015 at 12:39 PM, Greg Stein <gst...@gmail.com> wrote: > > Boo hoo. Todd said it wasn't about control, and then a few days later said > > he was forcing people into doing reviews. So yeah: in his case, it *is* > > about control. > > > > Over the 17 years I've been around Apache, every single time I've seen > > somebody attempt to justify something like RTC, it always goes back to > > control. Always. > > > > -g > > > > > > On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <andrew.purt...@gmail.com> > > wrote: > > > >> I have to completely disagree and find your assertion vaguely offensive. > >> > >> > On Nov 25, 2015, at 12:32 PM, Greg Stein <gst...@gmail.com> wrote: > >> > > >> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <apurt...@apache.org> > >> > wrote: > >> >> ... > >> >> > >> >> and inherited the RTC ethic from our parent community. I did recently > >> test > >> >> the state of consensus on RTC vs CTR there and it still holds. I think > >> this > >> >> model makes sense for HBase, which is a mature (read: complex) code base > >> >> that implements a distributed database. For sure we want multiple sets > >> of > >> >> > >> > > >> > I call bullshit. "complex" my ass. I've said it before: all software is > >> > complex, and yours is no more complex than another. That is NOT a > >> rationale > >> > for installing RTC. It is an excuse for maintaining undue control. > >> > > >> > -g > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
signature.asc
Description: Digital signature
