We are having less number of intro tickets for new comers to work on. Can relevant developers and repo owners add more intro tickets with intro label? Current intro tickets are in [1]. There are quite old tickets which we need to revisit. Some are seems not intro tickets. I believe there should be existing tickets which we need to tag with intro label.
@dkayiwa itās around 29. But when I go through them there more than half of them is not that much easy to follow for new comer who donāt have much knowledge. So we either need to do a revisit and create less complex tickets. It might be minor UI fixes, minor issues.
I agree with @harsha89, intro tickets are not just āeasy workā, theyāre often the first taste of OpenMRS that many people will get. Given that GSoC is also approaching, I think it would be a good idea if we can sit down and come up with some more intro tickets designed to make a few volunteers fall in love with OpenMRS
@dkayiwa, if you have some good intro ticket ideas, but not enough time to create detailed tickets, iād be happy to create them for you
@surangak@harsha89
We usually go through the list of tickets across all modules, and the platform, and add intro labels, put some more explanations, to those we feel like so. My recommendation is that at any one time, feel free to go through this pool and curate those tickets that you feel are good for newbies. In other words, let us, as the community, make it an ongoing habit to once in a while spare some time to add more to this list. Do not wait for permission from anyone, you are already empowered to do so. Does it make sense?
Harsha is asking for someone to be responsible for moving customer requests into workable issues. This is not his responsibility as the head of our Guides program ā he is tasked with matching people to that work (that doesnāt exist).
I echo the call of @harsha89 & @surangak in getting our software engineering leaders, including our /dev/5ās and other higher levels, to figure out someone to be responsible for this. It is a travesty that weāre 10 years old and still havenāt figured out how to do this reliably. After talking about it for several years, we still donāt have clear product managers, BAās, or anyone working our feature pipeline. So letās fix that. How can I help?
Iām getting several requests from new comers to point to some intro tickets. I also went through the trunk tickets, most of them are in medium complexity.
@dkayiwa currently what are the modules and component are at under heavy developments? So we should have new tickets from those modules to point to them
In theory, there is always someone dedicated as the āCommunity Development Leadā and one of this personās responsibilities is ensuring that there are enough good intro and curated tickets.
@dkayiwa, is there a job description for this role on the wiki?
Also, to everyone, we welcome others who might want to participate in the rotation of Community Dev Leads: it generally rotates on a 2-week basis.
(As an insufficient step, @jthomas, please ensure that we spend 5 minutes on every PM call verifying that there are enough āintroā and ācuratedā tickets, in addition to the ācommunity-priorityā look weāre doing.)
None of those wiki pages explicitly lists things you must definitely due
over the course of a week as the Community Dev Lead.
It would be great if those who have rotating through the role (@dkayiwa,
@wyclif, @raff) could document that, so that (a) we can look for more
volunteers to do this, and (b) we can think about measurements of whether
this is actually working.
+1, i think that can be a good step to keep this wonderful intro list populated with issues that are fitting to newbies just as @harsha89 is doing a great work with the OpenMRS Guideās program.
Are we going to have a meeting to discuss on strategy to discuss about creating and moving existing tickets to intro tickets?
Currently Iām getting several requests from new comers. We might need some brainstorming.
We should have a meeting like that (and I invite you to organize it!).
That said, I have a question: it seems to me that there are actually 28
āintroā tickets marked as ready for work. Given that, why are people
requesting more? Are these intro tickets actually not well-written? Are
they too boring?
These are some examples. There are several other tickets like this. We might need to run on those ticket and evaluate them again. I think it wonāt take much time. Some tickets are boring because they dragged too much. When new comers going through them, I feel their first impression is not good that the reason they asking point them to good intro ticket.
I have dropped a message to Downey and Suranga to arrange a meeting. Will do the needful soon.
And we should feel free to cancel tickets as Wonāt Fix other tickets of limited value. (E.g. in this case open for 4+ years, without any comments expressing real interest, and not providing any particular value over running OpenMRS on an open source stack.)
I have a general announcemnt emai drafted. It āgsoc-2016ā okay for a label
for non-intro tickets that GSoC should consider?
-Burke
Hereās a preview of what I have drafted on Talk for the Developers category
and waiting for me to hit the create topic button:
Attention OpenMRS Devs!The bad news:
We have an influx of GSoC students coming to the community NOW and we do
not have an organized list of tasks 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 the 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 newcomes.
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
https://github.com/openmrs/openmrs-core/blob/master/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
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.