incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: Concerns about our community health and collaboration process
Date Mon, 17 Dec 2012 14:43:17 GMT
On Fri, Dec 14, 2012 at 4:16 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
> 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.

I'd like to avoid picking out specific examples from the recent past,
because we're still figuring out how to do this as a community.  I
don't want community members to feel singled out, which would probably
happen if I didn't list all instances of it.  Moving forward, we'll be
sure to point out issues as we go.

> 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.
>

+1, that's exactly the right thing to do.  It should be extended to
your design process as well though.  It's also critical that your
collaboration happen on the list as well...  that way, it's not you +
someone else developing something, and then handing it back to the
community.  We need to mature the *process* of developing on the
project to be as inclusive and open as possible.

> 6. If there's sufficient feedback the change is committed, otherwise it's
> abandoned.
>

If you've spent the time to coordinate on the list developing the
idea, design and coordinating the implementation, then you shouldn't
have to abandon something.  To me, abandoning a feature should only
happen if there is a technical reason that the feature doesn't fit in
the project.

> 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.

All commercial entities involved have that issue, and that's the
beauty of the ASLv2.  Organizations and individuals are free to build
off of the project.

The distinction here is that we are trying to build a community *as
well as* the CloudStack software, and the community is composed of
individuals.  The focus of my concern is to make sure that people in
organization X don't collaborate outside of the community (i.e.: not
on this email list), and then assume that the work can be committed.
Each time a feature is developed in a closed environment, and then
brought to this open community as a mostly completed implementation,
it isn't actually an artifact of the project!

> 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.
>

This is the challenge of Apache projects...  the hard part is never
really the implementation.  It's in the consensus gathering.  Keep in
mind that this particular project seems to be trending in the
direction of "silence is consent", which makes us flexible enough to
tollerate lack of interest not being a blocker to a feature being
added.  Do the collaboration on the list, and unless there is a strong
disagreement with the work, it's a perfectly valid project artifact
once complete.

> 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.
>

The distinction is very clear actually.  For features that are done
within the project, they are *of* the project.  For features done
outside the project, and then proposed for inclusion later on, they
need to go through a Software Grant and IP clearance process.

Does any of this help?

-chip

Mime
View raw message