Newly created issues in Github go into a "New Issues" column in Zenhub. These issues are marked by product owners as "On Deck" when they're prioritized for work on the next work cycle.
When a work cycle is coming up for a project those issues are migrated to the "Under Consideration" column in the work cycle planning board. Those issues are then reviewed during a work cycle planning meeting by the team and product owner, and if they will be worked on that work cycle are assigned the "work-cycle" label.
Issues which severely impact the library staff's ability to work are top priority, and so able to disrupt the normal rhythm of work cycles. However, being pulled away from a work cycle is distracting, expensive, and will likely negatively impact the goals of that cycle. Therefore, it's important to keep track of when they happen and why they're important so we can move towards greater cycle stability.
If a "sudden priority" issue comes up, a product owner should do the following:
- Create the Github issue. Include as much information as possible.
- Add a "Sudden Priority" justification section. This should include how staff's work is being impacted and why there are no suitable workarounds. Please also include how urgent the priority is - can it wait until a couple weeks until the next maintenance week, or must it be done immediately?
- Add the "sudden-priority" label to the issue.
- Send a message in Slack to the "digital_library" channel so DLS knows to begin acting on the issue.
DLS should then do the following:
- Ensure the issue is actionable.
- Give the issue a "work-cycle" or "maintenance/research" label depending on which week in the work cycle is (or maintenance/research if the issue can be delayed until then), and pin it in Zenhub. Move it to the "Ready" column for that week.
The DLS Lead reserves the right to remove the sudden-priority label if they make a call that the issue is best delayed until the next project work cycle or a regularly scheduled maintenance/research week. If they do so, the issue will be marked as "on-deck" and pinned in the work cycle planning or maintenance board, as appropriate.
Example of a sudden priority issue: figgy/4811
Sudden priority issues will be reviewed on at least a yearly basis in an effort to identify the kind of work which has most often pulled us away, and how we might get ahead of those kinds of problems.
Some guidelines follow which make an issue actionable and thus able to be added to a work cycle. Developers and product owners can use the following to determine if an issue is "ready."
- Title is clear and concise
- Expected behavior
- Actual behavior (do we have screenshots, links, browser version if relevant?)
- Steps to replicate
- Clear acceptance criteria: "This issue can be closed when the following is true"
- Impact on user is clear
- Title is clear and concise
- Description includes a user story: "As a __ I need __ in order to __"
- Provides actual or sample data: Do we have a case to develop and test against?
- Clear acceptance criteria: "This issue can be closed when the following is true"