[openstack-dev] Avoiding regression in project governance

Devananda van der Veen devananda.vdv at gmail.com
Tue Mar 10 23:00:16 UTC 2015

On Tue, Mar 10, 2015 at 12:00 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2015-03-10 14:42:18 -0400 (-0400), Russell Bryant wrote:
> [...]
> > As to specific tags, I refer back to this:
> >
> > http://governance.openstack.org/reference/incubation-
> integration-requirements.html
> >
> > We worked pretty hard to come up with useful things for projects
> > to aim for. In fact, we considered it a minimum. Let's make sure
> > we capture the things we still value, which I believe is most of
> > it.
> [...]
> Coming from a "horizontal" resource and facilitation perspective, we
> previously had guidelines like these to help prioritize where effort
> is focused. I was hoping that most of the incubation requirements
> would become tags in some form so that support decisions could still
> be made based on them.

Many of those requirements were subjective (well tested, well documented,
etc) and had to be evaluated by the TC. Are these the sort of tags you're
referring to? If so, and if the TC delegated responsibility to manage the
application of those tags (say, QA team manages the 'well-tested' tag),
would that be sufficient?

If not, which ones do you mean?

> Otherwise I worry we're stuck relying on tags
> which merely declare the set of projects each horizontal team has
> chosen as a priority (in situations where there are ongoing demands
> on team members available time to help those specific projects).

These would be much more objective tags (eg, "qa-supported' or
'infra-supported') ... but I see your point that this doesn't help inform
decisions that horizontal teams need to make, it merely reflects the ones
that have already been made.

Nothing says we can't have both sets of tags ... but so far, neither has
been proposed.

Yes, horizontal teams should provide the means for OpenStack
> projects to support themselves where possible, but some activities
> do not scale linearly and do necessitate hard support decisions.
> Guidance from the community as to where it's most effective to spend
> those limited resources is appreciated, and also increases the
> chances that in those situations the prioritized subset overlaps
> substantially between various limited resources (which provides a
> more consistent experience and helps set expectations).

This is in line with my view -- tags should not serve as governance in the
rule-setting sense, but as providing guidance to the community. Guidance as
to what sort of behavior is expected // accepted, and guidance as to the
status of each project's conformity to those expectations.

Wit this, we can, collectively, make more informed decisions, without being
expected to independently gather that information and come to the same

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/2b08eff3/attachment.html>

More information about the OpenStack-dev mailing list