[Soc-coordination] Debian Teams Activity Metrics - Report IV [Update]

[Sukhbir Singh]

Hi,

Here is what we implemented during this time, in more detail:

1. Wrote a script that fetches messages for lists.debian.org from
Gmane and then creates a mbox archive for them. This allows us to
parse lists.debian.org as we don't have mbox archives for that as of
now. So we fetch the messages from Gmane, create mbox archives from
them and then throw that over to the Alioth parser (there is support
for preventing redundant fetching of messages also, so we don't strain
Gmane).

This took some time because there were lots of things to handle
(dates!) when creating mbox archives and the code had to be written in
such a way that it would work with the Alioth parser without modifying
that as initially we were not aware that we would follow this approach
of getting the archives. Actually, we didn't know that we won't get
the mbox archives for lists.debian.org but our 'hack' works :) And
note this is _public_ information (suggestions from DD that we can use
this is in the talk, subject to suggestion at 20:30 minutes).

2. Code for VCS commits was written.

2.1 Git:

For Git commits, we SSH into Alioth and then fetch the logs. The magic
(somewhat) here is that our code automatically handles multiple
packages per team, so all you need to do is specify the team name and
let it handle the rest. We measure the frequency of commits and the
number of lines changed (+ or -).

2.2 SVN:

Initially we were fetching SVN logs remotely. This took lots of time
for some teams and was unacceptable. Then I rewrote the code to
perform these operations locally and it works wonderfully now.

So during this time we implemented complete support for VCS commits
(Git and SVN) and worked our way to DebConf.

Our Git logs are indicative to check what we have been up to, browse
from 1st July to 20th July to get an idea. The latter commits are
related to the presentation at DebConf.

As for what we are going to implement, here are the important notes
for our talk @ DebConf:

The video for our talk at DebConf is at:
http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/712_Measuring_Team_Performance.ogv
(replace low with high for a clearer version)

--
07:22
What percentage of emails have actually been followed by someone else?

07:40
Attachments? People send attachments to mailing lists in the form of
patches and later on they are accepted into the team. But this metric
is _before_ they are a member of the team, so do we actually count
that?
(Your comment follows)

15:12
Enrico suggests that we measure the number of commits in a month,
which seems like a good idea. This can be easily done.

20:30
Another good point by Enrico in which he says that it's public data
but if someone is not interested, we should remove his/ her name from
it. I think this is a good idea. We should have a form or something
that people can fill if they want their name to be removed. I know
this is weird, given it's already there in other places, but well...
:)

22:10
dkg suggests that we don't mention names and just use it for team
comparison. This can be useful in some places but I don't think we
would like it globally.

27:30
Members of team who are vouched by DM/ DD. But how do we decide this 'vouching'?

28:05
Measuring Wiki page edits. This sounds good and I need to investigate this.
(Your question follows and a probable solution is provided)

30:10
(My favourite!)
A very good suggestion is made that we should ping inactive members of
a team using this data. I think this is the _best_ practical usage of
our project. A team has members who are just members and are not
contributing so that the team can know whether they still want to
contribute or not and whether their comments should be waited for.

32:00
dkg suggests that we should send a mail to debian-devel-announce or
something that we can present our metrics. We can highlight the teams
that are doing well. This will not only make our project more
practical but it is again an enhancement to the comments at 30:10.

35:40
Could this be used to identify orphaned packages? Yes. At least for
Git it is possible.
--

-- 
Sukhbir