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