Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of rohityadav89@gmail.com
 designates 74.125.83.48 as permitted sender)
MIME-Version: 1.0
Sender: rohityadav89@gmail.com
In-Reply-To: 
 <CA+96GG69tH+=L7U9-VkDk1v79WxKqBPpROpjZd78gWFscD+30g@mail.gmail.com>
References: <9313E9C8-80DD-441E-863E-0189171114D0@basho.com>
 <CD8C9E20.30506%abhinandan.prateek@citrix.com>
 <CAPaJBx508=uY_C48MZH31HRZP0vE3syP0vBNGLaqPa73zNULBA@mail.gmail.com>
 <EB0A961C-0354-483F-9E78-33733251D405@citrix.com>
 <CA+96GG69tH+=L7U9-VkDk1v79WxKqBPpROpjZd78gWFscD+30g@mail.gmail.com>
From: Rohit Yadav <bhaisaab@apache.org>
Date: Thu, 11 Apr 2013 21:22:57 +0530
Message-ID: 
 <CANLSSBUoAL=uKHgSxrmrLx=kvbY17uY15Gk7YGVGGU+3T2+a8Q@mail.gmail.com>
Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=089e0160c76aff811104da17c818

--089e0160c76aff811104da17c818
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 11, 2013 at 8:09 PM, Chip Childers <chip.childers@sungard.com>wrote:

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

Super duper +1.

I see the *feature owner/maintainer* only as person of interest around that
area and encourage contributions in whatever way and any area.

Instead of labelling things as mine or yours, being in community means we
own the whole CloudStack it as a team. So, for example I preferred to write
author as "The Apache CloudStack Team" [1] but name myself as the current
maintainer for the CLI as I've interest around that area and would like to
participate/help review/checkin any feedback/contributions and everyone is
welcome to administrate the pypi channel [1].

[1] https://pypi.python.org/pypi/cloudmonkey/4.1.0-snapshot

Cheers.
You should listen to Chip, read http://www.producingoss.com and follow his
tweets when he shares such awesome stuff ;)


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

--089e0160c76aff811104da17c818--