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: [DISCUSS] Don't assign tickets to people when triaging
Date Thu, 11 Apr 2013 14:39:56 GMT
On Thu, Apr 11, 2013 at 12:51:34PM +0000, Abhinandan Prateek wrote:
> Yes, I think we need to space our releases further apart.

That's a different discussion, which you are free to raise if you'd like.

> Also community members should volunteer to own some part so that in above circumstances
a person looking for some fix can approach that member, once again a suggestion.

I've been reading through this thread, and I'll pick the "owner" comment
above as a starting point for my personal opinions.  This is a reaction
to the whole thread really, so take a minute to read to the end please.

"Owning some part" is antithetical to a healthy community approach.
Certainly people will gravitate to certain areas, and by all means
everyone should feel free to work on areas of the code-base that they
feel like they want to improve or support.  This may lead to people
effectively being the primary "do-er" for certain areas (examples: Wido
has been working on DEB packaging, Rohit has been working on
CloudMonkey), but we shouldn't ever consider this ownership. I feel
personally welcome to make a change in CloudMonkey, and would certainly
consider it important to collaborate with anyone (especially Rohit) that
may have input and insights.

The idea of ownership if a part of the software is something I'm strongly
against.

Even the idea of maintainers seems like it is problematic in
implementation.  How do we decide who the "official" maintainer is?  How
do we decide when someone else should do that... And frankly, doesn't a
"maintainer" model really discourage others from working in named areas?

All of these attempts to structure the community appear to be natural
responses when you have a background in corporate development (product
or otherwise), which is my background as well.  It doesn't work here,
and you have to fight the urge to apply the same solutions (WRT
structure and process) in this environment.  If you haven't read
"Producing OSS" [1], go do that.

What we really need is for those individuals that are interested in
participating in this community to actively participate.  Read the ML,
take on bugs, focus on the shared community release goals.  If you
consider yourself interested in this project, then don't wait for
assignments from someone else.  Watch the lists, notice areas where you
can help, discuss if you disagree with proposed community goals as they
are being formed.

Personal responsibility and interest in contributing to the shared
community goals is what we should all expect of each other. We should
not expect that others in the community will spoon feed tasks out. If
that happens within someone's $dayjob, that's not a community concern.

You'll notice that I have rarely "assigned" a bug.  In a couple of
instances, I've pushed something to someone that I know is *actively*
working in an area of the code.  I've also assigned a bug as purely an
administrative step, when I know someone is already working on the issue,
but may not have had the time to assign the bug to themselves.  Release
blockers that I don't easily associated with some ongoing and known work
are highlighted in emails, with a request for someone to grab them.

Releases are the shared goals of the community, but building a strong
community is more important than any specific release.  That's why this
conversation started really.

So yes, I want blockers to be addressed.  Yes, I want us to get our
releases out.  Yes, I'd like us to be close to our proposed schedules.
No, I'm not willing to have a release take priority over the more
important goal of building a stronger and stronger community.

-chip

[1] http://www.producingoss.com/

Mime
View raw message