Language portal/Task Priority

Priority levels defined for Language Engineering tickets on Phabricator

Unbreak Now

• Affects all users of Content_translation or all Wikipedias where Content_translation is deployed
• Translate cannot be used on Wikimedia sites due to a failure
• UniversalLanguageSelector breaks in a major way; for instance, the input methods are unusable

High

• Content Translation is unusable, e.g. publishing errors
• Affects a significantly large group of users
• The reported problem has no workaround

Normal

• The reported problem has a hard to identify/implement workaround

Low

• Minor enhancement requests

Needs Triage

• If there is no information to proceed at all
• Request the reporter to respond to questions that may help determine the expectations
• Timebox the response time and close if no response is received
• Avoid putting an arbitrary priority for a ticket with no usable information

Apportioning within Sprints - Content Translation

• The release board (with the grouping columns) will be kept prioritized
• At the time of sprint planning, the high priority items from the release board (a judicious number) are picked
• After identifying the sprint items, they can be reprioritized within the sprint board. It is preferable that a maximum of 1/3rd number of the total tickets are of high priority
• Unplanned feature items are not brought into the sprint
• If someone finishes their planned tasks ahead of time, then they can choose from the prioritized tickets in the bugs column on the release board
• If new feature requests are received during the sprint, then it has to go into the release board (either the current or the next) and prioritized for consideration in a subsequent sprint.
• New bugs are added to the bugs column on the release board

Apportioning within Sprints - Other Projects

• 16 hours for each sprint will be reserved for non-CX projects (this may change based on effectiveness)
• The primary projects that fall under this group are Translate and ULS. For both of these projects, a list of candidate tasks that can be attempted during the 16 allotted hours of each sprint needs to be prepared from the phabricator/github backlog.
• During the mid-sprint meeting or sprint planning meeting or over email, these tasks are presented and, depending on priority and availability of people, they are included in the sprint.
• If for any sprint, no candidate tasks are identified then the team is free to reuse these 16 hours for Content Translation or other tasks.
• For major feature work, the requirements need to be worked out by the PM with the responsible SE and UX team member so that it can be planned and scheduled in a meaningful way