(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.)
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):
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.
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!
Interested in running Ubuntu Desktop in your organisation?
Over the past year, we’ve been working hard to bring you the next release of Vanilla framework: version 2.0, our most stable release to date. Since our last significant release, v1.8.0 back in July last year, we’ve been working hard to…
Drones, and their wide-ranging uses, have been a constant topic of conversation for some years now, but we’re only just beginning to move away from the hypothetical and into reality. The FAA estimates that there will be 2 million drones in…
This was a fairly busy two weeks for the Web & design team at Canonical. Here are some of the highlights of our completed work. Web Web is the squad that develop and maintain most of the brochure websites across the Canonical.…