incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <>
Subject RE: Concerns about our community health and collaboration process
Date Fri, 14 Dec 2012 21:40:22 GMT
In my opinion we should lean as much as  possible towards "collaborating on all features".

The reason is two-fold  firstly  community is a place to learn and explore if we do not share
ideas we would never know what community has to offer and secondly by bringing in real world
scenarios we also help educate the community on what matters most to the end users.


> -----Original Message-----
> From: Marcus Sorensen []
> Sent: Friday, December 14, 2012 1:17 PM
> To:
> Subject: Re: Concerns about our community health and collaboration process
> I think this is a great discussion to have, but I think it would help if there were
> specific examples you could share so that we all have a better understanding.
> For example, I think I'm guilty of this in some respects, but I'm not sure if this
> is what you're talking about. Let me post one of my examples and the
> workflow that has been followed (correct or otherwise):
> 1. We have a need for CloudStack to do X
> 2. We determine if it's a feature that makes sense for CloudStack in general
> to have, or just us (e.g. it may be some small custom thing that talks to our
> internal resources or storage).
> 3. If it's generic enough that it makes sense for upstream CloudStack (and
> believe me anything we can push back we want to), we post to the list to see
> if anyone else is working on it or interested in it.
> 4. We get feedback, but whether or not the community is interested in it,
> we're going to develop it.
> 5. If it seems the community is interested in the feature, we post our patches
> for review. Small fixes to existing things are simply committed, but new
> features need review. Even if the community didn't respond, we post it for
> others to look at in an attempt to get it upstream.
> 6. If there's sufficient feedback the change is committed, otherwise it's
> abandoned.
> The key here is that we're leveraging CloudStack, but we can't be beholden
> to what the community deems are good features, so we can (and should be
> able to) develop things independently. Then we say to the community
> "here's this patch we've developed that implements feature X, if you're
> interested", which we may have attempted to start a discussion about
> previously, with mixed results. Obviously we in particular haven't had more
> than 2 or 3 things total, so don't read too much into my example, but I could
> see how it could become a huge problem.
> So if we have a procedure that can mitigate the two forces of "collaborating
> on all features" vs "developing features that are necessary and feeding them
> back to the community if they want them", it would help me, in particular, to
> plan our workflow better.
> On Fri, Dec 14, 2012 at 1:12 PM, Chip Childers
> <>wrote:
> > is email on a positive note, let me say that I personally want nothing
> > but the best for Apache CloudStack, both as a software project and as
> > a growing community of like minded individuals.  Our young Apache
> > community has done some great things together so far.  Please do your
> > part to help us continue to grow and evolve in the spirit of an Apache
> > project.
> >

View raw message