OpenMRS devs… if you are getting this email, I’m interested in your thoughts…
Per our existing convention, any repo can be hosted under the OpenMRS organization as long as it isn’t implementation-specific and has an open source license. We have 163 repos and are on our way to 1000+ repos.
49% have not been updated in past 6 months(25% not updated in past year)
40% have only 1-2 contributor(s)(18% have only one)
75% have less than 10 forks
We have no process for removing repos from OpenMRS org.
Do we want OpenMRS org in GitHub to be hosting 1000+ repos, most of which are inactive or defunct?
If not, we need a plan, since entropy will take us there if we don’t do anything differently. At a minimum, I believe we should define a process for moving old/inactive repos out of OpenMRS org. Perhaps an openmrs-archive org in GitHub?
An alternative approach would be to raise the bar and limit the OpenMRS org to those repos that are being actively developed and supported by the community (i.e., actively used in the OpenMRS distribution and/or used by 3+ implementations), allowing individuals to host anything else they like under their own GitHub accounts. This would mean that some of the user management would fall to repo owners and we’d get used to some of our community work forking from individuals’ repos.
I’m just a lowly GCI student, so take this with a grain of salt, but my preference would be to only have projects core to OpenMRS under the org. This would be core, contrib-id, etc.
Then, I would vote that items that aren’t core to OpenMRS would be owned by their most active contributor, or whoever started them. That way people would be ‘rewarded’ for their contribution with ownership of their project, without having to add them to the org owners.
I’m working on the iOS app, currently under my account. The current plan is to transfer it to the OpenMRS org. Here are my thoughts:
I built it, it wouldn’t make very much sense for me not to have commit access to my own code. (and the code I’m publishing on the App Store)
It wouldn’t make very much sense for people without iOS/Obj-C/Swift skills (but very good in other areas, and thus owners) to have commit access to it.
If I were added to the OpenMRS org, it wouldn’t make sense for me to have commit access to other projects - I really don’t need access to core, I’m far too likely to break something.
That’s just my thoughts, but it’s early in the morning here and I don’t drink coffee so they might be a little crazy.
Since GitHub doesn’t really have a plan for “archiving” old repos (and an “archive org” seems to confuse things even more) I personally think this is the approach we should take going forward. It also seems to fit in well with the emerging idea of progression/evolution of developer roles, modules or projects could also evolve over time to be “community supported” once specific published criteria are met. (More than what we have now which is basically just asking.)
This is actually what we anticipated long ago in Kigali when we first agreed to move to GitHub, and is why we settled on the syntax of repo names like openmrs-module-foo for example … it makes it easy to search out OpenMRS modules, wherever they are located on GitHub. It also gives more autonomy to our developer contributors to take control of the projects that they (or they and others) are de facto leading.
I’m also interested to hear other ideas, especially ones that disagree from what I just wrote.
I think it is perfectly fine to have 1000+ repos under the openmrs org in github. There is a nice search feature and one doesn’t need to scroll through the list. What is active shows up first anyways on the list of repos
I agree that the number isn’t really the problem here. It’s more the expectation of ownership/responsibility/accountability with the repo’s “owning” organization and/or individual in GitHub, IMHO.
If a module doesn’t have updated documentation or doesn’t have updated work done on the codebase, it is likely to have been abandoned for further development. But removing it from the repo just because its been abandoned for further development, doesn’t mean that the older versions are not usable… And so it should still show up.
And not every module under the openmrs org needs to stay updated. I think the github org should only serve as an easy way to find code, and not function as any form of contract
Putting any/every repo under the OpenMRS org is not without some costs (i.e., asserting conventions, managing team memberships, etc.), which could be distributed if individuals managed their own repos.
@sunbiz, have you encountered another example of an organization with hundreds or thousands of repos in github? Looking around at python, ruby, perl, etc. they all have a single page of repos. discourse is the most I could find (around 30 repos). When you look at trending repos, you see mostly personal accounts, not orgs. This too makes me feel like we’re going about this wrong (i.e., overemphasizing a distinction between community members & the community).
I’m not so concerned about having 1000s of repos. It’s true the search feature works reasonably well (as long as you know what you are searching for). That said, the search feature for all of GitHub works pretty well too… and why are we alone in this approach? If I could see some other orgs ahead of us (i.e., without 1000s of repos) who were happy about their setup, then I’d be reassured.
@burke - Apache also mirror their git repos on github - https://github.com/apache
Another point to consider - Do we want to reject code donations someone wants to make to OpenMRS? What if a developer worked on a module for sometime and doesnt have the cycles to continue making new releases. The dev wants to put it under the openmrs org so that other devs might take it forward.
Keep in mind that the OpenMRS GitHub organization != the OpenMRS community. The community is the people building OpenMRS as a collective work, and our software is jointly owned by those who made it, until otherwise arranged.
I think the key is to ensure access to any code developed for OpenMRS in perpetuity. I believe an archive would be most appropriate to ensure that modules developed today are available in 10 years regardless of active involvement.
If we shift to personal repos, it’s possible that we could lose code as an individual becomes disinterested or shifts jobs and tries to make their personal Github account look better. I’m interviewing for jobs and we’re talking about my commit history at different projects. I wouldn’t look good if I had a bunch of old modules sitting in my personal account.
+1 for creating an archive with a clear path to fork and activate it back into the OpenMRS organization if someone wants to return to active development.
