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