Well said. I don't disagree with any of your points or suggestions below. Looking forward to a productive chat about it at the summit in a few weeks.
-jay On Thu, Mar 31, 2011 at 6:09 PM, Vishvananda Ishaya <vishvana...@gmail.com> wrote: > 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 > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp