Open Stack

On 04/11/2016 12:12 PM, Steven Hardy wrote:
> 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.

Fair enough, although I'm not sure a wiki page wouldn't be a better way
to capture this information.  We're never going to have granular enough
gerrit groups to capture things like who the experts on
upgrades/networking/ssl/etc. are.

> 
> - 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?

I probably should have been more explicit that I'm only referring to
separate Gerrit groups.  Totally +1 on the concept of sub-teams in general.

> 
> - 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).

I still have reservations, but once again I seem to be in the minority
here so I won't spend a lot of time arguing the point.