> On Apr 1, 2015, at 6:09 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > > And here is the crux of the situation, which I think bears > highlighting. These "empowered groups" are (or at least started out > as) nothing more than an attempt to map responsibilities onto the > ACLs available to our projects in the tools we use to do the work. > Coming up with some new pie-in-the-sky model of leadership hierarchy > is an interesting thought exercise, but many people in this > discussion are losing sight of the fact that the model we have is > determined to a great extent by the tools we use. Change the tools > and you may change the model, but changing the model doesn't > automatically change the tools to support it (and those proposing a > new model need to pony up the resources to implement it in > _reality_, not just in _thought_).
> Responsibilities not tied to specific controls in our tools do exist > in abundance, but they tend to be more fluid and ad-hoc because in > most cases there's been no need to wrap authorization/enforcement > around them. What I worry is happening is that as a community we're > enshrining the arbitrary constructs which we invented to be able to > configure our tools sanely. I see this discussion as an attempt to > recognize those other responsibilities as well, but worry that > creation of additional unnecessary authorization/enforcement process > will emerge as a "solution" and drive us further into pointless > bureaucracy. Given how important trust and relationships are to the functioning of individual projects, I think we’re past the point where we should allow our tooling to be the limiting factor in how we structure ourselves. Do we need finer-grained permissions in gerrit to enable something like subtree maintainers? I don't believe we do. In large projects like Neutron, there is no such thing as someone who knows everything anymore, so we all need to be aware of our limitations and know not to merge things we don't understand without oversight from those of our peers that do. Responsibility in this case could be subject to social rather than tool-based oversight. Maru __________________________________________________________________________ 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
