Prioritizing community metrics for OpenMRS


I noticed your created a GSoC 2018 project for Community KPIs and Activity Analytics. While I’m 1000% behind such a project, I think we would benefit from investing in hiring experts to help us set up a self-hosted and sustainable ELK stack (e.g., Grimoire labs). The GSoC KPIs project could then calculate KPIs using those metrics.

What do you think?


p.s. I think we should be leveraging github public data on Big Query so we’re not limited to repos in the OpenMRS org (e.g., we could consider any repo on github with “openmrs” in the name).

For those interested in more context…

History of OpenMRS community metrics

We’ve touched on this several times over the years. There was a point (circa 2011) where we toyed with the idea of David Eaves doing something for OpenMRS as he had done for Mozilla, using data to measure community member experience. More recently (late 2016), we had an offer from Bitergia to set up something like this for OpenMRS. While Bitergia’s self-hosted offer was a bit pricey, we might be able to work out something where we contract with them to help us set up a self-hosted instance of GrimoireLab.


There are many data points that would be invaluable in improving and growing our community efforts, supporting weekly project management decisions, quickly recognizing and addressing problems in the community experience, providing data for the website and annual reports, etc. Data to answer questions like:

  • Where is most active development within the OpenMRS community?
  • How many pull requests were merged last month? What was the average time from request to merge?
  • How many tickets got closed last quarter?
  • How long is it taking for people to get an answer at Ask OpenMRS?
  • How many people did code reviews last month?
  • Who was previously very active in the community and has dropped off in the past month?

Now that we’re in a world it’s possible to hire somone (Bitergia?) to set up Grimoire for us, I agree we should do that, and focus any of our own custom work on building our own KPIs on top of that stack.

(I’m fine to remove this as a GSoC project this year – @danfuterman created it not me!)

:grin: This was one of the unclaimed GSoC 2017 projects that was moved across as a potential project for 2018. Had a few concerns about the validity/viability of the project:

I agree with the proposed approach - will remove it from the list of GSoC 2018 projects.