On Wed, Feb 20, 2013 at 5:23 PM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote: > Chip > > I posted this in another thread where 72 hour was called out, > > > Do we really need to wait 72 hours for all merge requests? I feel that slows > developers down unless they plan very well. We had similar discussion just 3 > weeks back and it was discussed that it depends on the scope and dependencies > with other modules on case-by-case basis. If all discussion and development > and review has happened by community and if it is isolated feature merge can > be done quickly. > > Here is link to that discussion. > > http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.mbox/%3c93099572b72eb341b81a644e134f240b012f747fe...@sjcpmailbox01.citrite.net%3E > >
This is the problem with needing guidelines for things. It's much easier to operate more informally, but the challenge, particularly with a rapidly evolving and growing community is to communicate the community culture and expectations effectively. One way to do that is to have guidelines for everything, and it's probably the least manpower intensive. The opposite end of that spectrum is to heavily mentor folks. One of our challenges is that we are very distributed, and the mailing list is really our only common point of interaction, and with the volume, it can be an ineffective learning process. We do have IRC, but I'd guess that less than 25% of our committers hang out there - even though we have around 150 people combined in #cloudstack and #cloudstack-dev at any given time. We do want to keep things as streamlined as possible, while not sacrificing quality or community participation. I also get the sense that rushing merges will result in far more vetos from people who would have participated in a conversation about the merge; that's more expensive in a time perspective than waiting a bit longer. --David
