commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [VOTE] Revised dormancy policy
Date Tue, 17 May 2011 02:46:45 GMT
On 5/16/11 4:21 PM, sebb wrote:
> On 17 May 2011 00:07, Gary Gregory <> wrote:
>> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht <> wrote:
>>> So we should relaunch a vote?
>>> (or... I should vote a no and relaunch?)
>>> paul
>>> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
>>>>>>   d) svn remains open (but no commits without revival vote)
>>>>> It seems slightly too harsh to me.
>>>>> Since jelly is among the heaviest targeted ones here, I think the whole
>>> dormancy aspect would fit but preventing commits sounds like the best way to
>>> "cap off any attempt of revival".
>>>>> Couldn't we say
>>>> Good point.  I would be OK with that change.
> +1 to allowing SVN changes.
>>>> Phil
>>>>>>   d) svn remains open (but no release without revival vote)
>> Dormant status feels like a death sentence of sorts or at least another
>> barrier to entry.
>> If a committer wants to fiddle with POMs for example across all of commons,
>> he or she should be able to do so. Even a casual change like fixing typos
>> would not be allowed.
>> I wonder if the opposite would not be more interesting: showing which
>> projects are Active.
>> The whole dormant/active deliberation could be remedied with a page ranking
>> project activity by commit + ML activity + last release date for example.
>> The audience can decide what is active based on this table: Project Name,
>> Commits Last Week/Month/Year | ML msg count week/month/year | Last Release
>> and Date
> Mature and stable components will tend to have low activity, but
> should not be marked dormant.
> It would be useful to know which projects have outstanding bugs that
> are not being addressed - that seems more likely to indicate dormancy.

I agree with your points, but I am very hesitant to get into the
maintaining metrics game, partly because maintaining them requires
work but more because I don't really believe they can tell us what
we need to know to make these decisions.  Some active components,
for some periods, have big backlogs and relatively slow response. 
Some bugs get "attention" but no resolution for a long time.  And as
you said, some stable, but still active components have few issues
and commits during some periods.

What I wanted to capture in "dormancy" was community consensus that
nothing was - currently - going on with the component.  The best way
to determine that is to ask the question, "is anyone planning to do
any work on this any time soon?"  Voting -1 on a dormancy vote as I
have described it effectively means "yes" or at least "maybe."   I
bet we can relatively quickly get to consensus on some really
"dormant" stuff (e.g. [attributes]) and any that are in any way
debatable, (e.g. [jelly]), we leave as active and revisit now and
then if there are no signs of life.  My idea here was to make this a
"small reversible step" for us as a community, not a radical change
and not something that will create a lot of work or noise.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message