Karmic Retrospective
Long story short: we fixed 76 paper cuts for Karmic. Hooray! Congratulations! For more details, see the Ubuntu wiki page.
(I believe we actually reached 100, but many paper cuts were fixed without being reported or carefully tracked, and some individual paper cuts addressed multiple instances of a general of problem.)
What about Lucid?
At the Ubuntu Developer Summit last week in Dallas, the Canonical Design team; members of the papercutters team; and representatives from the Ubuntu community agreed to tackle one hundred paper cuts for Lucid. As an LTS (Long Term Support) release, Lucid is a fantastic opportunity for us to use the One Hundred Paper Cuts project to enrich the experience of LTS users by delivering a polished release that will stand the test of time. Bear in mind that paper cuts that go unfixed in Lucid will affect LTS users for years to come, so each opportunity to fix a paper cut is momentous. Luckily, very few disruptive changes are being introduced in Lucid, so we will be able to spend less time adjusting to major changes, and more time nailing the details.
Here are descriptions of the ten milestones structuring our effort to fix one hundred paper cuts for Lucid (see the Lucid series on Launchpad):
- Round 1 “Kibosh on Karmic” (2009-12-03)
- In Round 1, our goal is to fix ten of the fifteen paper cuts from the Karmic cycle that had patches attached but were not merged. After some discussion with Rick “Quickly” Spencer–the Ubuntu Desktop Team lead–we’ve established a more comprehensive workflow for landing paper cut fixes in Ubuntu: in the Lucid cycle, paper cuts with patches attached should be assigned to “canonical-desktop-team,” and “ubuntu-main-sponsors” should be subscribed to the bug report to prevent patches from languishing.
- Round 2 “Kibosh on Karmic” (2009-12-10)
- In Round 2, our goal is to fix the remaining paper cuts from the Karmic cycle with patches attached. Additional unfixed paper cuts from the Karmic cycle will be moved to this milestone to make an even ten.
- Round 3 “Kibosh on Karmic” (2009-12-17)
- In Round 3, we will finish fixing the leftover paper cuts from the Karmic cycle.
- Round 4 “Paper Jam: Empathy” (2010-01-07)
- Round 4 will be our first “Paper Jam.” A Paper Jam is a milestone where a majority of the paper cuts are taken from a particular domain of user experience. Our first Paper Jam will focus on Empathy; this milestone should contain paper cuts affecting Empathy’s user experience.
- Round 5 “Paper Jam: Gwibber” (2010-01-14)
- Gwibber is shipping by default in Lucid. Let’s help it make a great first impression.
- Round 6 “Paper Jam: Sound & Video” (2010-01-21)
- Movie Player, Rhythmbox, and maybe PiTiVi. These are very solid applications, so this milestone will be challenging!
- Round 7 “Paper Jam: F-Spot” (2010-01-28)
- With the removal of the GIMP from the default install, more weight is being placed on F-Spot’s shoulders — especially viewer mode.
- Round 8 “Paper Jam: Notifications” (2010-02-04)
- Fixing notification priorities and any other vagaries that pop up (ha!).
- Round 9 “Paper Jam: Compiz Settings” (2010-02-11)
- Clean up animations, make appearance consistent with Ubuntu’s look and feel, improve discoverability of Scale and other useful features, etc.
- Round 10 “Fin” (2010-02-18)
- Odds and ends.
As you can see, the One Hundred Paper Cuts effort for Lucid will look very much like the One Hundred Paper Cuts effort for Karmic, except that most of the milestones are organized around threads of user experience.
Documenting Design Decisions
In the Karmic cycle, it was often difficult to find the relevant design decisions buried in bug activity and comments. One important change to observe for the Lucid cycle is that paper cut design decisions should be documented separately on the Ubuntu wiki. When a paper cut needs an explicit design specification, append the following line to the bug description:
Design Spec: http://wiki.ubuntu.com/OneHundredPaperCuts/Spec/<bug id>
And document the design decisions there. Here’s an example spec for the unfinished Karmic paper cut, “Home Folder” has 3 different names. If you’d like to propose a solution, do not merely post a comment on the bug report; rather, please use the following template to record a solution in the design spec:
== Solution: <solution name> ==
=== Description ===
# Succinctly describe the solution.
=== Advantages ===
# List advantages of the solution.
=== Disadvantages ===
# Give at least one disadvantage of the solution.
=== Behavior Changes ===
# Specify behavior changes.
=== String Changes ===
# Specify string (text) changes.
=== Visual Changes ===
# Specify visual changes (e.g. icons).
If you agree or disagree with a proposed solution, feel free to add a bullet point to the appropriate Advantages or Disadvantages section. If you strongly disagree with a proposed solution and find it beyond remedy, please propose an alternate solution.
Sound good? Great, let’s do this!
27 comments
Really great idea and approach since the beginning. Although I miss kubuntu in this.
It’s hard to stick without the (kde) love buit I’ll try it anyway. Project timelord is the uberpapercut solver anyway. 
Even more now that u fix on gnome applications
Cheers
Taking on Gwibber…admirable, if a bit daunting. It certainly needs to be done.
While I think the one hundred paper cuts is a really great idea I am not so certain about the paper jams. They definitively make sense but I think you are missing on the more general problems.
So I would prefer if lets say 40 of the paper cuts are the top 40 requested paper cuts not tied to a specific topic.
E.g. I don’t care about gwibbler since I don’t use something like this and never changed compiz settings… But I have X independent annoyances I would like to see fixed.
I love this idea, but how do you go about submitting papercuts? I’m looking for consistent proxy settings for all gnome apps! Banshee, Gwibber and im sure others could hugely benefit from this.
I know there’s only room for so much, but I’m surprised to not see Evolution on the Paper Jam list. I would put Evolution over any of these application especially for a LTS release where companies will use it. However, this is cool nonetheless and I really enjoy the whole Paper Cut idea.
I’m in the same boat as Fabian.
In the first round, the number of bugs marked ‘Invalid’ in the project outnumber of fixed papercuts roughly ten to one: https://bugs.launchpad.net/hundredpapercuts/+bugs?field.status%3Alist=INVALID
To me, this indicates that a lot of people didn’t find out about the (appropriately) limited definition of ‘papercut’ until after they thought they had identified one. Perhaps many were using a less nuanced concept (“UI WTFs that I can think of a simple fix for”
.
The Paper Jams, in one sense, further narrow what is considered a ‘papercut’ at certain points of the process. Without more and better messaging, many more people will go through the roller-coaster of fulfillment and letdown (“Wow, someone finally cares about bug X! … Wait, it’s not in scope? This sucks!”
caused by this misunderstanding.
On a personal note, I feel that papercuts which have a greater “WTF-factor” should be prioritized, regardless of which component they occur in…but of course that’s nearly impossible to judge objectively. Popularity is not quite the same thing.
Hmmm…
Empathy, Gwibber, Movie Player, Rhythmbox, maybe PiTiVi, F-Spot and Compiz are the apps being looked at, huh?
I guess Kubuntu users should be grateful that we use the same notifications as Ubuntu so at least *some* improvements may (by accident) see our systems.
Fabian, Paul, paper cuts are being scheduled on roughly a first-come-first served basis. We cannot make an exhaustive list of all paper cuts in Ubuntu and sort them by annoyance or “WTF-factor” then fix the top 40. You are always welcome to sort through the reported paper cuts or report your own, and contact someone on the papercutters team, and we will milestone your bug if it’s a paper cut and it’s compelling. Telling me that we’re spending time fixing paper cuts that don’t appeal to you is utterly useless; we are always looking for good paper cuts, so instead just tell me which paper cuts matter to you!
KubuntuUser, we are looking for someone to help represent Kubuntu in the paper cuts project. If you’re willing to put in more work than a snarky, anonymous comment on my blog, please contact me (djsiegel) in the #ayatana IRC room.
David, I think you misunderstood me. I am not saying that the idea is bad. But why should I be motivated to report a papercut if the only category where it might fit in is Round 10. So the chances of getting it fixed in this cycle is pretty small.
And please don’t get me wrong again, I LOVE the paper cut idea and will contribute as much as I can.
Good luck! F-Spot could use a popularity boost: http://www.omgubuntu.co.uk/2009/11/poll-do-you-use-f-spot.html
Fabian, I see. Well, report paper cuts if you find them and have time. I would say that reporting a /valid/ paper cut gives the bug a very high chance of getting fixed — much higher than an average bug, even if it doesn’t fit into a milestone.
Of course, if we hit 100, we will just keep on fixing as many paper cuts as we can. If you don’t report a paper cut, it almost definitely will not be fixed.
Fabian, also, I don’t anticipate that we will fill each Paper Jam with related paper cuts; we will always need a few general paper cuts every milestone to make an even ten, so don’t hold back!
Vadim P, no F-Spot could use a “care about what a user wants”-boost and stop “managing” by stuff in a way I didn’t ask for. And be useful. Then maybe.
As for easy paper cuts, the Movie Player could stop halting with a completely useless message if you accidentally queue a text file and just skip it instead like it does with every other unrecognized format… helps when listening to/viewing directories, like, oh, series, split movies or an album.
F-spot is an awful slow application that should be discarded and work should be done on it’s faster competitors like Shotwell, Fotoxx and Solange(?)
http://img504.imageshack.us/img504/627/gwibberpapercut.jpg
The papercut team did excellent work for Karmic. I’m really looking forward to getting papercut fixes for Gwibber during this cycle.
I forgot to mention intipunku
http://intipunku.berlios.de/drupal/?q=node/3
Out of the 76 papercuts marked as fixed how many ended up with patches being submitted and merged into the relevant upstream projects versus an Ubuntu specific patch that won’t incorporated into an upstream project release?
I spot checked this at one point for about a dozen and found the number of patched submitted to upstream to be pretty good (easily over half of the dozen or so I checked).
I think trending the rate of upstream acceptance matters more than trending the number of closed bugs each papercut cycle. The upstream patch acceptance as shows that you are increasing your impact impacting usability decision making in upstream project development. If your patches are just falling on the floor that’s an indication of a communication gap about usability goals.
-jef
Jef, our goal is to get all patches upstream – that kind of collaboration is the whole point of using Lauchpad. We will only carry a distro patch if upstream is not moving quickly enough to land the fix in Ubuntu, but we believe upstream will eventually accept and land the patch.
I understand its the goal… just as its a goal to get 100 papercuts fixed every release. I think you may have missed my point. I think your aren’t stressing your success and progress towards that 100% upstreaming goal.
There is a truism I think applies here… “we value what we measure”…man I wish I knew who to attribute that to.
It looks like you are stressing the measurement of the number of bugs closed. Which is fine…its an easy thing to measure. But I think the measurement of how well you are doing getting patches submitted and merged is the more valuable thing and I’d hate to see the goal of upstreaming get lost if the focus narrows on upping the bug closure count because its the only metric you are tracking publicly.
-jef
Hey Dan,
100 papercuts was a good idea. Glad to see it continue.
Let me just ask though.
This drives me mad and everyone I ever mention it to agrees. It relates to core user experiecne and affects everyone, not just those who use some package or other.
Can you sort out desktop icons?
Currently file-names wrap over lines, arrangement is all over the place, (despite gconf settings to the contrary), you can’t have names beside icons, keep align also doesn’t work. All together I can’t have a small ordered list on my Desktop. Desktop is always a mess.
Thanks for listening, and working on this.
Regards
David :
I just wanted to say “thank you” for all the hard work that you and your team have been doing on improving the Ubuntu user experience.
Putting tireless hours of efforts on the seemingly thankless job of tracking down and eliminating “minor” bugs… this kind of thing is exactly what Microsoft has NOT been doing for 8+ years and it reflects very poorly on them, for a lot of “minor” bugs add up to a “major” user experience problem.
You guys may not get a lot of accolades on it, but you are performing an extremely valuable service to the world of Open Source software.
Every time that I — or the dozens of friends, family and business associates who I have introduced to Ubuntu — power up our computers, we see the results of your work, right in front of us. It is immediately obvious that you are listening to us poor dumb end users and are fixing the problems as we report them.
We know what you are doing, and we appreciate it. Keep up the good work.
Thanks for working on this – wasn’t quiiiiite as big of a success as I hoped it would be, but still very impressive.
I’m very interested in working on Rhythmbox, so please keep updating your blog and keep me posted!
@jef Spaleta:
Majority of the bugs have been fixed upstream too.
Probably only a couple of bugs might not have been done upstream. I’m not even sure that such bugs exist.
Could you comment on the launchpad bugs , which bugs havent been fixed upstream too?
We can hopefully get upstream to fix the issues soon.
Our focus is get upstream to fix the issues too. If there was a delay upstream , it would have only been due to their attention being diverted to crashers and other bugs.
Ubuntu does *not* want to carry patches over upstream efforts[unless absolutely essential]. This has been very specific focus from the desktop team.
If any bugs are not fixed upstream as well. Kindly mention it on the lp bugs.
David, your reply focused on a random musing which apparently overshadowed my main point.
Let me paraphrase: I understand what a papercut is. I am not angry because I think some pet bug of mine is neglected. I think the project is great, but I am worried that it might get a bad rep. This is because, as the link shows, there were perhaps 972 users who tried to suggest a paper cut, of which 100 were selected and 76 fixed.
That level of buy-in (almost 1000 suggestions!) is a good thing, but also has drawbacks. Namely, some people will complain when their bugs are not selected. This is not because the decision is wrong, but simply because these users misunderstand the working definition of ‘papercut’, or can’t see why their bug is not in scope.
Again, I am not one of these, but from viewing comments on bugs, it is clear they are numerous.
Unfortunately, with 76 fixes and 872 invalid bugs, odds may favour the complaints drowning out the praise, resulting in community opinion against something with real value. (The same sort of process is behind the groundless claims that “Ubuntu hates upstream.”
All I wanted to suggest was that, as the papercut efforts grow and mature from release to release, some attention could be paid to forestalling complaints by altering communication strategy somehow.
Ubuntu 9.10
gnome-system-monitor use from 20% to 80% cpu.
operapluginwrapper during flash video use 60% cpu
fix it.
jef, I understand and agree. The One Hundred Paper Cuts project is first and foremost about getting people to think about usability down to the smallest detail; a similar project could be carried out that stresses getting fixes upstream, but pushing fixes upstream is not the unique aspect of this project. Upstream adoption sounds like a really good metric for the Ubuntu project to adopt as a whole, though, and I know people including Jorge Castro are developing tools for tracking upstream adoption of patches originating in Ubuntu.
Donal, you just named my biggest pet peeve! I’d love to sort out the arrangement and sizes of desktop icons… The task is pretty big, though — larger than paper cut sized.
A Telco Guy, thanks so much for the positive feedback and encouragement! People don’t realize how motivitating it is.
Rich, how many paper cuts did you report or fix last cycle? This is a community project, so if it’s not as big a success as you hoped, it’s partially your fault! Please jump in the fray this time and help us fix them. If you have any good paper cut ideas for Rhythmbox, I’m all ears.
Paul, yes, this has been a problem. We discussed it at UDS. Part of me wishes that we hadn’t used the term “paper cut,” and maybe using “Koala Bite” or “Lynx Flea” would lessen the blow (e.g. “this issue that’s really frustrating you isn’t a ‘Koala Bite’”
. Don’t worry too much about the few hundred people who reported bugs that weren’t paper cuts–those bugs are still being worked on and fixed. We are taking extra care (more than we did at the beginning of the project) to thank people who’ve reported paper cuts, even if they are invalid.
Gena, please see the definition of a paper cut, I don’t think you understand the nature of the bugs we are discussing: http://wiki.ubuntu.com/PaperCut
Trackbacks/Pingbacks (3)
[...] της Ubuntu) ωστόσο αντιμετωπίστηκαν 75 από αυτά, όπως αναφέρει ο προγραμματιστής David Siegel στο blog του. Με βάση αυτά τα [...]
[...] Ulteriori dettagli che riguardano i piani del team, sono reperibili a questo indirizzo. [...]
[...] se harán 100 pequeñas mejoras a Lucid (la próxima versión de Ubuntu). David Siegel ha publicado los planes para realizar 100 pequeños parches sobre la interfaz, el uso, o pequeños ajustes que mejoren la experiencia de uso en [...]