Open Stack

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?

Doug

> 
>     -Sean
>