On 1/14/15 8:22 AM, Bertrand Delacretaz wrote: > Hi, > > On Tue, Jan 6, 2015 at 6:28 PM, Bertrand Delacretaz > <bdelacre...@apache.org> wrote: >> Creating such a model has been on my todo list for ages... > I've written a first draft at > https://wiki.apache.org/incubator/ApacheProjectMaturityModel > > I tried to take the comments of this thread into account, while > keeping the model minimal. > > Hopefully the overview helps explain the goals and expected level of detail. > > Feedback is welcome, feel free to edit obvious mistakes directly or > let's discuss larger things here.
QO30 - do we really want individual projects to have / advertise their own ways to take security reports? Shouldn't we just refer everyone to [1] or [2] and say handling should be according to the guidelines at [3]. QU40 - my friends @commons will find it comical that it is me who is questioning this one; but are we really sure we all agree on this? The "break early, break often" approach is sometimes supported with the argument that trying to maintain backward compatibility all the time stifles innovation. I don't think anyone advocates doing it in minor releases without warning, but some might argue that burning through the major rev numbers fairly quickly isn't a "quality" issue. The dodgy bit is do you maintain support for the stranded lines. CS30 - CS40 (correctly, IMO) refers to "ASF voting rules" - why should individual projects have their own voting rules? Being vote-happy is a community smell, so you would not expect mature communities to have to develop or rely on these things. Missing Q or C thing: The project is not dead. Bugs do not sit forever with no response. Questions get answered on user lists. Phil Phil [1] http://www.apache.org/security/ [2] http://www.apache.org/security/projects.html [3] http://www.apache.org/security/committers.html > > -Bertrand >
