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 intro to 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 intro level. 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-2016 to 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 intro ticket 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-2016 to 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 intro and gsoc-2016 and directing students toward them.
Cheers,
-Burke
Label definitions
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.
p.s.
Please do NOT label tickets as intro or 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.
p.p.s.
@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).
@darius, in this case, I want them to work on adding just the stock classes and link it up to the API level. the mapping of the domain is out of bounds for this task
I have another task that deals with mapping of the domain object, but that specifically lists how the mapping is done. Basically, I took a large ticket, and broke it into incremental smaller tasks that are intro-worthy
Do the legacy UI views have been migrated to Angular yet? It’s a lot of work but most of them are simple CRUDs, with a good functional example it’s a matter of copy and paste.
If I’m understanding this right, yes, this has mostly been done already. The Admin UI module for the Reference Application includes angular-ized versions of all the management pages.
(Actually @wyclif, are there any management screens that haven’t been done in the refapp UI, that can be easily written as intro tickets?)
It’s in my plan sometime in the near future to create some tickets for next release of the module, and one of the to dos is to add the remaining management pages
@maurya, I wonder if we can break up the OHDSI module work into intro tasks - I know we were planning to develop some UI and all that… maybe this, and other stuff like validations etc. can be new intro tickets ?
By looking at the demo only apps, global properties and accounts have a new UI.
Advanced administration shows the legacy UI admin page (I assume with the old UI screens).
Also, the grids in apps and global properties do not provide sorting or (Ajax) paging, which I consider very useful. Exporting to Excel and PDF will be great too. This kind of widget could easily be a GSoC project instead of intro tickets.
Actually there is more there. We split things up so some things are under “Configure Metadata”, while the ones you mention are under “System Administration”.
