On Tue, Mar 31, 2015 at 5:24 PM, John Griffith <[email protected]> wrote:
> > > On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon <[email protected]> wrote: > >> I am starting this thread based on Thierry's feedback on [0]. Instead of >> writing the same thing twice, you can look at the rendered html from that >> patch [1]. Neutron tried to go from core to maintainer but after input from >> the TC and others, they are keeping the term 'core' but are clarifying what >> it means to be a neutron core [2]. [2] does a very good job of showing how >> what it means to be core is evolving. From >> >> "everyone is a dev and everyone is a reviewer. No committers or repo >> owners, no aristocracy. Some people just commit to do a lot of reviewing >> and keep current with the code, and have votes that matter more (+2)." >> (Theirry) >> >> To a system where cores are more then people who have votes that matter >> more. Neutron's proposal tries to align that document with what is already >> happening. >> >> 1. They share responsibility in the project's success. >> 2. They have made a long-term, recurring time investment to improve the >> project. >> 3. They spend their time doing what needs to be done to ensure the >> projects success, not necessarily what is the most interesting or fun. >> >> >> I think there are a few issues at the heart of this debate: >> >> 1. Our current concept of a core team has never been able to grow past 20 >> or so people, even for really big projects like nova and cinder. Why is >> that? How do we delegate responsibility for subsystems? How do we keep >> growing? >> 2. If everyone is just developers and reviewers who is actually >> responsible for the projects success? How does that mesh with the ideal of >> no 'aristocracy'? Do are early goals still make sense today? >> >> >> >> >> Do you feel like a core deveper/reviewer (we initially called them core >> developers) [1]: >> >> In OpenStack a core developer is a developer who has submitted enough >> high quality code and done enough code reviews that we trust their code >> reviews for merging into the base source tree. It is important that we have >> a process for active developers to be added to the core developer team. >> >> Or a maintainer [1]: >> >> 1. They share responsibility in the project’s success. >> 2. They have made a long-term, recurring time investment to improve the >> project. >> 3. They spend that time doing whatever needs to be done, not necessarily >> what is the most interesting or fun. >> >> Maintainers are often under-appreciated, because their work is harder to >> appreciate. It’s easy to appreciate a really cool and technically advanced >> feature. It’s harder to appreciate the absence of bugs, the slow but steady >> improvement in stability, or the reliability of a release process. But >> those things distinguish a good project from a great one. >> >> >> >> >> [0] https://review.openstack.org/#/c/163660/ >> [1] >> http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html >> [2] https://review.openstack.org/#/c/164208/ >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > Hey Joe, > > I mentioned in last weeks TC meeting that I didn't really see a burning > need to change or create new "labels"; but that's probably beside the > point. So if I read this it really comes down to a number of people in the > community want "core" to mean something more than "special reviewer" is > that right? I mean regardless of whether you change the name from "core" > to "maintainer" I really don't care. If it makes some folks feel better to > have that title/label associated with themselves that's cool by me (yes I > get the *extra* responsibilities part you lined out). > As Doug said in his response, for many projects this is about trying to make the definition of what is expected from a core reflect reality. > > What is missing for me here however is "who picks these special people". > I'm convinced that this does more to promote the idea of "special" > contributors than anything else. Maybe that's actually what you want, but > it seemed based on your message that wasn't the case. > correct, I would like to see the opposite. I think we need to empower and trust more people with more then just the standard +1 vote. > > Anyway, core nominations are fairly objective in my opinion and is > *mostly* based on number of reviews and perceived quality of those reviews > (measured somewhat by disagreement rates etc). What are the metrics for > this special group of folks that you're proposing we empower and title as > maintainers? Do I get to be a "maintainer", is it reserved for a special > group of people, a specific company? What's the criteria? Do *you* get to > be a "maintainer"? > Long term I see two levels of maintainers. General maintainers and subsystem maintainers. Both would more or less have the same process as core does today. > > What standards are *Maintainers* held to? Who/How do we decide he/she is > doing their job? Are there any rules about representation and interests > (keeping the team of people balanced). What about the work by those > "maintainers" that introduces more/new bugs? > > My feeling on this is that yes a lot of this sort of thing is happening > naturally on its own and that's a pretty cool thing IMO. What you're > saying though is you want to formalize it? Is the problem that people > don't feel like they're getting recognition or > Do I want to formalize it? Maybe? Right now I want to discuss the idea, so that more people can form an opinion on what the core (get it?) issue is here and how we can address it. > credit that they deserve? The "nobody wants to work on the not fun stuff" > I kinda get, and yeah.. that happens. I'd argue though there are a good > number of people that are however jumping in on things outside of features. > > Yes, there are a good number of people who are working on things besides sexy features, but IMHO not enough. I want to empower/trust more developers, but we have not been able to get passed 15/20 core reviewers per repo. > > It's sort of funny looking back over the years. We used to complain over > and over that "we don't have enough reviewers", and that "reviewing is > crucial but under appreciated work". Since then there's all sorts of > people striving to spend time doing reviews and provide in some cases real > constructive feedback. > > Now we seem to be saying "reviewing isn't where it's at, anybody can do > that; bug fixes is the new coolness". I think there are > I wouldn't say that. I think trust empowerment of more developers is the new coolness. I want more developers to be able to specialize more and feel they are responsible for the success of some piece of code. > others way to address this by the way, possibly more effective ways. > Heck, you could even do commit credits; it costs five bug fixes to the > overall project before you can commit a feature (ok, don't take me > seriously there). > > Maybe I'm misinterpreting some of this, maybe there's something in > between. Regardless I personally need a good deal more detail before I > form my opinion. > > Thanks, > John > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
