Plan on transferring repositories created by students [GCI]

[ixWDE4eR]

Hi.

During GCI some repositories requiring continuous support (such as OpenMRS OpenShift Quickstart cartridge or Docker image (which should be updated (and tested after updates))) have been created by students. These should probably be transferred to the OpenMRS github group (after some polishing maybe (with which I could help BTW)). Is there a plan for this?

Thanks,

Dmitrii.

[Parker]

Related: When does a repo go under OpenMRS org? Do they ever leave? on OpenMRS talk. It seems to have become slightly inactive, but it looks like the almost-consensus (don't quote me on this) is that individual contributors can own their own projects on GitHub.

I made one of these projects during GCI - the iOS app. The main problem is that I'm the primary contributor right now, and if we put the repo under the OpenMRS GitHub org I either 

(a) won't have commit access to it, which makes no sense, or 

(b) will have commit access to it *and core*, which also doesn't make any sense because I'm far too prone to break important non-iOS app things.

We could make teams within the OpenMRS organization, but at that point we've added a whole layer of meta-complexity that we don't really need.

Anyway, those are my thoughts :)

Parker

--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions at http://om.rs/id
 
Register today for our Maputo 2015 Implementers Meeting: http://om.rs/moz15

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.

[ixWDE4eR]

> individual contributors can own their own projects on GitHub

This does not look like a good practice to me. The projects we have stated so far are being referred to on the official wiki, which may make people think they are supported well. Quality assurance, though, does not seem very possible without constant monitoring and such, which is probably more problematic if the project is scattered all over github. Another problem is "individual contributors" come and go, and I'm not exactly sure we should rely solely on them (ex.: a critical vulnerability gets discovered while the contributor is unavailable. Everybody either waits to get MR into master or forks. Both do not look like best solutions possible.). Lastly, trust should also be considered (an OpenMRS snapshot from github.com/openmrs looks far more legit than one from github.com/$some_random_string).

> teams <...> we don't really need

It's probably the best option if the projects are to be transferred. And I'm not quite sure what's wrong with ACL. Is it considered harmful?

Anyway, it's probably mostly about 'status' of these projects. If they are to be considered more or less 'official' (enterprise, production, etc.) I believe they have to be under the 'official' OpenMRS group (applies not only to github, but ex. dockerhub too).

Dmitrii.

[Robby O'Connor]

Git is decentralized,  you can always continue to do pull requests...and eventually get commit privileges

--Rob
Sent from my cell, please excuse any typos.

[Michael Downey]

Hi Dmitrii,

We just had a productive community meeting about this on Thursday. You can go to http://go.openmrs.org/devmtg to see notes and listen to a recording to learn more of the latest developments.

Michael

[ixWDE4eR]

Robert,

I'm asking about a situation when no corresponding project exists in github.com/openmrs (and one of the ways of solving it is creating one and having individual contributors do pull requests, yes).

But doesn't ACL seem like a good idea in this case? A person developing an image for cloud platform/mobile client/etc. probably should not be able to commit to core's master, which seems to be the case in your proposition.