Our process for repository management depends on you!

Calling all /dev/5s…

We need to sort out how we plan to manage our GitHub repos. I am assuming that all /dev/5s are notified when topics are entered in this Repo Management category, so starting this conversation here.

In the past…

We used code■■■■■■■■■■■■ as a group email. Anyone could write to it and the email was distributed to our “code” group, which was basically all of our “Full Committers.” It was up to this group to respond to requests in a timely manner.

Today…

Our code■■■■■■■■■■■■ distribution list has been replaced with the Repo Management category on OpenMRS Talk. Requests are coming in, but nobody is answering them in a timely manner.

Going forward…

I believe we should continue to address repository change requests as a group (i.e., amongst /dev/5s) for a few reasons:

  • As a group, we can ensure conventions are being followed (OSI licensing, predictable naming, etc.)
  • It’s an opportunity to inform people of other similar efforts they may not know about.
  • The organization of our repositories should be managed by the community (i.e., us, the developers) and not left to a Help Desk.

Comments?

Agreed? Or do you disagree? I we agree, I would ask that all /dev/5s feel both the responsibility & authority to respond to repo management requests and, just like we did with code■■■■■■■■■■■■, we use brief, timely discussions to move things along while keeping our repositories tidy & predictable for everyone’s sake.

3 Likes

I guess i agree

Can we distinguish between deciding what needs to be done (+/- whether it’s okay to to do the requested thing) versus doing the work of carrying it out?

E.g. I do agree that it’s a responsibility/authority of /dev/5s to say any of these things:

  • “yes let’s transferring xyz repository into the openmrs github group”
  • “+1 to creating a new openmrs repo with that name”
  • “the repo name is confusing / doesn’t follow convention so …”

However the process of creating or (especially) moving a repository is tedious and it doesn’t feel like “everybody’s job” or a group activity.

And I think I’ve probably avoided commenting on topics to say “+1” because I don’t have time to deal with actioning it.

You’re correct. I didn’t mean to suggest that a /dev/5 would perform the migration. When a migration is approved, then the requestor is temporary added to the “Transfer Team”, which gives them the privilege to migrate the repository. Once complete, they’re removed from the Transfer Team. Any Owner in GitHub (currently Michael, Elliott, myself, Darius, Mike, and Ryan) can add & remove someone from the Transfer team (it’d be nice if we could let any /dev/5 manage Transfer Team membership, but I’m not seeing that as an option in GitHub at the moment).

So, if you don’t have the time to add someone to the Transfer Team and then remove them after they’ve migrated their repo, then you could ask the Help Desk to do it. But /dev/5s should be responding to requests & making the decision when a migration should occur.

1 Like

Agree all /dev/5s should be responding to transfer requests with +1 or comments. BTW I wonder how many +1s is enough to get the repo to be transferred :smile:

I’m not sure why we transfer repos instead of simply forking someone’s repo to github.com/openmrs. It would alleviate the trouble of adding and removing someone from the Transfer Team.

1 Like

Good question. While we don’t need GitHub wiki/issues (since we use our wiki & JIRA for all repos), The primary reason to transfer ownership is so any forks of their repo will automatically follow it. A smaller (less commonly used) benefit would be maintaining any webhook, services, or deploy keys.

Temporarily making the individual an admin of the OpenMRS org (via the “Transfer Team” assignment) seemed like the easiest approach (minimal effort for us – given their github username, it takes less than 30 seconds of effort to add & later remove them from the tream – and, importantly, the requestor is responsible for actually perfomring the transfer).

Historically, we have required two /dev/5s to agree (i.e., +2). Assuming there’s a /dev/5 associated with the request (e.g., a mentor), then it only takes +1 to get to +2. :thumbsup: :thumbsup:

Did we ever sort out what it actually means for a repository to be moved to the OpenMRS organization on GitHub? We have been talking about for a long time (years) now.

Specifically:

  • Is the owner of the code base still the same as it was before the move?
  • Are the maintainers still the same? Are other maintainers added?
  • What is the expectation as to level of ongoing support and currency/maintenance of projects in the OpenMRS organization?

Update: It appears that these criteria are outlined at https://wiki.openmrs.org/display/docs/GitHub+Code+of+Conduct#GitHubCodeofConduct-HostingamoduleundertheOpenMRSorganization. See below for the criteria, but I think the questions above are still open.

  • Community-developed or community-owned. (How is this evaluated?)
  • Designed to be used by multiple organizations.
  • Open source.

Another 6 months have passed with no response, so I’m pinging this topic again to see where we are on answering the questions above, as well as for clarification about the roles & responsibility for /dev/5’s in managing our repositories.

Moving a repository under OpenMRS implies collaboration on the repo and, as a result, the community can do what it wants with the repository (move it, rename it, push to it, etc.). So, it implies at least co-ownership with the community.

Migrating a repo under OpenMRS does not require that maintainers change nor imply that there will suddenly be more maintainers. Community devs will gain privileges to the repo, but should follow our code of conduct.

Currently, none. Personally, I’d prefer OpenMRS to be a “clean” list of actively supported community repos, people building code for the community could host it under their own account in most cases, and we’d have a separate “openmrs-legacy” org as a graveyard for legacy repos. But entropy appears to be winning.

Creating an “openmrs-legacy” or “openmrs-graveyard” org is probably a separate discussion (not in this thread). If anyone thinks it’s worth having, I’m happy to weigh the pros & cons.

+1. I’d propose that we enable repository creation (i.e., turn on the “Allow members to create repositories for this organization” option), so anybody on any team could add a repo and manage this socially – i.e., anyone/everyone who wants to create or migrate a repo under the OpenMRS org needs to come here first, but once agreed, they’d have no barrier to migrate their repository.

These two statements seem at worst in conflict, and at best ambiguous (IMHO). Have we defined “co-ownership with the community” anywhere? Is it /dev/5 that decides what projects will be co-owned by the community? Are there any criteria or guidance for someone’s project (to meet or to aim for) before that decision is made?

Anyone including /dev/null? Seems like this privelege (wherever it lies) should probably be listed on: https://wiki.openmrs.org/display/RES/OpenMRS+Developer+Stages

If you believe someone would transfer a repo under the OpenMRS organization in GitHub and believe they continue to have independent authority over that repository, then we certainly use some documentation to clarify.

Perhaps the ambiguity comes from the term “ownership”:

  • Ownership meaning the ability to rename, migrate, or make changes to the repository. This is shared.

  • Ownership meaning the responsibility to maintain or support users of the code in the repository. This is not automatic inherited by the community. If that’s the case, then there are many repos that need to be removed from the OpenMRS organization in GitHub.

I assumed the “Allow members to create repositories for this organization” was referring to members of the OpenMRS organization – i.e., someone on any of our teams in GitHub. In that case, it would only apply to /dev/2 and above (since a /dev/null is unknown to OpenMRS in GitHub and, since a /dev/1 only has read access just like anyone else with a GitHub account, we could remove that as a team in GitHub).

It’s a good point that we’d want to include this in http://om.rs/devstages.

1 Like

I agree with:

  • /dev/5s approve adding a repo to the OpenMRS org
  • /dev/2+ have privs to carry out the action
  • need to document explicit guidance of what belongs under the OpenMRS github org

Also:

  • my preference is that adding a repo under the OpenMRS org implies that OpenMRS project management will actively try to corral volunteer resources to maintain the repo (I.e. just “multiple community devs want to work on this repo” is not sufficient.)
  • I agree with Burke that we should push to have less in the “official” OpenMRS repo, including moving some existing stuff out, but that we’d need another alternative repo to make this happen. (I don’t like his proposed names, but that should go in another thread.)

FYI – I noted the privilege on http://om.rs/devstages and have enabled the option to allow community members to create repositories. We’ll keep an eye on it. If people creating or adding repositories under OpenMRS without following conventions & first discussing in this category, then we can turn it off and go back to moderation.

On a side note, our existing approach of temporarily assigning the person to the “Transfer Team” (created before GitHub changed their permissions) still works, so we should hold onto that team and avoid migrating it in case we need to fall back to using it later.