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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
