Future of the Hundred Papercuts project

[Chris Wilson]

Hi Bryce,

Thanks a lot for your input. I had no idea about a lot of this and it's all
going to be very useful.

Chris

On 26 September 2012 20:31, Bryce Harrington <bryce at canonical.com> wrote:

> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120928/292deb32/attachment-0001.html>