Continuing the discussion from Ideas for creating an OpenMRS annual report:
In the analyses I did, I named out a bunch of specific “priority” repositories, based on the idea of: (1) the platform, (2) the reference application, (3) a few extra priority modules, (4) a few non-module things.
What I was trying to get at is that some code is of higher value to implementations, and we should be measuring ourselves based on producing code that implementations use. (Example: a couple summers ago I had an intern working on concept management apps, but the module never got quite finished, and as far as I know nobody is using it.)
For an external-facing update like in an annual report, I don’t think this distinction is important, and we should just report on all contributions to all repos under github.com/openmrs. (E.g. Jenn’s contributions to the conceptmanagementapps module were real and meaningful.)
But for internal KPIs, we should find a way to measure code contributions that are having an impact on implementations, and I’d welcome suggestions for how we might do this. (E.g. we should penalize ourselves on some measure for not getting Jenn’s module across the finish line and into real-world usage.) Perhaps one metric is “% of all commits that are made to repos getting significant real-world use”.
If the Atlas had higher adoption, I could imagine weighting code based on how many implementations are running that code. (But sadly we don’t have meaningful numbers of what modules are running the wild.)
More feasible today would be to assert that “modules getting significant real-world usage” is the union of (a) platform modules, (b) reference application modules, © everything we’ve ever done a sprint on, (d) top 10 downloaded modules from the module repo.
But I wonder if there’s a way to do this which is actually driven by implementation feedback and not by the easiest-to-calculate proxy that devs can come up with. @janflowers?
I list some of the specific repos I chose below, or you can see the complete list here.
- the Platform
- openmrs-core
- REST
- FHIR
- all modules included in the Reference Application
- (too many to list here)
- some other current or past priority modules
- xforms
- legacyui
- openconceptlab
- addresshierarchy
- sync
- a few non-module things
- standalone
- uitestframework
- bamboo