+1
On 11 April 2013 15:39, Chip Childers <chip.child...@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. > > 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/ > -- NS
