CommunityMetrics

= Measuring OpenStack Developers Community = We want to measure engagement of OpenStack's developers and users in the community.

What is engagement?
Community engagement is the degree to which an individual is active with other  individuals and groups around particular community events and issues. In OpenStack case, the engagement we want to measure is the level of  activity of each participant (developer or user, and companies hiring them --if any) with other developers/users/groups around code  development, bug reporting/triaging/fixing and blueprints, documentation  and general socialization. We want to measure facts in each of those areas and define dimensions for  each of these facts. Questions to ask to the system:


 * What actions are being taken by members, where is activity happening?
 * How to differentiate between developers and code deployers and cloud integrators? Segmentation of "who's who?"
 * How influential is a particular person?
 * Where do people find answers to their questions?
 * for docs: is the doc useful, did you find the info you were looking for?
 * for code: do people find it easy/hard to contribute?
 * for social interaction: did you find your answer? was the answer you gave useful?
 * Multichannel integration: is this guy on launchpad the same as the blogger the same as the participant to mailing list?

Socialization
Socialization in this case is about all activities to support other people in the  community, users or new developers. One proxy to measure this fact is participation of developers to mailing lists, chats and forums.

Facts to track
(does it make sense to put the channel as one dimension or is it better to track messages to the different lists, irc, etc as different facts?


 * Message

Facts to track

 * Commits
 * Code Reviews
 * Bugs

More details on

Issue tracking + blueprints
[Use http://sourceforge.net/projects/qareports/ as foundation to build upon?]

Facts to track:

 * Issues and Issue changes, Blueprints and Blueprint changes

Issues measures * Issues: Number of Issues (the total of which should match the number of bugs managed by your Issue tracking system)
 * Days Since Creation: The number of days from the Time Created to the most  recent change. Note: this is NOT calculated using the current date when  running the report. The logical defintion is “Most Recent Time Changed -  Date” ­ “Time Created”

Issue Changes measures * Changes: The number of “Issue Changes.” This the total number of times an Issue was “changed”
 * Actual Issues: Number of actual Issues (think “distinct count on actual issue  Ids”). If an Issue was changed multiple time at the intersection point  it will only count ONCE in this number.
 * Opened: Indicates how many Changes were from a Should Count Net Open = false  state (Closed, Resolved) to a Should Count Net Open = true state  (Reopened, In Progress). This will “increment” the Net Open value by  one.
 * Resolved:Indicates how many Changes were from a Should Count Net Open = true state to a  Should Count Net Open = false state. This will “decrement” the Net Open  value by one.
 * Net Open: The aggregated balance of opened and resolved values to determine  the “net.” If “Opened” = 10, and “Closed” = 15, Net Open = ­5. If  Opened = 5 and Closed = 0, then Net Open = 5.
 * Starting Net Open:The “running” balance at the beginning of this Time period. If  the report is at the Month level, this will be the “Net Open” balance  at “balance” at the beginning of the month. Note: Uses “Time Changed”  for determining starting and ending periods.
 * Ending Net Open:Starting Net Open + Net Open. If the balance at the beginning  of the year was 100, and Net Open is ­5, then the Ending Net Open = 95.  Note: Uses “Time Changed” for determining starting and ending periods.
 * Days Since Creation: The number of days from Time Created to Time Changed.  The number days “into the issue” this change occurred.
 * Elapsed Days: The number of days since the last Issue Change for this Issue.  This is useful for calculating total number of issue days spent in  statuses, assigned to particular persons, etc.
 * Net Open: The aggregated balance of opened and resolved values to determine  the “net.” If “Opened” = 10, and “Closed” = 15, Net Open = ­5. If  Opened = 5 and Closed = 0, then Net Open = 5.
 * Starting Net Open:The “running” balance at the beginning of this Time period. If  the report is at the Month level, this will be the “Net Open” balance  at “balance” at the beginning of the month. Note: Uses “Time Changed”  for determining starting and ending periods.
 * Ending Net Open:Starting Net Open + Net Open. If the balance at the beginning  of the year was 100, and Net Open is ­5, then the Ending Net Open = 95.  Note: Uses “Time Changed” for determining starting and ending periods.
 * Days Since Creation: The number of days from Time Created to Time Changed.  The number days “into the issue” this change occurred.
 * Elapsed Days: The number of days since the last Issue Change for this Issue.  This is useful for calculating total number of issue days spent in  statuses, assigned to particular persons, etc.

Documentation
[We should treat this as code and track similar things]

Facts to track:

 * Edit (similar concept as patch for code)