I think CTR may be a good idea. Considering all the excellent efforts to build community by Moon and others, I can understand why he has experienced the community in the way he describes.
My experience, however, has been different. I’m not sure that community involvement is either as broad, or as deep, as Moon suggests. Silence is not the same thing as consensus. It seems that active, regular involvement from outside the PMC is a very small number of people. I have a PR that has been pending since *August*. It’s the subject of 2 jira’s, and I’d emailed members of the PMC about it several times. It has an active user base, to whom I provide technical support. It’s been presented to Spark (and soon, R) user groups. However, as I understand it no member of the PMC has ever downloaded or tried the code. In fact, no member of the PMC even looked at the code until the users began tweeting to ask why the PR had not been accepted yet. One of the prerequisites to graduate from incubation is decentralization of project governance. For example, it can’t be that all the code, or significant code, comes from the PMC. And the PMC members can’t be all or mostly co-affiliated with each other. At this point, anything that would decentralize the project can only help move it toward graduation. In fact, if graduation is a goal, it seems to be mandatory. CTR sounds like it might help. From: moon soo Lee <[email protected]> Reply: [email protected] <[email protected]> Date: November 27, 2015 at 8:15:50 PM To: [email protected] <[email protected]> Subject: Re: Trying CTR for the project Thanks for starting the thread. I was keep an eye on discussion about CTR/RTC on the general@incubator. I saw people think RTC means lack of trust in that discussion. To me that is complete nonsense. I can say, RTC trust others more, trust reviewer. So I don't agree the "reason" CTR over RTC in the discussion on general@incubator. Importantly, Zeppelin project used to count not only review from committer but also review from any contributor. This kind of consensus sharing among the community may be lost or weaken when committers start commit in CTR fashion. But what I agree is, CTR can be faster than RTC. That can help speed up the development of Zeppelin and that's what I personally really want and can't wait. So, to me, applying CTR for this reason is more than welcome. But I think we need some preparation to keep the consensus in the community. I think building set of guidelines for each components (GUI / Core / Interpreter / Notebook Storage / etc) would help. Contribution guide that we're discussing on mailing list [1] and "Zeppelin UI design principle" [2] could be example, what guidelines trying to do. Community can discuss and create/change guidelines. Once they're settled then I think there will be no big problem applying CTR in Zeppelin project. And that means some type of discussion about the code is going to be moved from individual pullrequest to guidelines. Which is indirect but more scalable way. Best, moon [1] http://s.apache.org/ma4 [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328042 On Sat, Nov 28, 2015 at 8:05 AM Konstantin Boudnik <[email protected]> wrote: > Guys, > > as you might have seen on the general@incubator list, there's a lengthy > discussion about benefits of Commit-Then-Review (CTR) development model > over > Review-Then-Commit (RTC) one. > > As the project is getting more mature, I would like to start the > conversation > on what the community think about this sort of thing. If anyone isn't clear > about the topic - please chime in and I would be happy to go into as much > details as needed. In the meanwhile, here a coupe of links that might help > > Apache Ignite CTR vs RTC discussion (Ignite is CTR project) > http://s.apache.org/wPA > Apache Bigtop CTR vs RTC long thread (Bigtop is a CTR project as well) > http://is.gd/TgBovX > > Regards, > Cos >
