Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <86A2FCB6-29CB-4DD6-8718-A375BEE65AA2@stratosec.co>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA334EFFD@SJCPMAILBOX01.citrite.net>
	<86A2FCB6-29CB-4DD6-8718-A375BEE65AA2@stratosec.co>
Date: Tue, 18 Dec 2012 13:08:50 -0700
Message-ID: 
 <CALFpzo7w6mptFtnj3sUT_Ni3pa5x9eGtNaG66USaEJUd2aodgg@mail.gmail.com>
Subject: Re: [DISCUSS] What can we do to help CloudStack community be more
 involved
From: Marcus Sorensen <shadowsor@gmail.com>
To: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=20cf307cffccf46cc704d12610fd

--20cf307cffccf46cc704d12610fd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 18, 2012 at 12:40 PM, John Kinsella <jlk@stratosec.co> wrote:

> (comments inline)
> On Dec 18, 2012, at 10:43 AM, Alex Huang <Alex.Huang@citrix.com>
>  wrote:
>
> > Hi All,
>
> Hi, Alex!
>
> > I've talked to various developers on the challenges they face in
> participating in the community and these are issues that I've gathered.  =
I
> hope this adds to the recent discussions about project bylaws and  concer=
ns
> about community health and collaboration procedure.
> >
> >>
> >> The biggest issue I believe is CloudStack is too big a project.  When
> you look
> >> at CloudStack, it can really be broken down to five or six different
> parts that
> >> can be projects within its own right.  I don't want this discussion to
> turn into
> >> what those projects are as that should happen on the -dev list, but,
> just to
> >> give a reference, cloudstack can be broken into orchestration, VR,
> >> automation, template management, acl, UI, and console proxy.  Each of
> >> these parts can require special set of knowledge.  And to some it can =
be
> >> broken into even finer parts.
>
> The first thing that comes to mind when I read this was the other open
> source cloud automation platform, and not in a good way.
>
> We need (IMHO) to ship CloudStack as an atomic unit without worrying abou=
t
> which versions of which components work together. By breaking the
> components out, QA workload and release management workload both increase=
 -
> significantly, I suspect.
>

I agree. There are a lot of facets to the project, but I think overall it's
not too bad. I've been around for only 3-4 months, and feel that I have a
good basic understanding of all of the pieces, except for a few things like
the Mock* stuff and some work in progress stuff. In general I think it will
make the project better for people to know a bit about the whole stack.
Maybe this will become less as the architecture becomes more modular, but
for example, if you're working on something that is only agent-side (e.g.
router system vm multiple IPs per nic), you're probably also going to need
to know how the Command/Answer works between the server/agent to some
things, etc.

One idea to mitigate this though is to have defined teams, where people can
look at a page or perhaps list and know who should be able to answer their
questions. I'm all for clarifying or subdividing the information/resources
to make conversations more relevant and help more available to the
individual who only cares about a specific thing. Also some sort of defined
mentor system, where there are a few defined individuals "in charge" of
each major component.


>
> >> This leads to the following problems that I often hear when I talk to
> other
> >> developers.
> >>
> >> - The mailing list is too verbose and is often not about the subject
> they can
> >> respond to.  The problem is they get into a habit of not looking at th=
e
> mailing
> >> list because it's often not about what they can respond to but then
> misses
> >> things that they can respond to.
> >>
> >> - The same problem with the review boards.  Most of them don't feel th=
ey
> >> understand CloudStack sufficiently to be trolling the review board.
> >>
> >> - Many of them feel insecure about posting designs because the project
> is
> >> overwhelming.  Many of them want to get their designs just right befor=
e
> >> posting to the list.
>
> Valid issues=85I think the answer, whether we break apart or not, is for
> individuals to dig into the areas they're interested in, and as they lear=
n,
> to the contribute back on reviewBoard/etc. Maybe if we had intro wiki pag=
es
> for the major components of ACS?
>
> >> The second issue is we have not developed a good set of processes for
> >> people to follow.  What does it mean to post a design?  What does it
> mean to
> >> fix a bug?  How does one participate in a release? Etc.  Every bit of
> ambiguity
> >> leads to insecurity which leads to inactivity.
>
> I think we're making progress in this area over the last month - as more
> [DISCUSS] threads appear, there's more examples for folks to learn from.
>
> >> The third issue is lack of confidence in the code they write.  For
> example,
> >> today anything someone writes must be tested with the entire cloudstac=
k
> >> system which means they must know quite a bit of the system to get
> started.
> >> They can't just say I wrote a plugin and which test driver I should
> test it with
> >> to know it will work inside CloudStack.  This is different from unit
> tests.
> >> These are tests that CloudStack community provides to test contracts
> >> between projects but because there's no separate projects today,
> there's no
> >> such tests being developed.
>
>
> So here's how I'd like to address this - for the new folks (or those
> thinking of contributing) - tell us, how can we make it easier for you to
> dip your toes into the water? Better dev docs? Better QA instructions? Mo=
re
> examples on how to modify the code? Docs on things like DB schemas,
> functional diagrams, data flow diagrams, what?  Please make suggestions o=
n
> how we can help you.
>
> This one goes beyond code, but even to posting ideas/thoughts on mailing
> lists. Always plenty of lurkers.  Folks - we don't bite, promise.
>

As a new contributor, one of my hurdles was knowing really who has 'say'.
If you post something, you may only get one or two responses on it, and you
don't necessarily know if that simply indicates that some other user is
interested in that feature/has concerns about that feature, whether it's a
veto or go-ahead, or exactly where it leaves you.  So you may have a
feature you want to work on, and have some conversation/feedback on it, but
be left wondering where to go from there. This goes back to the idea about
teams/mentors.

As a committer, knowing when I need a functional spec, knowing when it's ok
to collaborate via a feature branch vs just posting a review request, and
again, when is it OK to merge the feature? When is it done? Should we have
votes?

These are the things I've struggled with.

--20cf307cffccf46cc704d12610fd--