Open Stack

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