We need to move the OT module code to OpenMRS org in Git Hub
Current repo : https://github.com/merovingienne/openmrs-module-operationtheater
Thank you. 
@akshika47, please clarify a bit.
Generally we don’t move repos for GSOC into the openmrs org until they’ve reached a certain level of maturity.
However if it’s already at the point where it has been worked on by multiple OpenMRS people from different organizations, we might move it to the openmrs org.
In this case I see that you’ve pointed to a repo that’s itself a fork (maybe from a previous GSoC project). Wouldn’t we be moving the original repo under openmrs in this case?
Hi ,
The original repo has been done in 2014 years GSOC. And it has been continued in this years GSOC by @merovingienne. Not sure if the original repo owner would like to review pull requests he pushes.
But that could also be a good option. @merovingienne has already made some commits to the forked repo and maybe we can move the repo with those or if you suggest we can move the original repo and ask him to merge those newly made commits to the parent repo after the movement.
What is your opinion?
People should work in forks – move it at the end of GSoC – not before. Whoever is mentoring your project should review your code and merge it periodically.
Hi All,
With regard to GSoC, some students may continue to contribute to OpenMRS and stay longer with the community. But some students will move away with the time due to their interests. So we need to make sure work carried out in the GSoC need to move forward. Students may create new modules or contribute to existing modules. If a student creates a new module, it might not ready for production use straight away. But we need to make sure that code is maintained in somewhere. Because we might need to go through with an another cycle to make it production ready. We may add a new GSoC project to improve the module capability which may be taken up from an another new student. So I think the best place to maintain in under OpenMRS repo with some indication of the project status. We might mention it’s not ready for production yet. If original student deleted the repo, we will loose entire project. So I believe we need to maintain it under OpenMRS repository. I think, maintaining a repository under a particular student or a mentor wouldn’t be a good option.
This is why at the end of the program, you move it – not before.
The general convention (not just for GSoC, but for all OpenMRS developers) is that when you start a new project with only one contributor, you put this in your own github space. (Or, if it’s multiple contributors from the same organization, you might put it in that organization’s github space.)
As the project progresses and gets more mature, and it acquires more contributors who need to collaborate across organizational boundaries, that’s when we’d typically move something into the OpenMRS github space, so that it’s more easily found, and so management can be simplified by applying the OpenMRS github permissions scheme to it. (A special-case of this is if a repo becomes “core-supported”.)
As this applies to GSOC, my preference is that most projects are initially created in the student’s github space, not in OpenMRS’s, but later in the summer, once the project is more mature, one of the activities is to move the repo under OpenMRS. In fact this migration/forking is an open-source workflow that people should be practicing during GSOC.
Of course if a student is working on a project that’s already under OpenMRS’s github space, it stays there.
In this specific case, this student is picking up a module from a previous GSOC (2014?) that wasn’t moved into the OpenMRS space. My recommendation is to do either of two things:
- Ask the student from 2014 to transfer the repo over into the OpenMRS space to continue work
- Continue working on this fork, and move the fork into the OpenMRS space at the end of the summer
3 Likes
@darius Agreed We will move this to OpenMRS space end of this summer. @akshika47 @merovingienne please note.
1 Like
Got it @harsha89. I’ll continue working on my fork.
Thanks everyone for your input
1 Like