community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: A maturity model for Apache projects
Date Wed, 14 Jan 2015 19:29:44 GMT
On 1/14/15 8:22 AM, Bertrand Delacretaz wrote:
> Hi,
> On Tue, Jan 6, 2015 at 6:28 PM, Bertrand Delacretaz
> <> wrote:
>> Creating such a model has been on my todo list for ages...
> I've written a first draft at
> 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.



> -Bertrand

View raw message