On Tue, Sep 18, 2018 at 12:17 PM Doug Hellmann <d...@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 <d...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
