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

Reply via email to