Attention All OpenMRS Devs!
The bad news:
We have an influx of GSoC students coming to the community RIGHT NOW and we do not have tasks ready for them. We literally have students looking at our pool of tickets and stumbling through old tickets trying to find good work to do!
The good news:
You could get some work done for “free” if you take a little time NOW to curate some tickets.
We want to fix for you the little things you haven’t had time to do. If you have an easy ticket with a clear summary of what needs to be done, label it as
introto get it into our pool of intro tickets for newcomers.
We want to fix for you some slightly bigger things. Many of the GSoC hopefuls have strong coding skills and can quickly surpass the
introlevel. If you have ready-for-work tickets with a clear description that doesn’t assume someone is already working on your project, label the ticket as
gsoc-2016to get it on our radar.
What you need to do to benefit
Are you a module owner? Are you an implementer with requests for simple things that have too-long gone ignored? Here’s your chance: take a look at your project’s tickets in JIRA from the perspective of someone new to the community. How many “shovel ready” tickets do you have?
Get your intro tickets ready now. Clean up the summary & description of any small, simple tasks and label them as
intro. If you know of small, simple tasks that are not yet ticketed, this would be a good time to describe them in an
introticket to leverage the current wave of GSoC students.
Get some non-intro tickets ready now. Clean up the summary & description of any tasks that could be tackled by a skilled developer new to the project within a few days or week or effort. Label them as
gsoc-2016to get them on our radar.
- Make sure people know how to contribute. Ideally, module repos should begin following the GitHub convention of having a CONTRIBUTING.md file (like openmrs-core/CONTRIBUTING.md describing how someone can contribute to the module. If you don’t have time to make a CONTRIBUTING.md file, at least make sure your module’s wiki page contains instructions for how a contributor can set up a development environment and, for now, make a CONTRIBUTING.md file pointing people to that wiki page. If your documentation is missing or stale, this is the best time to clean it up, since doing so now can easily lead to students contributing to your project over the upcoming weeks.
We will be keeping an eye on tickets labeled
gsoc-2016 and directing students toward them.
intro– any ticket that requires minimal developer skills or time. This could be correcting a typo, doing something trivial in a bunch of well-defined places, etc.
gsoc-2016– any ticket appropriate for a /dev/1 or /dev/2 (strong coder new to OpenMRS) could tackle in a few days of effort or less. Must be well-defined and appropriate for someone new to the module/project, but does not have to be an introductory ticket.
Please do NOT label tickets as
gsoc-2016 if they do not have a clear summary & description and are ready for work. Doing so is counter-productive and is likely to discourage students from working on your project and within the OpenMRS community. If you see a ticket with one of these labels that is not clearly described & read for work, please either clean up the ticket or remove the label.
@dkayiwa, @raff, @wyclif: The Community Development Swim Lane should be curating intro and non-intro tickets for the Platform 2.0 release (openmrs-core, REST module, FHIR module, OWA module, and legacyui module).