Paper cuts for Maverick

Thanks to Sense and Vish!

What is a paper cut:
- Trivially fixable bugs that affect the user experience in a big way. Often these are things that are old and have been neglected for a while
- Ease of fixability is crucial. 1 developer in 1 day. ("5 per week")
- Example is f-spot default window size was 300 x 300. Small little changes that are really easy to make.

What worked for papercuts in Lucid:
 - more app focussed. So paper jams where we would focus on a theme and it was easier for contributors. Easier to focus on 10 at a time
 - developers were fixing their own bugs: different not better or worse
 - it was easier to ping the devs directly in Lucid
 - Papercuts gave us an agenda to be talking to upstream devs
 - the act of making something a papercut shows that a decision has been made and in some cases this unblocked things

What has changed:
- In Lucid we added a dedicated full screen button to Totem

: is quite complicated (pester the desktop team? Let's nail this for Maverick)

What is the relationship between paper cuts and bitesize bugs?
 - things that were rejected from papercuts could be given "bitesize" tags when appropriate (eg are small fixes but not in default install)

Should we be connecting papercuts to bug jams?

What do we want the hundred papercuts project to look like for Maverick?
- In Karmic we had people in the community who just fixed things everywhere. In Karmic almost everything was forwarded upstream.
- In Lucid it was more of an upstream responsibility to fix them. We fixed many more.
- We want everything fixed for everyone whether they use Ubuntu or not.
- One papercut a day? (or "7 a week")
- Publicity is the key.

- Launchpad functionality to support papercuts?
- We need usability testing input
- There is a concern that if the design team are not agreeing the papercuts the project will lose some of the credibility with upstream
Action: papercuts remains a design team project supported by the community
- provides awesome PR opportunities - blog/tweek before/after screenshots + link to each patch "as proof"
- is there a need for a #papercuts? Should we just use #ayatana? (confusion between to-the-point bugs, and artistee design ideas)
- usually we are pinging people on their channels so there seems to be no need to create a papercuts irc channel

Action: The report is part of the fix.

Work items for maverick-beta:
[djsiegel] Encourage people to blog about their fixes: TODO
[vish] Encourage people to blog about their fixes: DONE
[ivanka] Encourage people to blog about their fixes: TODO
[sladen] Encourage people to blog about their fixes: TODO
[vish ] Investigate involving the patch review team: DONE (when a patch is added for a bug , we can ping the reviewers in the #ubuntu-reviews channel to get it through quicker)
[vish ] update papercuts wiki page: DONE
[ivanka] blog about new comms plan for papercuts: TODO
[ivanka] How do we take this to the next level? How do we talk about end to end journeys and processes? : TODO
[jorge] Bug jam will check with papercuts project: DONE
[rick-rickspencer3] Can you help fix the Cut and paste bug for Maverick? Bug #11334 : POSTPONED
[iainfarrell] Engage with papercutters to help them target number of papercuts to be completed say every day/ week and track progress : DONE