openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

There has been a lot of great discussion and airing-out around blueprint and merge process.  I think some good points have been raised on all sides.  I'd like to weigh in with some perspective-changing suggestions about how we can manage specs and blueprints that I think everyone will be happy with.

Basically we are all in the process of learning how to manage a large open-source project with 100+ developers, and I think managing a group that large by throwing everyone into a pool and hoping that all of the developers can collaborate effectively is a bit optimistic.  The suggestions that I outline below are not radical changes from how we are currently doing things, but hopefully it will help clarify the process.

Blueprints

People have extolled the value of blueprints many times, and I agree that they are very valuable.  But I think blueprints are much more valuable from a project management perspective than they are from an 'in-the-weeds' coding perspective.

I would suggest that blueprints are used to give a broad overview of an intended feature and enough technical information for the PTL and other teams to ensure that work isn't being duplicated.  Since we all work in teams, I think it is reasonable to expect every team to have a contact person that is responsible for ensuring that the team's blueprints are up-to-date with what they are actually working on.  Internal to the team this can be managed however they see fit.  It can be offloaded to individual developers or handled by a project manager, etc.

If we can all strive to follow this limited use of blueprints, I think it gives us the advantages that they provide for project management without putting too much strain on the developers.

Specs

Detailed specs beyond a brief technical overview should not be required in all cases.  It is strongly recommended (but not required) for a team to make available any internal specifications that they are using.  For small features, a simple link to a public branch is enough.

Detailed Specs should be required in the following cases:
 * A large feature that touches a lot of the code
 * Code that will need multiple merge proposals
 * Features that are being worked on by multiple teams
 * A feature that is blocking features by other teams.

I think we could 

Branches

Teams should be encouraged to keep their branches in the public as work goes on.  This allows curious community members to drill down into the current development and see what is going on.  This is especially important for teams using agile development.

Merge

Merges should be evaluated on merit.  If we get a large feature without an associated blueprint/spec, we can help educate the developer on the blueprint / spec process, but i don't think we should block merging if the feature is well designed and tested.  Obviously if the feature interferes with other blueprints in the pipeline, we can block it.



In conclusion, I strongly agree with soren's comment that the core developers should be following the suggested process, and I will mea culpa in my own avoidance of blueprints.  I think a lot of the issues the developers have had are due to a feeling that it is a) complicated and b) not valuable.  Hopefully with the understanding of the value that has been provided in this thread and the clarification and suggestions I've provided, we can all improve our teamwork.

Please let me know if I've missed anything.

Vish