[Teammetrics-discuss] What to present?

Vipin Nair swvist at gmail.com
Tue May 15 23:17:17 UTC 2012


Hi Sukhbir/Andreas,

As I understand, the goal of this project is to understand/analyze the
performance of different 'teams' in Debian. To do so, we need to link
different metrics of an individual team. This helps us to see the big
picture (Like say some team is all talk and no code, then probably
they have some misunderstanding or some trouble in decision making, or
something like that.) and makes this more effective. I had discussed
with Sukhbir once and he said it is possible. I have also looked into
the database. It can be easily achieved by adding a new table or
restructuring existing database structure.


Before proceeding with the discussion I would like to define some
terminology so that we understand each other and also helps us in
being unambiguous. This should also be considered as my understanding
of the project.

<Terminology>

Team: Let us define a 'team' as any group of people working on any
particular project as part of Debian. I am assuming a one to one
mapping from projects to team. Even if the same team is working on two
different projects, they will be considered as two different teams.
Teams do not have names and a particular team is referred to by the
name of the project they are working on. Example of this is the
_teammetrics_ team where all of us are team members, me being the
newest :) Any person who contributes to a 'team activity' will be
considered as a team member.

Team Activity: Any contributions to the 'Project' the a particular
'team' is working on is considered a 'Team Activity' of that project.
The contributions can be in form of code, bug report, uploads, and
project discussion.

Project: Any work done by a group of people (Count >0) for Debian. One
'team' works on one project. Project names are distinct across Debian.

Metrics: A quantifiable attribute that measures 'Team Activity' as
defined above. For example, _lines-of-code_ is an attribute of the
coding 'activity' that can be quantified. Metrics can be viewed at
different 'levels'.  How? (Look at the next para) There are mulitple
values for the same metric as it is recorded at different points in
time.

Level* : It is the point of view from which we are talking. At the
highest level we have the project, one level below is the metric, and
the last level is the Individual level. When we are talking about the
metrics, we need to specify a level and 'time period' along with the
metric.
  People level -- X lines of code by Y '# OR X bugs reported/closed by
Y of this team for this project.
  Metric Level -- X lines of code OR X number of bug reports for this project.
  Project level --- X lines of codes AND Y bug report AND Z list
discussion in this project.


Time period* : All (levels)/(values of metrics in that level) have a
time period associated with them only for which the data value is
valid. If a particular metric does not exist at a time period, the
value of the metric will be considered as zero. For example,
discussions may start a long time before coding, so at some point of
time on the listactivity metric exists but commitstats does not.


Here is a visual representation:

  Team (Project Level)
        |-- Team Activity (Metric Level)
                    `-- Team Activity Member (People Level)


* = Important

</Terminology>

An end user of this site can always select a time period irrespective
of the level else the default time period should be the most recent
time period for which data is available.

One question arises, What unit should the time period be in? Can time
period unit be flexible, say month, year, decade? It cannot go below
months as data is collected monthly or can it?

An end user also gets an option to view the data at different levels
at any time period. According to the level, he can customize options
available to him at that level.

At project level, a user can select the project and get the default
data. All other parameters will be some pre defined constants.
At metric level, a user can select a project and the metric. All other
parameters will be some pre defined constants.
At people level, a user can select a project, a metric, and Y, where Y
is either a particular individual in that team, or a constant like
'top5' and 'top10' whose values depends on the metric selected.


This was my basic plan on _what-to-present_ part. Please do comment on
this and add if I missed out something.

PS: The terminology is used for conceptual clarity and need not be to
presented to the user in this way. ( For example, asking him to select
a level or something like that.)



-- 
Regards,
Vipin Nair
National Institute of Technology, Calicut
http://swvist.github.com



More information about the Teammetrics-discuss mailing list