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 <sbaluk...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev