Open Stack

Excerpts from Lance Bragstad's message of 2018-09-18 12:27:06 -0500:
> On Tue, Sep 18, 2018 at 12:17 PM Doug Hellmann <doug at doughellmann.com>
> wrote:
> 
> > Excerpts from Lance Bragstad's message of 2018-09-18 11:56:22 -0500:
> > > On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann <doug at doughellmann.com>
> > > wrote:
> > >
> > > > Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> > > > > Hi,
> > > > >
> > > > > Based upon the discussion we had at the TC session in the afternoon,
> > I'm
> > > > > starting to draft a patch to add long term goal mechanism into
> > > > governance.
> > > > > It is by no means a complete solution at the moment (still have not
> > > > thought
> > > > > through the execution method yet to make sure the outcome), but feel
> > free
> > > > > to provide your feedback at https://review.openstack.org/#/c/602799/
> > .
> > > > >
> > > > > --
> > > > > Zhipeng (Howard) Huang
> > > >
> > > > [I commented on the patch, but I'll also reply here for anyone not
> > > > following the review.]
> > > >
> > > > I'm glad to see the increased interest in goals. Before we change
> > > > the existing process, though, I would prefer to see engagement with
> > > > the current process. We can start by having SIGs and WGs update the
> > > > etherpad where we track goal proposals
> > > > (https://etherpad.openstack.org/p/community-goals) and then we can
> > > > see if we actually need to manage goals across multiple release
> > > > cycles as a single unit.
> > > >
> > >
> > > Depending on the official outcome of this resolution, I was going to try
> > > and use the granular RBAC work to test out this process.
> > >
> > > I can still do that, or I can hold off if appropriate.
> >
> > The Python 3 transition has been going on for 5-6 years now, and
> > started before we had even the current goals process in place. I
> > think it's completely possible for us to do work that takes a long
> > time without making the goals process more complex.  Let's try to
> > keep the process lightweight, and make incremental changes to it
> > based on real shortcomings (adding champions is one example of a
> > tweak that made a significant improvement).
> >
> > It may be easy to continue to prioritize a follow-up part of a
> > multi-part goal we have already started, but I would rather we don't
> > *require* that in case we have some other significant work that we
> > have to rally folks to complete (I'm thinking of things like
> > addressing security issues, some new technical challenge that comes
> > up, or other community needs that we don't foresee at the start of
> > a multi-part goal). We designed the current process to encourage
> > those sorts of conversations to happen on a regular basis, after
> > all, so I'm very happy to see interest in using it. But let's try
> > to use what we have before we assume it's broken.
> >
> 
> That's fair.
> 
> >
> > I think you could (and should) start by describing the stages you
> > anticipate for the RBAC stuff, and then we can see which parts need
> > to be done before we adopt a goal, which part are goals, and whether
> > enough momentum picks up that we don't need to make later parts
> > formal goals.
> >
> 
> Do you have a particular medium in mind?

Not really. As we discussed in IRC, you'll want to balance the need to
have something that's easy to edit with the need to have our usual peer
review. So some things like tracking the phases or work may be done
better with storyboard or an etherpad, and other things like working out
significant technical details may work better as documentation or spec
reviews.

Doug