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/
