[Teammetrics-discuss] Video Notes.

[Andreas Tille]

On Wed, Aug 03, 2011 at 01:15:30PM +0530, Sukhbir Singh wrote:
> Hi,
> 
> 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
> 
> Here are the important points for the meeting that we should
> implement/ give a thought to:
> 
> --
> 07:22
> What percentage of emails have actually been followed by someone else?

The idea is in fact interesting, but I have no good idea how to finally
express this.
 
> 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)

By our definition a posting to the mailing list just makes such a person
a member of the team.  Because we only regard top most posters this side
effect seems to be irrelevant, because if the poster is doing it really
frequently he will finally do its commits inside the repository.
 
> 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.

It can be done but on the other hand we somehow agreed to have this
aggregation over one year as some privacy means.  Missing commits might
reflect vaccations, holidays or so.  So while this is actually
interesting I would not put this on high priority because of this side
effect.
 
> 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...
> :)

We could implement this by our established name substitution procedure
where people are posting under different names.  We could then rename
the person to <privacy concerned member> or something like this.  I hope
we will not have much of these issues and I think there is no form
needed but a simple e-mail request might do.
 
> 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.

This would be a last resort (for instance by leaving out the legend) but
I hope we will not be forced to do so by to many <privacy concerned
members>.
 
> 27:30
> Members of team who are vouched by DM/ DD. But how do we decide this 'vouching'?

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

My idea was to subscribe Wiki edits to certain pages per Team.
 
> 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.

Yes.
 
> 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.

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

Why only Git?
 
> It was suggested by a friend after the video (and who was too shy to
> speak during the recording!), that we measure balance within a team.
> Like in the 'debian-med', you were the single committer.

Fortunately not.  It was the blends commit where I'm very highly
involved and others are not that deep in the team.  But yes, in
principle we should try to cope with such "1-man teams".

> However,
> there are many teams that have a balance of involvement and we need to
> highlight that because that is what makes a team good -- every member
> is contributing.

This is actually what I'm concerned about.
 
> We will take up the points mentioned here one by one.

I remember there was also an interesting measure (mentioned by Enrico?):
The bugs a team member has fixed.  I will investigate into UDD some
time to see if we can find out this information.

Kind regards

      Andreas.

-- 
http://fam-tille.de