+1 I'd in favor of a "soft rule" over a "hard rule". This allows for flexibility while encouraging folks to try to engage others in the community more.
On Sun, Jan 22, 2017 at 9:44 PM, Roman Shaposhnik <[email protected]> wrote: > On Sat, Jan 21, 2017 at 10:22 PM, RJ Nowling <[email protected]> wrote: > > I agree with a lot that has been said here. Primarily, that I see RTC > as a > > way to increase committer involvement. If we know we need to be actually > > watching for commits to review, we are more likely to pay attention to > the > > project and engage in discussion. I think that more involvement means a > > more cohesive community. > > > > The biggest problem with RTC is that it holds up work by the most active > > committers, who are the life blood of the project. CTR makes it easier > for > > the most active committers to focus on their work of moving the project > > forward. That part can't be overlooked. > > > > However, if there are other ways to encourage community participation, > then > > I would propose trying those before trying to revert to RTC. > > So far the biggest rationale I can relate to is the one articulated by > Olaf -- if the project > doesn't have RTC than important stuff can flow by that not a lot of > folks realize how to > use/support (lets assume that the implementation is correct and bug > free so that the only > purpose of a peer review would be for others to actually know what's > getting where). > > So what do you folks think about flipping a problem on its head and asking > the committers still working under the CTR model to always announce any > kind of major (or even mid-size things on dev@ ? > > Would this be too weak of a guarantee? > > Thanks, > Roman. >
