Bertrand-- Thanks, this is good stuff. I take your point about final responsibility always resting with the PMC. I think what I am looking for is exactly examples of the kind you point to in Commons. I'm going to delve into the Maturity Model a bit.
--- A. Soroka Apache Jena > On Jan 23, 2017, at 12:06 PM, Bertrand Delacretaz <bdelacre...@apache.org> > wrote: > > Hi, > > On Mon, Jan 23, 2017 at 3:34 PM, A. Soroka <aj...@virginia.edu> wrote: >> ...the project is humming along nicely, growing and changing organically, >> when a Nice Person...presents >> a contribution to the project. This contribution ...is _large_. It expands >> the remit of the project much more >> than the ordinary commit.. > >> ....Is it okay for only one person to take responsibility for such a piece >> of the project going forward?... > > What's important from the Foundation's point of view is that the > project's PMC takes responsibility for releases of that module. If > something goes wrong, like an urgent security hole that needs to be > patched, it's not ok for a PMC to reject the responsibility for that > on a specific sets of committers - it's the PMC's business. > > So if a given module is clearly maintained by a single person that's a > risk for the PMC and it should label that module accordingly. > > Apache Commons for example classifies their projects in Proper, > Sandbox and Dormant - that's a fair way to give honest info about > their status, IMO, see http://commons.apache.org/ > > Items QU10 and QU60 of our Maturity Model [1] are relevant to this - a > PMC should be honest about its code, and make sure users have a good > visibility into each module's "community strength", quality, etc. > > If a PMC feels uncomfortable accepting a contribution that's too big > or not likely to be maintainable, it's fair to ask for that module to > be developed elsewhere or incubated separately. > > -Bertrand > > [1] http://community.apache.org/apache-way/apache-project-maturity-model.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --- A. Soroka The University of Virginia Library --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
