Hacking on trivial Launchpad bugs
The Launchpad registry team has a zero-trivial bugs policy. Last year we observed that trivial bugs, though they are often low priority, they have the highest certainty to be fixed and are very visible to users. We decided that since an engineer can close 8 bugs in a day of work, there should never be more than 8 trivial bugs in the project.
I had a lot of meeting this week. I was too distracted to commit to working on a bug issue. I decided to start a branch that I could fix trivial bugs in between meetings. After a day of meeting, I had a branch that was ready for review.
We I say trivial bugs have the highest certainty to be fixed, I am referring to my own primer on bug triage. There is almost no risk in fixing the bug, and since we will know in an hour instead of days whether our efforts fixed the issue, trivial bugs have an intrinsic high priority. I really cannot say every trivial bug is high priority, but when I consider several of them together, they are high priority.
Most trivial bugs are grammatical errors, presentation issues, or navigation issues that do not stop users from accomplishing their task. Trivial bugs are obviously easy to fix, and users are reminded of them every time they repeat their task. These bugs are very annoying, they amplify the user's perception of poor quality. Engineers can make a big improvement in user experience by fixing trivial bugs.