Future of the Hundred Papercuts project

[Bryce Harrington]

On Wed, Sep 26, 2012 at 01:05:33PM +0100, Chris Wilson wrote:
> Hi there Desktop and Dev teams,
> 
> My name if Chris Wilson and I've recently taken over the leadership of the
> Hundred Papercuts project, and am exploring ways to revitalise it now that
> contributions have all but dried up. I'm drawing up a plan on this
> wiki<https://wiki.ubuntu.com/FutureOfThePapercutsProject>page
> consisting of ideas from both myself and anyone who has something to
> say.

Hi Chris, thanks for taking on this work.
 
> Throughout this discussion, I'm not going to be dismissing any but the most
> radical proposals, which could result in a rather disruptive plan to
> reorganise the project. To reduce the impact that such changes may have on
> the larger Ubuntu project, I was hoping that the Deskop and Development
> teams could review the proposal and give final approval once the discussion
> period ends on 1st November.
> 
> Does this sound Ok with you guys, and if not, do you have any suggestions?

Yes, I recall there were some various things that posed challenges to
the 100 papercuts project, which are likely to affect this new project
too, so could be worth some extra thought.  Apologies ahead of time for
the length of this post...


* A LOT of papercuts end up really being more "design issues".  David
  was on Canonical's design team so could easily get direction on what
  bugs were going to be acceptable to the design team and omit ones that
  weren't.

  You'll want to either develop a good working relationship with the
  design team(s) in question so you can be certain all bugs are
  acceptable, or focus on software and applications that don't require
  consultation with design teams.


* I like your ideas #5 and #7, and more generally the idea of picking
  one software project at a time to focus on.  Pick one application to
  focus on for a month (or maybe 2 months) and target bugs in that
  project's software.

  It was notable in the original papercuts that a huge proportion of the
  bugs were against just a few apps - Nautilus, Unity, etc.

  This approach lets you be more organized as a project.  For instance
  you could assemble a reference list of useful links, hold an
  "orientation class" at the start of the month to give a newbie intro
  to the codebase in question, and arrange closer coordination with the
  project's developers, designers, packagers, etc. for that month (maybe
  even solicit their direct involvement.)  For example, if you wanted to
  do Inkscape one month I could totally hook you up!  (hinthint) :-)


* Fixing even a simple bug in the distro involves a number of different
  specialized roles:

   a.  Reporter - notes a problem
   b.  Analyst - identifies what's actually wrong
   c.  Designer - decides how it *should* work
   d.  Developer - implements fix in code
   e.  Tester - verifies the fix works properly
   f.  Liaison - ensures fix is acceptable upstream
   g.  Packager - integrates patch or branch into the distro
   h.  Updater - handles SRU to get patch into the stable release

  It's easy to slip into the mistake of thinking (d) is the only
  important role.  Lots of people don't know how to code so assume
  development really hard.  Sometimes it is, but with papercuts (and
  esp. bitesize bugs), often the coding is quite trivial (or is trivial
  once you're familiar with the codebase); the real work is in all the
  other steps.

  I think this tended to hamstring the old papercuts project here and
  there.  Some bugs really needed someone authoritative to make a design
  decision.  For others it was vital the fix be acceptable upstream
  (e.g. including test cases or whatnot) so got blocked waiting on that.
  A lot of bugs were things that bug reporters wanted in the LTS, but
  being minor things by definition they often couldn't fit into the SRU
  process.  And so on.

  In regular distro work, many of us developers are able to wear
  multiple hats, so one of us can handle a number of steps in one go,
  and we don't really even think much about all these different roles.
  But with papercuts, your volunteers are not going to be quite so
  ambidextrous.  The good news is you can probably find separate
  individuals who each can fill one or two roles, and so can team up to
  tackle it.

  You may also find it easier to solicit volunteers if they can
  constrain their commitment or expectations to just one role.


* Once you have a number of bugs in flight, it can be hard for a
  volunteer to figure out what to do with any of them.  Out of 100 bugs,
  maybe 30 actually need patches coded, 30 have patches already but need
  packaging work, and the rest are somewhere in between.  Grabbing bug
  reports at random can be frustrating.

  So, consider splitting all of the bug work into three buckets.  First
  are bugs needing review - roles (a), (b), (c) from the previous point.
  Second are bugs needing coding work - roles (d), (e), (f).  Third are
  bugs with patches needing packaged - roles (g), (h).


* Regarding rebranding (idea #3), note that 'bitesize' and 'papercut'
  imply different audiences.  'bitesize' is descriptive if you're a
  developer and is describing how much work.  'papercut' is descriptive
  if you're a user and is describing a degree of annoyance.

  bitesize bugs could end up being a lot of things that people would
  simply never notice (e.g. code cleanup work).  papercuts can sometimes
  end up being non-trivial coding exercises.  So they can imply very
  different meanings.

  Personally, I'd keep the project called papercuts; it's a proven name
  and was effective at drawing in participation.