Developer Space/Dashboard Metrics

From wiki.gpii
Revision as of 21:48, 3 June 2015 by Avtar (talk | contribs)
Jump to: navigation, search

Developer Space Dashboard Metrics

This document contains information related to metrics that could be presented using the DSpace Dashboard.

Currently attainable metrics using public services

  • Number of contributors and commits for a repository

The above information, particularly 'total' and 'author' could be utilized to display the number of contributors and provide an idea of how active they are in the project. The data contained in the 'weeks' array could be used to provide a more detailed view of activity.

There is a note in the Repository Statistics API documentation that covers caching behaviour which has implications on the number of requests that would be required in order to obtain the most recent data.


Github enforces a rate limit of 60 requests per hour for unauthenticated requests originating from a particular IP address and 5,000 for authenticated requests. Caching responses and using conditional requests can help to stay within rate limits.

This example was Github specific but Bitbucket and Gitlab could be two additional providers

An alternative way of obtaining the above information for each repository would be to make separate requests to the list contributors and list commits endpoints. The disadvantage here would be the number of requests being made for each repository but it would align well with how Bitbucket and Gitlab provide the same information:

Displaying open issues and pull requests could help provide an idea of how active a project is, whether issues or pull requests are being closed or more opened since the last time the request was made, etc.

This endpoint will return pull requests, if they exist, along with issues. Each issue or pull request will be represented as an object. If an issue is a pull request, the object will include a 'pull_request' key.


Other options for retrieving the information above would be to use the list issues and list pull requests endpoints. Doing so will result in more requests but would be similar to retrieving the same type of data from Gitlab.

Metrics that can be gathered using existing tools

Data obtained from quering this endpoint could illustrate how stable a project is. The response includes a 'healthReport' array. The first object in the array will include a description and score of the build job. A second object will be included if the job has tests configured. The score is a percentage with 0 and 100 inclusive.

Challenging metrics

  • Test coverage
    • seems to be a popular service used by several open source projects. It will need to be evaluated in order to determine its usefulness since its API documentation is currently sparse.
  • Multi-platform accessibility evaluation tools offering CLIs and/or APIs for native and web applications