One Hundred Paper Cuts is off to a great start. After my last post, many people began adding existing bugs to the project, and filing new bugs as paper cuts. Now we have hundreds of bugs filed, and we will probably have hundreds more by the end of the week, but many of the bugs are not paper cuts. Some people are confused because, although every paper cut is a usability bug, not all usability bugs are paper cuts; also, although we have committed to fixing one hundred paper cuts, when your bug does not qualify as a paper cut, that does not mean we do not think it’s a great bug that should be fixed.
As a reminder, a paper cut is:
- Very easy to fix.
- A bug that, if fixed, makes Ubuntu more usable for a significant percentage of users.
- A bug that affects a default install of Ubuntu 9.10. A good rule of thumb: if the bug affects an application that is not in the applications menu by default, it is probably not a paper cut. We are looking for “ambient paper cuts,” little glitches a user might encounter many times during the day.
A paper cut is not:
- A new feature. If it requires writing more than a few lines of code, or adds any new visual elements to an interface, it’s probably not a paper cut.
Now that everyone is posting their pet usability bugs as paper cuts, we need to start filtering out the noise to find the hundred paper cuts to fix for Karmic. Here are all of the new paper cuts. Please take a moment to go through one or two of them, and mark them invalid if they fail to meet any of the positive criteria above, or if they meet any of the negative criteria listed.
- If you find a bug that only affects a small number of specialized users (like this one), mark the bug invalid in hundredpapercuts with the comment “This is not a paper cut because it is not a general usability issue, but rather a bug affecting a relatively small user population.“
- If you find a bug that is not trivial to fix (like this one), mark the bug invalid in hundredpapercuts with the comment like “this bug is not trivially fixable, so it is not a paper cut.” If you are not sure whether a bug is trivial to fix or not, just leave it alone.
- If the bug is a vague rant about someone’s problems with Ubuntu (like this one), patiently ask the poster to identify the particular issue they believe to be a paper cut. If they cannot identify one, kindly mark the bug as invalid in hundredpapercuts.
- Only take any of these recommended actions if you are very confident that your decision to mark the bug invalid is correct. There is absolutely no harm in leaving the bug for someone else to adjudicate; however, there is harm if you mark a good paper cut invalid by mistake.
When reporting a new paper cut, please make an effort to identify the other projects affected by the bug. If you can go so far as to search upstream bug trackers first, and file paper cuts there, that would be incredibly helpful. Many people are reporting new bugs in hundredpapercuts without bothering to report the bug against the software project that is actually affected. If you can identify the actual project affected (for example, gnome-panel or network-manager), please mark the bug as affecting that project.
Finally, let me reiterate–when a bug is marked invalid in hundredpapercuts, that doesn’t imply that it’s not a good bug, that it doesn’t affect user experience, or that it won’t be fixed in Karmic. Thanks!
Edit: If you believe very strongly that a bug is a paper cut, mark the bug confirmed. Please don’t try to elevate the status of your non-papercut bug by marking it confirmed, because others will catch it and just mark it invalid! Everyone believes their bug is a paper cut, so avoid marking your own bugs confirmed–let a third party confirm it.
6 comments
This is why I love open source: the community working together. Thanks to you and everyone for this awesome work.
Good summary! For people helping out with triaging, do you want us to do anything with bugs that we can confirm ARE paper cuts, and if so should those be set as Confirmed or Triaged? Perhaps Triaged could be more useful as that means it wasn’t set by a random person.
Mike, I’ve addressed your comment at the bottom of the post — thanks!
“A new feature. If it requires writing more than a few lines of code, or adds any new visual elements to an interface, it’s probably not a paper cut.”
How are users supposed to know if a minor fix will take more than a few lines of code? And often the addition of a minor UI element might only be a few lines of code and provide a huge improvement (such as a button, icon, or UI effect).
Can you clarify this a little more? Or will you just make exceptions for the ones you can discern as easy to fix?
Celeste,
I am not suggesting that users would know whether a fix involves writing 1 or 1,000 lines of code. In fact, I believe most users won’t even know a paper cut is there when they experience one. What I meant to say, is that if someone participating in this project is able to determine with a good deal of certainty that a fix would require writing new code, then they should mark the bug as not being a paper cut. I did not say that users would know this, I even express doubt that project participants would be able to make this determination: “if you are not sure whether a bug is trivial to fix or not, just leave it alone.”
I also realize that the addition of “minor UI element” could improve usability greatly, but that is not the kind of usability improvement we are calling a “paper cut.” It has been really tempting for people to report any and all usability bugs, but our goal is to solve 100 extremely subtle, “ambient” usability issues. The more subtle the bug, the better — the perfect paper cut is something users never notice, but if fixed would improve usability in an ineffable manner. The addition of even a minor UI element is not a paper cut in this sense.
I hope that made sense… I am exhausted from sifting through bugs all day
I still think we’re a little wooly on what makes a papercut a papercut, and I’m still bitter that the old copy/paste issue didn’t make it into the hundred
, but I’m pretty excited about this project. If even half of these issues are resolved, it’s going to be not just a better Ubuntu, but a better Gnome, since so many of these issues are upstream. Nautilus features very heavily, but even metacity bugs are making the grade. Great stuff.
Trackbacks/Pingbacks (4)
[...] Further reading: Jorge’s Stompbox: Papercut Time Launchpad: One Hundred Paper Cuts project page David Siegle: One Hundred Paper Cuts David Siegle: Calling All Paper Cutters [...]
[...] As part of the 100 paper cuts project that we are running for the next Ubuntu release we are focussing on small usability problems that, if fixed, will make the Ubuntu desktop experience feel smoother, safer, better. [...]
[...] of you may have heard about Canonical’s new 100 papercuts project (more info). The goal is to fix 100 minor usability bugs for the Karmic release. Although the primary focus is [...]
[...] is plenty more information regarding 100 Paper Cuts, its initial progress and integration/planning for Kubuntu. Please comment and tell me, what do you think of the [...]