Open Stack

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?

I also have a general question about whether goals could be documented as
user stories[3]?


>


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



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time

[1]
https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst
[2]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json
[3]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160801/c9ce8c4a/attachment.html>