<div dir="ltr">I forgot to add to the etiquette section:<div><br></div><div><b>Before doing work on an assigned blueprint, coordinate with the assignee</b></div><div>This can help to make sure you aren't wasting time by duplicating efforts already underway.</div><div><br></div><div><br></div><div>(Hmmm... starting to thinks I should add this to a wiki page...)</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 24, 2014 at 11:56 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi folks!</div><div><br></div><div>First off-- thanks to Brandon for running yesterday's Octavia meeting when I had to step out for an emergency at the last minute.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>(For the record, yes I am aware of this: <a href="https://wiki.openstack.org/wiki/Blueprints" target="_blank">https://wiki.openstack.org/wiki/Blueprints</a> )</div><div><br></div><div>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:</div><div><br></div><div><b>Keep a prioritized list of <i>everything</i> that needs to be accomplished to deliver v0.5</b> </div><div>(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.")</div><div><br></div><div>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).</div><div><br><b>Indicate who is working on what</b></div><div>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.</div><div><br></div><div><b>Keep a rough estimate of progress on any given topic</b><br></div><div>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.</div><div><br></div><div><b>Try to make it obvious where attention is needed</b></div><div>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).</div><div><br></div><div><b>Try to make things as self-serve as possible</b></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>...</div><div><br></div><div>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):</div><div><br></div><div><br></div><div><b>Anyone should feel free to update any blueprint</b></div><div>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.</div><div><br></div><div>In any case, please don't view blueprints as fiefdoms that only the assignee is allowed to control.</div><div><br></div><div><b>Anyone should feel free to add any blueprint</b></div><div>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.</div><div><br></div><div><b>Assignees coordinate work on a given blueprint, but aren't expected to do all the work</b></div><div>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.)</div><div><b><br></b></div><div><b>Anyone should feel free to assign themselves to any unclaimed blueprint</b></div><div>If you want to tackle something, go for it! Note that as an assignee, we're expecting:</div><div><ul><li>You should be responsive to inquiries about the blueprint</li><li>You should be driving progress on the blueprint forward (the PTL will likely regularly request updates)</li><li>You are not necessarily expected to do everything in the blueprint, but are expected to coordinate efforts on getting the blueprint done.</li><li>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.</li></ul></div><div><b>Blueprints can be re-assigned (frequently)</b></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>If an assignee is unresponsive</b></div><div>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).</div><div><br></div><div>....</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>And... I think that's about it. Please share your thoughts with me on the above!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Stephen</div><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>

</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>