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 > __________________________________________________________________________ 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