Open Stack

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.

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.

Doug