Reading: https://hackernoon.com/bugs-priority-3b5cf5f6aadd#.6dea1eo0d
- Maintaining software is about tradeoffs
- Shared understanding of tradeoffs is important
- Tracking bugs is important
- What priority means?
- What else should we be using?
- Depends on the person prioritizing
- I disagree, I think many times there are standards for our priorities
- Seems to make the assumption that there is one person setting priority on tasks…not really “at scale”
- But…it is most of the time….
- How do we get everyone on the same page?
- e.g., crash/data loss/cosmetic
- Is it happening all the time?
- Is it happening at a very low rate?
- Understanding variables key to standardizing decisions
- Chart for each company is different, only important that people agree
- Process should be flexible enough to break from time-to-time
- Structured data around what kind of defects you have
- Let’s you build reporting in your bug tracker
- More informed about trade-offs
- We never answered what priority means or what else we should be using
- The second “problem” with priorities is not addressed at all:
- That is, priority list can be changed
- If the list of priorities change, then your carefully crafted chart no longer works
- This is a non-problem anyway, not sure why it’s in here
- The only valuable part is the chart and the idea that dimensions of priority should be made explicit
- Reminds me of “issues that hold the train” and our example emergencies
- We have guidelines for bug SLO response times https://www.mediawiki.org/wiki/Code_Stewardship#Base_Service_Level_Objectives_(SLO)
- https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Bug_triage