[openstack-dev] [TripleO] Can we create some subteams?
openstack at nemebean.com
Mon Apr 11 18:09:35 UTC 2016
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
> - 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.
More information about the OpenStack-dev