We encounter this case where multiple students can work on a specific task. For example if multiple students work on a task which fix code formatting and and bad code practices, there we will have multiple pull requests from students to the openmrs core. We needs to manage both tasks address by pull requests. As we discuss on this on github, @dkayiwa has suggest to use subtasks for each parent task on that cases. As @sunbiz pointed out, there may be some limitations on it.
What would be the best approach to handle these situations? We needs to give student feeling that they have done a contribution. For that we will need to review the pull request and merge it to the repository. How we going to dealt with this situations?
I agree with @michael which is why if the review (for the code style changes) is fine and the code is compiling, we should accept that the task is done.
I personally would vote for having sub-tasks to give our students a felling of ownership of the issues they are working on. what do others have to say about sub tasks so that we have specific students assigned to specific issues, and they can request review and move on to work on other issue as they wait review, here is what we discussed on github according to @harsha89’s post here: https://github.com/openmrs/openmrs-core/pull/1172
I would like the infrastructure team to comment on this. I feel too many JIRA issues will be duplicates and are only mockups of actual ticket, which is one broad issue of code style fixes. But I agree that without merging changes into one branch, students might work on the same thing… the worry I have is that we dont want code to go into trunk without good review.
@k_joseph , can you create a gci branch in openmrs-core that students can fork and we will merge to this. That way we can be sure that students are not replicating each other’s work
When I was handling with JIRA tickets, I was extremely frustrated as I wasn’t able to move my own tickets to review, or close them - even if I was the one assigned to it.
I don’t know how others feel about it, if it was just configuration problem or what, but as a developer, I feel I should be able to move the ticket around.
Creating a new branch will be good. But again student needs to be more familiar with with branching strategy. It will make things complex from their side. It’s more like a trade-off, we will needs to move with this option since we may not have any other options. Additional set of guidelines will make this easier from their side.
Agreed. We are not trying to duplicate effort. Melange is the canonical “task tracker” for GCI. We use JIRA issues for GCI tasks only to provide additional background. The GCI JIRA project is a special case for this reason and should not be handled like our normal JIRA issues.
Since the program is already running let us not change that approach at this point to avoid confusion. However, we can do a retrospective assessment and improve next time around.
I’m running into a slightly similar problem: I am okay with merging students’ work into master of my project, but multiple students will be duplicating each others’ work. How should I organize this so that each student gets the experience of submitting a PR, but I am still able to determine whose code goes into the final release?
Students should NOT be duplicating work! This is inefficient for
us…the goal is to get meaningful code…I am firmly against this…if
a student completes a task…close the ticket and when they’re
done…they’re done.
Let’s focus, folks. Some tasks are repeatable, like beginner tasks, or UI
type tasks where you need a few ideas, or “fix N things of many”. Many but
not all of our tasks are in these categories.
@sunbiz or @surangak, please ask this question on the mentors GCI list or
ask Joel for ideas.