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) 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. Facts and dimensions will go in a datawarehouse on top of which there will be reports to dissect and analyze data.Questions we want 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?"
Can we find our community on a particular platform such as LinkedIn or Twitter?
- How influential is a particular person?
- If a community member blogs, are they answering questions on certain channels?
- for docs: is the doc useful, did you find the info you were looking for?
- for code: did you find the code, was it easy/hard to contribute?
- for social interaction: did you find your answer? was the answer you gave useful?
- for developers: understand the use cases
- Multichannel integration: is this guy on twitter the same as the blogger the same as the mlist
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
Code development
Facts to track
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)