Something else that helps a great deal is for the original author of the proposal to be the gatekeeper on changes to the proposal, including adding committers. Wiki's are wonderful in that anyone can fix anything, but for project proposals, editing them to shift without consent their intent or original initial committer list is strongly at the root of the problem. It also allows the TSC to be *thoughtfully* flexible in places, because it can then ask the proposer "Why do you have 6 committers?". Sometimes there *will* be a good reason, and in the situations where there isn't one... the *fact* that the proposer knows they will be asked will likely lead to the correct outcome long before it comes to the TSC.
Ed On Fri, Jun 30, 2017 at 8:56 AM, SPATSCHECK, OLIVER (OLIVER) < spat...@research.att.com> wrote: > +1 > > > On Jun 30, 2017, at 11:41 AM, Andrew Grimberg < > agrimb...@linuxfoundation.org> wrote: > > To help weed things down I would suggest that every repository in a > project be required to define a distinct list of committers and not > allow an umbrella project to define top level committers. That list may > be the same across several of them, but they should be distinct to each > repository and hold to the same configuration of just a few committers > per repository. It may mean a bit more administrative overhead for the > management, and definitely for the set-up but it will clearly define who > does, and does not have domain knowledge on a particular set of code. > > > > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-tsc > >
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
