Thank you so much for starting this important discussion.
How we got here
OpenMRS started before git existed. When we started, subversion was da bomb. We were quick to embrace subversion and befriended Karl Fogel, who taught us so much about producing open source software. This included enforcing commit privileges socially instead of technically – i.e., avoid micromanaging write access to code (it’s a versioning system, after all, so it’s easy to undo changes). When we migrated to git about 10 years ago, we brought this ethos with us: be quick to grant write access to code and manage authorization socially. This translated into anyone
/dev/3 or above getting write access to our repos. Unless you change the default settings, your git account is configured to auto-watch any repo to which you are granted write access. Since we have 250+ repositories, when you become a
/dev/3 you end up, by default, watching a hundreds of repositories.
I appreciate that someone watching hundreds of repositories is effectively watching 0 repositories, since nobody can keep up with activity across hundreds of repositories. As a result, there’s ambiguity on who is truly overseeing repos and a corresponding vacuum of accountability. On the other hand, if you should come across something that needs to get fixed in a community repo, you don’t have to ask permission fix it.
We have 3 to 5 times more repositories than developers. So, there are many repos that are currently loosely maintained or not maintained at all. Switching to an approach where admins of a repo are explicitly defined, will make it very clear which of our repositories – including “core” repositories – are not owned by anyone. I expect it will be the large majority of repositories under OpenMRS org. I’m not suggesting this is a reason not to make the changes you suggest; in fact, making it obvious which repos don’t have an admin or maintainers will help everyone and help devs to see where they are needed.
What happens with repos for modules we use but don’t have an admin or maintainer?
We could define conventions for dealing with repos that have no admin/maintainer. Abandoned & unused repos can be archived or moved to openmrs-archive; however, we need to consider what we do about a repo for a module that is widely used but stable and rarely changed (e.g., calculation).
How do we avoid re-creating the administrative bottleneck and barriers that existed in subversion?
Perhaps in a world of git, easy forking, and PRs it’s less of an issue. But I think there’s more to Karl Fogel’s recommendation of managing authorization socially instead of technically. It’s not just a matter of avoiding administrivia & permission bottlenecks, but also promoting a culture of trust. Perhaps we could make a lightweight bot that would allow anyone who is a
/dev/5 to grant admin access to themselves to any OpenMRS repo. If an admin leaves the community and abandons a repo, you don’t have to submit a ticket or hunt down an org admin, you just grant yourself admin access to the repo or, if you aren’t a
/dev/3 yet, ask any seasoned devs you happen to be working with to help you out.
When does a repo need to live under OpenMRS org?
It might help to move away from an “everything needs to be under OpenMRS org in GitHub” model. While it can be convenient to search repos under the OpenMRS org, it’s just as easy to search GitHub for openmrs. Or we could promote use of the openmrs topic a search GitHub for topic:openmrs. Getting comfortable with having only a handful of repositories hosted under the OpenMRS org in GitHub and having “official” OpenMRS repos hosted under various individuals’ or other organization’s account could help promote the type of module maintenance you describe. For example, does it really matter that the openmrs initializer module is hosted by mekomsolutions? Maybe it’s even better than hosting it under the OpenMRS org. But we need a shared understanding of when & why a repo belong under OpenMRS org.