Open Stack

Excerpts from Shamail's message of 2016-08-01 22:37:28 -0500:
> Thanks Doug,
> 
> > On Aug 1, 2016, at 10:44 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> > 
> > Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500:
> >>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann <doug at 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?
> > 
> > Possibly. I don't want to tie the governance part of the process
> > to tightly to any project management tools, since those tend to
> > change, but if the project-specific tracking artifacts exist in
> > that form then linking to them would be appropriate.
> The purpose of the tracking is to link existing project-level artifacts including cross project specs and service level specs/blueprints.  Once the tool is deployed, we can see if it fits this need.
> > 
> >> 
> >> I also have a general question about whether goals could be documented as
> >> user stories[3]?
> > 
> > I would expect some of the goals to come from user stories, and in
> > those cases references to those stories would be appropriate.
> > However, we need much more specific detail to describe "done" than
> > is typically found in a user story, so just having a story won't
> > be sufficient. It's the difference between "As a deployer, I can
> > run OpenStack on Python 3.5" and "There are voting gate jobs running
> > all of the integration tests for a project under Python 3.5."
> I agree that user stories could provide context for certain goals but, as the template stands, it doesn't include the specifics that would be needed for a goal.  

The goal should describe the "end state".  How projects get there
is up to them, because implementation details may vary between
projects.  That's why these are "goals" and not "specs".

Doug

> > 
> > Doug
> > 
> >> 
> >> 
> >>> Doug
> >>> 
> >>>> 
> >>>>    -Sean
> >>> 
> >>> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>