Open Stack

On Mon, Apr 11, 2016 at 10:33:53AM -0500, Ben Nemec wrote:
> On 04/11/2016 04:54 AM, John Trowbridge wrote:
> > Hola OOOers,
> > 
> > It came up in the meeting last week that we could benefit from a CI
> > subteam with its own meeting, since CI is taking up a lot of the main
> > meeting time.
> > 
> > I like this idea, and think we should do something similar for the other
> > informal subteams (tripleoclient, UI), and also add a new subteam for
> > tripleo-quickstart (and maybe one for releases?).
> > 
> > We should make seperate ACL's for these subteams as well. The informal
> > approach of adding cores who can +2 anything but are told to only +2
> > what they know doesn't scale very well.
> 
> How so?  Are we planning to give people +2 even though we don't trust
> them to not +2 things they shouldn't?  I remain of the opinion that if
> we need ACL controls to keep someone from doing something then they
> shouldn't have +2 in the first place.

IMO it's not about a lack of trust at all, there are several other projects
using this model and there are a number of advantages:

- Clear responsibilities enable better communication, e.g having a clearly
  defined core team for a specific subteam enables folks to more easily
  know the folks they should approach re reviews, to discuss features etc.

- Beyond a certain point, large teams make disscussion e.g in a timeboxed
  weekly meeting hard.  We're already at this point, e.g folks show up
  wanting to add an item to the weekly agenda on some topic, but we spend
  59 of the available 60 minutes discussing bugs, specs and CI.  Having
  sub-teams that feel empowered to self-organize e.g extra meetings and
  their own core members may help this process scale a little better?

- Potentially easier on-ramp (encourage domain experts as sub-team cores),
  this isn't about lack of trust, it's acknowledging that spending a year
  or more learning all the different pieces of TripleO is really hard and
  not everyone wants or needs to do it.  Would folks feel a little more
  motivated to contribute if they could aim towards deep expertise
  reviewing a smaller subsystem?

> Quickstart is a bit of a weird case because the regular contributors to
> it have not previously been very involved in TripleO upstream so I don't
> think most of us have enough context to know whether they should have
> +2.  I guess the UI would fall under the same category, so I'd be in
> favor of keeping those two separate, but otherwise I think we're
> creating bureaucracy for its own sake.

I think the overhead of creating a few additional gerrit groups is pretty
small, there's zero "bureaucracy" for pretty much everyone involved,
tripleo-core still works the same but we might just be a little quicker to
nominate folks and/or attract reviews on some smaller projects given this
change IMO (again, not through any lack of trust but because the teams
would better represent the way folks are actually working).

Cheers,

Steve