Tracking commons component liveliness

[Simon Kitching <sk...@apache.org>]

Hi All,

There have recently been some discussions about handling dormant/dead
commons projects. And I've been wondering about the activity levels of
some projects recently (whether they are dead or not). 

It's hard to track activity by email volumes, and subversion commit
counts can be misleading for two reasons:
* some commits are done to fix widespread issues such as copyright
  dates, while not actually indicating activity on a project
* some projects are perfectly stable, and so have low activity counts
  though they are by no means dead and still have maintainers around.

I've got a suggestion to make about tracking this.

We could put up a page on the wiki (or maybe directly on the
jakarta-commons main page) listing all the projects (main and sandbox).
Next to each project would be listed the currently active developers and
a date. 

People would be expected to regularly (as often as they like but at
least every 3 months) go to the page and update the date next to their
name for projects they still are actively involved in, and remove their
name against any projects they no longer do anything on. By "actively
involved" I mean that they respond to bug reports or patches submitted
for the project, not just that they are currently coding on it.

Periodically (eg before the board report is due) the Jakarta PMC chair
can post a few mails reminding people to update their details. And then
names where the dates get too old can be removed as they clearly aren't
responding to those prompter emails.


A quick look at this page by users or apache people would show the
stability of projects: zero, one or multiple maintainers.

It doesn't seem an unfair burden; I'm happy to update 3 or 4 lines on a
wiki page once every 3 months.

Anyway, it's just a thought for the PMC, Henri, etc. to follow up on if
you think it's worth doing for us or the users.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Tracking commons component liveliness

[Henri Yandell <ba...@generationjava.com>]

On Wed, 27 Jul 2005, Henri Yandell wrote:

> Also, in Jakarta terms, you're talking about moving 50->100 people, which is

Oops, wrong number. 50->100 is the PMC, 50->400 is Jakarta, which in 
itself shows the possibility for inactivity.

Came up with an idea for using SVN karma to drive this, before I 
remembered that Commons is all one SVN karma and wouldn't get helped at 
all.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Tracking commons component liveliness

[Henri Yandell <ba...@generationjava.com>]

On Wed, 27 Jul 2005, Simon Kitching wrote:

> There have recently been some discussions about handling dormant/dead
> commons projects. And I've been wondering about the activity levels of
> some projects recently (whether they are dead or not).
>
> It's hard to track activity by email volumes, and subversion commit
> counts can be misleading for two reasons:
> * some commits are done to fix widespread issues such as copyright
>  dates, while not actually indicating activity on a project

Couple of thoughts on this one. We could try to train everybody to include 
a [GLOBAL] flag when doing such things, or, being as it's subversion, we 
could actually have a script that analyses the globalness on a commit.

It'd still be tricked by somebody doing many individual commits as part of 
a global effort.

> * some projects are perfectly stable, and so have low activity counts
>  though they are by no means dead and still have maintainers around.

No problem. These guys should still be listed on the inactive list, we 
would just look at them and each time agree that they are fine.

One of the problems with a low activity, by no means dead project is that 
nobody notices when it becomes dead.

> I've got a suggestion to make about tracking this.
>
> We could put up a page on the wiki (or maybe directly on the
> jakarta-commons main page) listing all the projects (main and sandbox).
> Next to each project would be listed the currently active developers and
> a date.

Downside is that it involves a lot of reliance on people to do things
periodically. These kind of systems seem to fail usually because we're
inherently lazy/easily bored.

Also, in Jakarta terms, you're talking about moving 50->100 people, which 
is a fair amount of inertia. That said, this idea would let us purge the 
cvs/svn authorizations and unix group of all the people who are no longer 
active in Jakarta.

Another possibility would be to have a file in subversion with this 
information (rather than wiki) which we could use as the configuration for 
a script to tell us about activity. skitching and rdonkin would be listed 
as the only ECS committers let's say. If bayard made a change to the ECS 
base, it would not count as activity as it would be assumed to be global. 
If skitching made a change, it would be counted as activity, even if 
global.

Said script could then let us know how long it was since each committer on 
a subproject made a commit and when that hits a year or so we could have 
periodic clear-outs.

We could also hook it to the mail mboxes to look for last email on a 
mailing list etc.

Could be something all of Apache could use. Infra have a jira issue to 
create a 'find inactive committers' script, this is effectively a variant 
on that.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Tracking subproject liveliness (was Re: Tracking commons component liveliness)

[Rahul Akolkar <ra...@gmail.com>]

On 7/27/05, Torsten Curdt <tc...@apache.org> wrote:
> > I have a big problem with putting people's names beside projects
> > and components on a public web page. Besides being yet another
> > thing that needs to be kept up to date, it will only encourage
> > people to contact the developers directly, instead of using the
> > mailing lists. From my own perspective, this is a huge problem
> > already, and I'd be -1 to anything that's going to further
> > exacerbate it.
> 
> ...in general I find the idea not too bad.
> But Martin is right - putting names to projects
> is bad in general.
> 
> What about a slight modification - what if
> every jakarta sandbox committer is required
> to report back to the *PMC* what sandbox he
> is working on? (lazy feedback of course.
> no feedback not working on anything)
<snip/>

Changed the subject since this also applies to other sub-projects in
Jakarta as well; outside Commons.

I think we should find a middle ground. There's something to be said
about transparency as well. A biannual(?) vote maybe, of the type:

<biannual-vote>
Subject: [VOTE] Active projects within Jakarta foo

I intend to contribute to (while we understand these are only best
guess estimates):

[ ] subproject bar
[ ] subproject fubar
...
</biannual-vote>

Only +1s next to subproject names, a subproject that doesn't get a
minimum number of votes (2?, even 1?) gets archived.

IMO, while this brings the process in plain view, the possibility that
this causes a surge in the traffic in personal mailboxes is probably
not high.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Tracking commons component liveliness

[Torsten Curdt <tc...@apache.org>]

> I have a big problem with putting people's names beside projects  
> and components on a public web page. Besides being yet another  
> thing that needs to be kept up to date, it will only encourage  
> people to contact the developers directly, instead of using the  
> mailing lists. From my own perspective, this is a huge problem  
> already, and I'd be -1 to anything that's going to further  
> exacerbate it.

...in general I find the idea not too bad.
But Martin is right - putting names to projects
is bad in general.

What about a slight modification - what if
every jakarta sandbox committer is required
to report back to the *PMC* what sandbox he
is working on? (lazy feedback of course.
no feedback not working on anything)

...the PMC will sort out the statistic
internally. Since project oversight is
one of the duties of the PMC ...I think
it would make sense.

WDYT?

cheers
--
Torsten

Re: Tracking commons component liveliness

[Martin Cooper <ma...@apache.org>]

On Wed, 27 Jul 2005, Simon Kitching wrote:

> Hi All,
>
> There have recently been some discussions about handling dormant/dead
> commons projects. And I've been wondering about the activity levels of
> some projects recently (whether they are dead or not).
>
> It's hard to track activity by email volumes, and subversion commit
> counts can be misleading for two reasons:
> * some commits are done to fix widespread issues such as copyright
>  dates, while not actually indicating activity on a project
> * some projects are perfectly stable, and so have low activity counts
>  though they are by no means dead and still have maintainers around.
>
> I've got a suggestion to make about tracking this.
>
> We could put up a page on the wiki (or maybe directly on the
> jakarta-commons main page) listing all the projects (main and sandbox).
> Next to each project would be listed the currently active developers and
> a date.

I have a big problem with putting people's names beside projects and 
components on a public web page. Besides being yet another thing that 
needs to be kept up to date, it will only encourage people to contact the 
developers directly, instead of using the mailing lists. From my own 
perspective, this is a huge problem already, and I'd be -1 to anything 
that's going to further exacerbate it.

--
Martin Cooper


> People would be expected to regularly (as often as they like but at
> least every 3 months) go to the page and update the date next to their
> name for projects they still are actively involved in, and remove their
> name against any projects they no longer do anything on. By "actively
> involved" I mean that they respond to bug reports or patches submitted
> for the project, not just that they are currently coding on it.
>
> Periodically (eg before the board report is due) the Jakarta PMC chair
> can post a few mails reminding people to update their details. And then
> names where the dates get too old can be removed as they clearly aren't
> responding to those prompter emails.
>
>
> A quick look at this page by users or apache people would show the
> stability of projects: zero, one or multiple maintainers.
>
> It doesn't seem an unfair burden; I'm happy to update 3 or 4 lines on a
> wiki page once every 3 months.
>
> Anyway, it's just a thought for the PMC, Henri, etc. to follow up on if
> you think it's worth doing for us or the users.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org