On Tue, Dec 4, 2018 at 11:14 AM Allen Wittenauer <[email protected]> wrote: > > > > On Dec 3, 2018, at 9:09 PM, Sean Busbey <[email protected]> wrote: > > > > I found a pro-RTC message I did in another community. Here it is below > > just barely updated for here: > > Good stuff! Comments in-line. > > > --- > > 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? > > The same thing you’d have to do in an RTC world: ask for a review and > a commit. >
Right, but now there's no incentive for reciprocity. The review I can offer in exchange for someone reviewing my work is less of a concern for committers. This is part of where I'm starting to have my doubts. like if committers need an incentive to go commit the contributions of new folks, that should be an issue the PMC worries about. Then again, one of the most challenging things I've found so far when trying to encourage new contributors is convincing them of the value in them doing reviews. > > 2) Community interaction. [...] having the communal norm of > > reviews means that folks are more likely to see more of the code. > > Is this actually true though? It definitely feels like the larger > the code base, the more people start to specialize. Granted, I haven’t been > involved with that community that much in about a year (I’m only subbed to > security@ presently), but Hadoop definitely has more code flowing into > sub-projects than the main one that really should have been targeted for the > main project. (e.g., anything to do with metrics gathering, core pom changes, > etc) > > .. and yes, I realize Hadoop is a severely broken “community," but I > think it’s still an important lesson in where RTC completely breaks down: > > Perfectly valid code written by committers is regularly ignored > because the rest of the committers are too focused on vendor-driven goals. > Since those vendor driven goals are the only patches getting in and getting > reviewed, coworkers get commit and PMC bits at a rate significantly faster > than non-coworkers. In the end, only the vendors survive and what was a > diverse community dies. [.. and to put an ASF spin on it: it feels > sanctioned by the ASF board who really doesn’t understand what is happening > because they just see new faces being added to the rolls, not being told that > ~90% of these people work for 2-3 companies. Since no one goes emeritus, the > numbers/diversity looks more impressive than it really is: it’s not unusual > for not-coworkers to basically disappear after getting PMC or even committer.] > yeah I think that's a Hadoop thing. Definitely different than my experience in HBase, for example. Though HBase is much smaller than Hadoop they're way bigger than Yetus. :) I'd be curious to know how this looks in e.g. Spark, Mesos, Cassandra, or Beam. But I don't have the time to indulge that curiosity. I do agree with the general blind spot you're pointing out, FWIW.
