[Teammetrics-discuss] What to present?

[Sukhbir Singh]

Hi Vipin,

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

Correct.

> 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>
>
> [...]
>
> 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)

Cool! This will help us in visualizing the project easier.

> * = 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.

Right.

> 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?

The data is collected monthly, but we can go down to the weekly and
even the daily level because say for list archives, with every message
we fetch, we also save the date the message was sent (archive_date).
So yes, you can go down that road if you want.

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

That will be the best way because then we let the users decide as to
what they want, rather than forcing something on them.

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

Cool :)

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

This sounds good for now. I am assuming you want to start at the
project level? So let's do that.

-- 
Sukhbir