Open Stack

Hi folks!

First off-- thanks to Brandon for running yesterday's Octavia meeting when
I had to step out for an emergency at the last minute.

Anyway, it's clear to me from the transcripts of the meeting that I've done
a poor job of communicating what my intentions are, as far as what I'm
doing for managing blueprints in launchpad. Y'all did notice that I'd added
probably around a dozen new blueprints last night, and updated *all* the
other blueprints with various tweaks-- and unfortunately wasn't around to
explain my intentions during the meeting. So hey! Now y'all get another
book to read by me. I apologize in advance.

First off, let me say that I'm not a fan of the launchpad blueprint system,
and have a hard time understanding its usefulness over, say, a text file or
etherpad for tracking task lists and progress. In my opinion, launchpad has
too much detail and functionality in areas that are not useful, and not
enough in areas that actually would be useful. I could rant for a while on
a lot of specific things launchpad gets wrong... but suffice to say I'm
really looking forward to a transition to Storyboard (though I'm being told
it's not the right time for us to start using that tool yet, dangit!).
Perhaps launchpad is useful for projects that are relatively stable and
established, or useful where volume of contribution necessitates more
formal processes. Octavia definitely isn't that yet (and I would argue,
very few of the existing OpenStack and Stackforge projects appear to be,
IMO).

(For the record, yes I am aware of this:
https://wiki.openstack.org/wiki/Blueprints )

So, having said this, please note that in using this tool to manage
software and feature development in Octavia, my primary goals are as
follows:

*Keep a prioritized list of everything that needs to be accomplished to
deliver v0.5*
(And later, v1.0 and v2.0). This list is divided up into logical topics or
areas (I'm using "blueprints" for this) which should contain smaller task
lists (in the "Work Items" areas of the blueprints). Since there are still
a significant number of architectural details to work out (ex. amphora
lifecycle management), this means some blueprints are not so much about
coding as they are about design and discussion, followed by documentation.
Code will likely happen in one or more other blueprints. Also, some
blueprints might be other non-design or non-coding tasks that need to be
done in a coordinated way (ex. "Do whatever we can to get Neutron LBaaS v2
into Neutron.")

The point here is that by tracking everything that needs to happen, a
complete path from where we are to where we want to be emerges (and gets
refined and updated, as we make progress, learn more and/or encounter
obstacles).

*Indicate who is working on what*
This is both so that I know who is working on the most important things,
and so that others contributing know who they should talk to if they want
to get involved in or need to talk about a specific topic or area.

*Keep a rough estimate of progress on any given topic*
For what it's worth, I consider an implementation "started" when there's
been a significant amount of work done on it that you can share (which
includes specs). Heck, as we develop some of these features, specs are
likely to change anyway. Keeping the "Work Items" up to date is probably
the quickest way to provide some detail beyond that.

*Try to make it obvious where attention is needed*
Unfortunately, unless everyone is almost religiously using launchpad to
keep blueprint information up-to-date, then this is difficult to accomplish
with this tool. At best, a prioritized task list is a good place to start,
and using the 'blocked' progress indicator can help (when blocked).

*Try to make things as self-serve as possible*
I hate being a bottleneck in the process, so the more I can get out of the
way so people can get work done, the better. Ideally, this project should
not be dependent on any single person in order to make progress at any
stage in the game.

This also means if you're working on a blueprint, try to keep good notes in
the description, whiteboard, etc. so anyone can see what's going on with
the blueprint. Links to other resources are less desirable (since following
them off the launchpad site is distracting and disruptive), but are often
necessary, especially when linking to what will become permanent
documentation.

...

Anyway, having said my intentions above, let me suggest the following as
far as etiquette is concerned (please feel free to object to / discuss
these things of course):


*Anyone should feel free to update any blueprint*
One of the things launchpad gets right is that it will send an e-mail to
all subscribers of a blueprint whenever anything about that blueprint gets
changed. The most common changes a non-assignee is going to make to a
blueprint are going to be to clarify ambiguities, add things that are
apparently missing, or to update status and other information with what is
current. If you're the assignee, please don't take offense at this-- but do
feel free to change things back and/or strike up a conversation with the
person who made the change. If you can't come to an agreement on something,
that probably indicates something that ought to be brought before the group
anyway.

In any case, please don't view blueprints as fiefdoms that only the
assignee is allowed to control.

*Anyone should feel free to add any blueprint*
The PTL or core devs may delete the blueprint if it's redundant or
irrelevant (and usually not without explanation)-- but you should feel free
to add it anyway. It's entirely possible you see something that we don't,
eh.

*Assignees coordinate work on a given blueprint, but aren't expected to do
all the work*
Most, if not all, of the blueprints in the project are fairly extensive,
and often times it will make sense to split up the work between several
people. In these cases, the assignee's first responsibility is to
coordinate the people working on the blueprint, and THEN to actually work
on the blueprint him- or her-self. (If we aren't splitting blueprint work
up between several people, the problem of having some people over-burdened
while others are idle gets exacerbated.)

*Anyone should feel free to assign themselves to any unclaimed blueprint*
If you want to tackle something, go for it! Note that as an assignee, we're
expecting:

   - You should be responsive to inquiries about the blueprint
   - You should be driving progress on the blueprint forward (the PTL will
   likely regularly request updates)
   - You are not necessarily expected to do everything in the blueprint,
   but are expected to coordinate efforts on getting the blueprint done.
   - If someone with more expertise, domain knowledge, or capability steps
   up to help with the work, please let them. Getting this project done is not
   about egos: It's about delivering the best possible open-source
   operator-grade load balancer to the OpenStack community.

*Blueprints can be re-assigned (frequently)*
If you're going on vacation for a week and work really needs to get done on
a blueprint, then work with someone else (probably someone else working on
the same blueprint) to transfer "assignee" status to them. (And then
transfer it back when you're back, again, coordinating with them.) Note
also that the PTL or core devs might do this for you if you forget to
transfer assignee status prior to a period of unavailability. Please don't
take offense at this.

Do note, though, that it's rude to "take" someone's assignee status without
first checking with them on this. Please try not to be rude.

*If an assignee is unresponsive*
First off, please try to work with the assignee. If that isn't working,
feel free to come to the PTL (or if unavailable, one of the other core
devs-- not in your organization) to help with the issue. We're all
professional adults, and I'm pretty sure that we can work out most of these
issues between us-- but if I need to be a belligerent asshole to get things
done, I have no problem being thus (as y'all are probably now abundantly
aware).

....

As a final note, I did want to address this:  It was suggested that all the
decisions we make on this project be made by committee. I am not going to
do this, because I think this will have a severely detrimental effect on
the velocity of this project, not to mention the morale of the people
working on it. That's not to say I won't listen to objections and
alternative ways of solving problems when they arise-- but there are simply
too many decisions that need to be made on this project to go through a
committee on everything.

That's also not to say I will try to sneak things through: If I know that a
decision is likely to raise a concern, I generally go out of my way to seek
the input of the people likely to object, and drive consensus toward an
acceptable compromise.

Having said this, I know it's probably impossible for me to anticipate
every situation or decision which you might object to. If you're concerned
about the direction some of these blueprints might go, I encourage you to
subscribe to them, and then raise objections with me or with the group if
you see a problem. We're speccing almost everything out as well, so keeping
current with the gerrit reviews is the best way to make sure that concerns
you might have are addressed before we've painted ourselves into a corner.

And... I think that's about it. Please share your thoughts with me on the
above!

Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140924/4c71d91c/attachment.html>