Open Stack

I've been following this thread [0] with extreme interest.  It encapsulates multiple issues for the community, the developers, the vendors and the users.  And lots of people are very passionate about it.  

I would like to propose a slightly different solution to the problems.  Yes, we have a process problem, but we also have a communications problem.  

I've watched the mailing list for 2.5 release cycles now and there is a pattern that people have intimated goes back even further:  around this time in the development cycle, some part of the infrastructure, whether hw, sw, people, etc. hits a wall big enough for a large discussion such as this one.  Not surprising with the rate of growth of OpenStack and its communities.  And also what happens is that a fix is proposed on the mailing list and adopted to keep the gears oiled and turning.  Then a segment of the community gets upset because they either don't follow the dev mailing list closely for anything but the project they are focused on, or the fix is discussed and agreed upon in one project, then spreads to others as the defacto process for most projects.

So, we as a community are good at problem solving, as evidenced by both the success of OpenStack and the ability to OpenStack on the tracks through outrageous growth, but we are less good at communicating changes in direction/process.

Add to the lack of communication that we are also not especially good at going back and updating the developer documents (wikis and guides), especially for new contributors.  I know, it's hard.  I love all the guides and captured lore and I have difficulties going back and updating the parts I contribute.  Out of sight, out of mind.

So, with all that prologue, here is what I propose (and please consider proposing your improvements/changes to it).  I would like to see for Kilo:

- IRC meetings and mailing list meetings beginning with Juno release and continuing through the summit that focus on core project needs (what Thierry call "strategic") that as a set would be considered the primary focus of the Kilo release for each project.  This could include high priority bugs, refactoring projects, small improvement projects, high interest extensions and new features, specs that didn't make it into Juno, etc.
- Develop the list and prioritize it into "Needs" and "Wants." Consider these the feeder projects for the two runways if you like.  
- Discuss the lists.  Maybe have a community vote? The vote will "freeze" the list, but as in most development project freezes, it can be a soft freeze that the core, or drivers or TC can amend (or throw out for that matter).
- With list in a soft freeze, create the placeholders for the items on the list. This would be updating the bug priorities and ensuring that the bug either has an active implementer or is visibly not assigned so new contributors can claim them (new contributors easily get stymied by assigned bugs that are actually abandoned).  Create blueprints with an outline of the intent/work for small projects and again, leave the assignments empty so developers can claim them.  Create specs for the big projects (along with their skeleton BPs) and sketch out the why and some of the whats; perhaps a team of developers will claim these. By doing this, the known desired work for Kilo is advertised and both new and old contributors know where to look if they don't have their own projects they want to work on.
- Each BP and each spec should have at least one core that "owns" it.  They will watch it more closely and at least be willing to answer questions, discuss designs, or find another developer who will shepherd the assigned developer through the process (if they need it).  I would hope the cores and veteran developers would distribute the load such that no one developer would have all newbies;-)
- Now to the needs versus wants:  Any time a "need" project queues up a review, those reviews get addressed first.  Consider it the "First Class" airline lines as opposed to the "Cattle" lines. So, two runways, and needs take priority, but anyone who wants any specific review to move forward can certainly review wants.  Any BP/spec/bugfix that is proposed after the vote will take a spot in the "want" line unless it gets "promoted".  We can work on the promotion/demotion bit down the line a bit.  When the need queue is low or empty, the wants get the review attention.  Perhaps some sort of counter on +1s with no -1s will allow the patch set to graduate to "need" for a cycle, too.  That would allow patchsets of high interest and likely reasonable quality to get quicker core attention when it's close.

This is a start of a process that will:

- provide more transparency to the community
- provide clear direction from the cores and drivers
- provide input from operators and users on what is needed
- allow more informed decisions when shifting priorities
- help newbies get beyond fixing bugs and into feature development or  enhancement of the existing code base
- Provide a clearer view of progress, backlog, etc.
- Maybe it will also be able to be designed for more visibility of cross-project dependencies.

Anyway, my thoughts on how to improve communications, community ownership, strategic participation, and maybe even improve development velocity while increasing the number of contributions.

--Rocky


[0] http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html