Future of the Hundred Papercuts project
notgary at ubuntu.com
Fri Sep 28 10:14:32 UTC 2012
Thanks a lot for your input. I had no idea about a lot of this and it's all
going to be very useful.
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
> > Hundred Papercuts project, and am exploring ways to revitalise it now
> > 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
> > radical proposals, which could result in a rather disruptive plan to
> > reorganise the project. To reduce the impact that such changes may have
> > the larger Ubuntu project, I was hoping that the Deskop and Development
> > teams could review the proposal and give final approval once the
> > period ends on 1st November.
> > Does this sound Ok with you guys, and if not, do you have any
> 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
> 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...
More information about the ubuntu-desktop