Thanks Doug, > On Aug 1, 2016, at 10:44 AM, Doug Hellmann <d...@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 <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? > > 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. > > Doug > >> >> >>> 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 > > __________________________________________________________________________ > 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
__________________________________________________________________________ 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