Continuing the discussion from OpenMRS Leadership Strategy Meeting 2018-05-03:
- Defining concurrency limitations
- Using an open source load tester to come up with a repeatable (preferably automated) method for estimating the maximum number of concurrent users supported by (1) Reference Application UI and (2) Platform’s REST API. Doesn’t need to be exact, but reliable enough to give the community reasonable expectations on what load OpenMRS can tolerate.
- Defining content limitations
- Come up with a repeatable (preferably automated) way to push OpenMRS to failure with content (patients, encounters, obs). Doesn’t need to be exact, but reliable enough to give the community a reasonable expectation of how big OpenMRS can grow.
- Automated testing of installation and upgrading
- Building CI projects to test the installation process (i.e., testing deployment) and to test the upgrade process (i.e., ensuring upgrade from prior version works)
There are also other roles/opportunities that could benefit from having someone own/lead them. For example, when we brainstormed community roles year ago, we came up with several software engineering roles. Some of these are still relevant:
- Web Services Lead
- Database Lead
- SDK Lead (@raff had been owning this, but changed jobs and I’m not sure if he still is planning or able to lead it)
- Specific feature lead (feature of Platform or Refapp)
Other places we could use ownership/leadership in development:
- Helping the Andela team with Java mentorship or programming
- Serving as a business analyst for the community (we could definitely benefit from more people taking on business analyst tasks for the community)
- Helping review pull requests and/or helping streamline our pull request review process (clear goals, defining/automating metrics to know if we’re meeting those goals, and growing the number of community developers productively contributing to code reviews)
If none of these are of interest, I’m sure there are other opportunities we could find.