Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-13 Thread Stangel, Dan 
Hi Stef,

On Thu, 2014-06-12 at 17:07 -0700, Stefano Maffulli wrote:
 we're working on a quarterly report of activities in all our git and
 gerrit repositories to understand the dynamics of contributions across
 different dimensions. This report will be similar to what Bitergia
 produced at release time.
 
 I'd like to discuss more widely the format of how to meaningfully group
 the information presented. One basic need is to have a top level view
 and then drill down based on the release status of each project. A
 suggested classification would be based on the programs.yaml file:
 
 - OpenStack Software (top level overview):
- integrated
- incubated
- clients
- other:
devstack
deployment
common libraries
 - OpenStack Quality Assurance
 - OpenStack Documentation
 - OpenStack Infrastructure
 - OpenStack Release management
 
 It seems easy but based on that grouping, integrated and incubated git
 repositories are easy to spot in programs.yaml (they have
 integrated-since attribute).
 
 Let's have the Sahara program as an example:
 
   projects:
 - repo: openstack/sahara
   incubated-since: icehouse
   integrated-since: juno
 - repo: openstack/python-saharaclient
 - repo: openstack/sahara-dashboard
 - repo: openstack/sahara-extra
 - repo: openstack/sahara-image-elements
 - repo: openstack/sahara-specs
 
 So, for the OpenStack Software part:
 * openstack/sahara is integrated in juno and incubated since icehouse.
 * Then clients: python-saharaclient is easy to spot. Is it standard and
 accepted practice that all client projects are called
 python-$PROGRAM-NAMEclient?
 * And what about the rest of the sahara-* projects: where would they go?
 with openstack/sahara? or somewhere else, in others? devstack?
 common-libraries?
 
 Other repositories for which I have no clear classification:
 
 - repo: openstack/swift-bench
 - repo: openstack/django_openstack_auth
 - repo: openstack/tuskar-ui
 - repo: openstack/heat-cfntools
 - repo: openstack/heat-specs
 - repo: openstack/heat-templates
 - repo: openstack-dev/heat-cfnclient
 - repo: openstack/trove-integration
 - repo: openstack/ironic-python-agent
 - repo: stackforge/kite
 
 Any suggestions on how you would like to see these classified: with
 together with the integrated/incubated 'parent' program (sahara with
 sahara-dashboard, sahara-extra etc  or separately under 'other'? Or
 they're all different and we need to look at them one by one?
 
 Let me know what you think (tomorrow office hour, 11am PDT, is a good
 time to chat about this).

You can also refer to the example of Stackalytics, who have created
their own hierarchy and groupings for metrics reporting:
https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json

I have found this grouping to be pretty logical and useful.

For my own internal metrics, I also rely on the programs.yaml file
organization, and / or the Programs wiki page
https://wiki.openstack.org/wiki/Programs where they differ.

Further, I group all the other projects that do not clearly fit into a
separate bucket grouping, until they either disappear or become
incorporated into other groupings.

Dan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposal to recognize indirect contributions to our code base

2013-11-13 Thread Stangel, Dan 
On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:

 To enable this, we are proposing that the commit text of a patch may
 include a 
sponsored-by: sponsorname
 line which could be used by various tools to report on these commits.
  Sponsored-by should not be used to report on the name of the company
 the contributor is already affiliated to.
 
 We would appreciate to see your comments on the subject and eventually
 get your approval for it's use.

Rather than including this sponsor information directly in commit logs,
the metrics tools could attribute specific changesets to a different
organization.  This would override the normal attribution that the
metrics tools would otherwise make based solely on the committer's own
affiliation.

gitdm already special-cases some commits. For example, we do this to
completely omit changesets that should not be counted towards
contribution metrics, such as automated commits from Jenkins or
translations [1].   Stackalytics has a similar mechanism [2], and
activity.openstack.org (metrics-grimoire) may also provide similar
functionality.

This approach moves the recognition completely out of band from the git
commit, and closer to where (presumably) it will be recognized by the
community and the sponsor.  Yet it would allows special attributions to
be transparently documented and maintained by, and within, the
community.

Dan

[1]
https://github.com/openstack-infra/gitdm/blob/master/openstack-config/grizzly - 
the list of commit IDs in parentheses are omitted from metrics totals
[2]
https://github.com/stackforge/stackalytics/blob/master/etc/corrections.json - 
stackalytics provides for finer-grained corrections to specific changesets.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev