> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, April 11, 2013 7:40 AM > To: <dev@cloudstack.apache.org> > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging > > 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? > [Animesh>] +1, that is the reason Apache projects do not use @author tag. I take back my original argument of auto-assigning based on maintainers list. I did a search but did not find any community using auto-assignment. The community argument wins.
> 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. > [Animesh>] +1 I have read [1] cover to cover a few times already but looks like it is taking in longer to sink in but I think I will get there. > -chip > > [1] http://www.producingoss.com/
