Open Stack

I forgot to add to the etiquette section:

*Before doing work on an assigned blueprint, coordinate with the assignee*
This can help to make sure you aren't wasting time by duplicating efforts
already underway.


(Hmmm... starting to thinks I should add this to a wiki page...)

Stephen

On Wed, Sep 24, 2014 at 11:56 PM, Stephen Balukoff <sbalukoff at bluebox.net>
wrote:

> 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
>



-- 
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/20140925/09152d74/attachment.html>