Continuing the discussion from URGENT: We've got more developers than well-defined work!:
During the call for tickets for prospective GSoC 2016 students, we realized we could benefit from a clearer convention for labeling tickets appropriate for general community consumption.
We currently have two labels:
intro– trivial task requiring minimal technical skill
community-priority– tasks that are a priority for the OpenMRS Community (e.g., tasks important for community milestones)
intro is generally well-understood to label tickets that someone brand new to the community could tackle; however, we don’t have a convention for labeling tickets beyond the introductory level.
A simple, easily understood (ideally self-evident) scheme for labeling tickets such that people new to the community can more easily identify tickets appropriate to their level of skills & comfort with OpenMRS.
dev-null– requires little to no technical skill (equivalent to an easy
introticket or GCI task). wouldn’t be included on a community dev sprint (too simple).
dev-1– requires basic coding skills but little-to-no domain knowledge and could be accomplished in isolation (equivalent to an
introticket that requires programming). could be an intro ticket on a community dev sprint.
dev-2– requires decent coding skills and may require some basic knowledge of OpenMRS, but does not require knowledge of the module/project to accomplish. could easily be a ticket on a community dev sprint.
dev-3– requires strong coding skills and would likely require coordinating work with others, may require some basic knowledge of the module/project. could be a medium-to-high level sprint ticket.
dev-4– requires strong coding skills and knowledge or experience with the module/project, but could be accomplished by someone new to the module/project if they spend time researching the issue and working with dev(s) on the module/project. could be a complex ticket for a sprint.
dev-5– step away from the ticket! it requires guru skills or in-depth knowledge or experience with the module/project (if you haven’t been working on this module/project, this probably isn’t for you). might be a sprint in itself.
It seems intuitive to me, but, then again, I’ve been involved in dev staging from the start. I do like, however, that is doubles down on communicating & understanding dev stages in our community (i.e., making it part of our culture). What do you think?