Developer Space/Dashboard Metrics
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
- Endpoint: https://api.github.com/repos/:owner/:repo/stats/contributors
- Method: GET
- Response: https://developer.github.com/v3/repos/statistics/#response
- Pertinent information:
- 'total': a key providing the total number of commits attributed to the contributor
- 'weeks': an array containing objects representing each week of activity. Each object contains the start date of a week represented as a Unix timestamp, the number of additions, deletions, and commits
- 'author': an object containing the 'login' key that provides the developer's Github user name
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.
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:
- List Bitbucket repository changesets
- List Gitlab repository commits
- List Gitlab repository contributors
- Number of open issues and pull requests
- Endpoint: https://api.github.com/repos/:owner/:repo/issues
- Method: GET
- Response: https://developer.github.com/v3/issues/#response-1
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
- Jenkins jobs health scores
- Endpoint: https://:jenkins_host/job/:job_name/api/json?tree=healthReport[description,score]
- Method: GET
- Response: http://pastie.org/pastes/10222186/text
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.
- Test coverage
- Number of releases a project has made
- The Github API offers a 'List releases for a repository' endpoint but if the repository owner decided to not publish any releases then the endpoint will return an empty response. For example the io.js repository returns an empty response even though numerous releases are listed when using a browser.
- Multi-platform accessibility evaluation tools offering CLIs and/or APIs for native and web applications