<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:<br>
<div><div class="gmail-h5">> On 07/29/2016 04:55 PM, Doug Hellmann wrote:<br>
> > One of the outcomes of the discussion at the leadership training<br>
> > session earlier this year was the idea that the TC should set some<br>
> > community-wide goals for accomplishing specific technical tasks to<br>
> > get the projects synced up and moving in the same direction.<br>
> ><br>
> > After several drafts via etherpad and input from other TC and SWG<br>
> > members, I've prepared the change for the governance repo [1] and<br>
> > am ready to open this discussion up to the broader community. Please<br>
> > read through the patch carefully, especially the "goals/index.rst"<br>
> > document which tries to lay out the expectations for what makes a<br>
> > good goal for this purpose and for how teams are meant to approach<br>
> > working on these goals.<br>
> ><br>
> > I've also prepared two patches proposing specific goals for Ocata<br>
> > [2][3].  I've tried to keep these suggested goals for the first<br>
> > iteration limited to "finish what we've started" type items, so<br>
> > they are small and straightforward enough to be able to be completed.<br>
> > That will let us experiment with the process of managing goals this<br>
> > time around, and set us up for discussions that may need to happen<br>
> > at the Ocata summit about implementation.<br>
> ><br>
> > For future cycles, we can iterate on making the goals "harder", and<br>
> > collecting suggestions for goals from the community during the forum<br>
> > discussions that will happen at summits starting in Boston.<br>
> ><br>
> > Doug<br>
> ><br>
> > [1] <a href="https://review.openstack.org/349068" rel="noreferrer" target="_blank">https://review.openstack.org/349068</a> describe a process for managing community-wide goals<br>
> > [2] <a href="https://review.openstack.org/349069" rel="noreferrer" target="_blank">https://review.openstack.org/349069</a> add ocata goal "support python 3.5"<br>
> > [3] <a href="https://review.openstack.org/349070" rel="noreferrer" target="_blank">https://review.openstack.org/349070</a> add ocata goal "switch to oslo libraries"<br>
><br>
> I like the direction this is headed. And I think for the test items, it<br>
> works pretty well.<br>
><br>
> I'm trying to think about how we'd use a model like this to support<br>
> something a little more abstract such as making upgrades easier. Where<br>
> we've got a few things that we know get in the way (policy in files,<br>
> rootwrap rules, paste ini changes), as well as validation, as well as<br>
> configuration changes. And what it looks like for persistently important<br>
> items which are going to take more than a cycle to get through.<br>
<br>
</div></div>If we think the goal can be completed in a single cycle, then those<br>
specific items can just be used to define "done" ("all policy<br>
definitions have defaults in code and the service works without a policy<br>
configuration file" or whatever). If the goal cannot be completed in a<br>
single cycle, then it would need to be broken up in to phases.<br>
<span class="gmail-"><br>
><br>
> Definitely seems worth giving it a shot on the current set of items, and<br>
> see how it fleshes out.<br>
><br>
> My only concern at this point is it seems like we're building nested<br>
> data structures that people are going to want to parse into some kind of<br>
> visualization in RST, which is a sub optimal parsing format. If we know<br>
> that people want to parse this in advance, yamling it up might be in<br>
> order. Because this mostly looks like it would reduce to one of those<br>
> green/yellow/red checker boards by project and task.<br>
<br>
</span>That's a good idea. How about if I commit to translate what we end<br>
up with to YAML during Ocata, but we evolve the first version using<br>
the RST since that's simpler to review for now?</blockquote><div>We have created a tracker file[1][2] for user stories (minor changes pending based on feedback) in the Product WG repo.  We are currently working with the infra team to get a visualization tool deployed that shows the status for each artifact and provides links so that people can get more details as necessary.  Could something similar be (re)used here?</div><div><br></div><div>I also have a general question about whether goals could be documented as user stories[3]?  </div><div>   </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Doug<br>
<br>
><br>
>     -Sean<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div><div style="font-size:small"><br></div><div style="font-size:small">[1] <a href="https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst">https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst</a></div><div style="font-size:small">[2] <a href="https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json">https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json</a></div><div style="font-size:small">[3] <a href="https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst">https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst</a></div><div style="font-size:small"><br></div></div></div></div></div>
</div></div>