Open Stack

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?


>
> Doug
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180918/e9c4920b/attachment.html>