cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: Concerns about our community health and collaboration process
Date Thu, 20 Dec 2012 17:46:12 GMT
Thanks for the followup Chip, I think I have a better idea now.

The silence == consent thing is a bit hard for me to take; as a committer I
have the ability to really screw things up, and so there's a lot of
potential fallout from moving forward with something only to find out that
someone missed a conversation. It also sort of validates how we've been
doing things, if a feature is discussed, but there's little community
interest, that sort of seems like the go ahead for us to just work on it
and offer up our solution, with the caveat that the implementation needs to
be spelled out in detail so to reduce blowback if some unexpected result
occurs that was overlooked simply because nobody was really interested in
the feature when it was being discussed (that worries me too). This sort of
links back up with Alex's thread about knowing who is a mentor or leader
over each aspect of the project and understanding who to get buyoff from
for a new feature.

On Mon, Dec 17, 2012 at 7:53 AM, Chip Childers <>wrote:

> On Mon, Dec 17, 2012 at 6:07 AM, Sebastien Goasguen <>
> wrote:
> >
> > On Dec 15, 2012, at 12:42 AM, Marcus Sorensen <>
> wrote:
> >
> >> I agree, I certainly don't want to implement something only to have the
> >> community do the same later(and in an incompatible manner).  It behooves
> >> consumers of the project to work with the project. I just wanted
> >> clarification because I read this to mean essentially "hey guys, don't
> just
> >> drop patches on us for new features", when I actually have a few things
> in
> >> the pipeline that I intend to do that with. As I mentioned, if I don't
> get
> >> much response from the list I'll just push ahead and offer up a patch if
> >> the community wants to take it. In the future I'll be more explicit
> that we
> >> are moving forward and invite anyone to be involved if they'd like.
> >>
> >> I'm glad the issues are being addressed. And really, I don't want it to
> >> sound like we've had a huge problem because the list is generally
> >> responsive. But I can see how some people may have felt a bit lost on
> how
> >> to go forward with a new feature so I thought I'd offer up these
> >> experiences.
> >
> > I will just pick up on Marcus's last point.
> >
> > This is still a very new project with lots of people learning the
> "Apache Way" and even the open source way, the main reason for incubation.
> It takes time and patience. I for one have to learn the way it's done.
> >
> > One of the main tenant of the Apache way is that everything happens on
> the mailing list. While great, this is also difficult to get used to. Face
> to face is still a very effective interaction media :), public emails can
> be tough and solving issues via email can often lead to more issues rather
> than a solution.
> >
> > To keep things brief I would like to make two (maybe naive) suggestions:
> >
> > -Can we have an official roadmap ? We discussed a plan for release, but
> I don't know where we discussed what was going to be in the release. Maybe
> we don't need a roadmap, but for instance I don't know when the
> api_refactoring is going to be merged in master, or the javelin branch ? If
> we have a roadmap even a coarse one, we could also have a process (a light
> one) to include new features in the roadmap.
> >
> Just like many of you, I'm new to open community development.  On one
> hand, I like the idea of knowing what's coming in the future.  On the
> other hand, we had set a release schedule designed specifically to
> allow independent streams of work to converge within certain windows,
> and then have a set timetable for cutting a release from those merge
> activities.
> So let's say we turn the feature request lists into a road map of
> sorts...  I would propose that we just rank the features in order of
> our priority, and then they get picked off as developers are
> interested in them.  The actual release is based on when the work
> finishes and merges into master.
> Thoughts?
> > -We have IRC meetings, and we understand that we cannot make decisions
> in the meeting. But IRC is still a text interface. In order to build up the
> community I think we need to build up relationships. The conference did
> that (even though I was not there :( and we need to have other
> conferences/meetups/workshops/beers ). How about a voice meeting, or even a
> video one. I don't know if it's done in other Apache projects, maybe it's a
> big no-no. But seeing folks in Skype or google video might help
> communication/trust and build a healthy community.
> >
> I know of at least Deltacloud holding video / voice meetings.
> Personally, I'm a little concerned about going beyond the IRC meeting.
>  I completely agree that face to face is a very powerful communication
> method, with video and voice having similar strengths. Right now our
> struggle is ensuring that we are collaborating effectively on this
> email list.  Does focus on other communication mediums dilute the push
> to get more onto the list?
> > Cheers, and Merry Christmas :)
> >
> > -Sebastien
> >
> >
> >> On Dec 14, 2012 4:07 PM, "Joe Brockmeier" <> wrote:
> >>
> >>> On Fri, Dec 14, 2012 at 02:16:58PM -0700, Marcus Sorensen wrote:
> >>>> 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,
> >>> 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.
> >>>
> >>> Others can correct me if I'm wrong but I'd tweak this slightly:
> >>>
> >>> If you work within the community to develop a feature by proposing it,
> >>> making it available for community review, etc. - and do not have any
> >>> opposition to the feature - then it should be committed rather than
> >>> requiring someone to maintain a feature separate from ACS.
> >>>
> >>> We need to be sure we're reviewing and accepting patches/features in a
> >>> timely fashion and addressing all the requests.
> >>>
> >>>> 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.
> >>>
> >>> Sure - the ASL ensures you can develop independently as necessary and I
> >>> don't think anybody would gainsay that. I just hope it's largely
> >>> unnecessary for folks to do & maintain things outside CloudStack. I'm
> >>> sure there will be instances of features that others want that don't
> >>> seem like they fit for the overall project, but I hope we keep that
> kind
> >>> of thing to a minimum.
> >>>
> >>> Best,
> >>>
> >>> jzb
> >>> --
> >>> Joe Brockmeier
> >>>
> >>> Twitter: @jzb
> >>>
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message