Open Stack

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
<vishvananda at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>