Hi Bryce,<div> </div><div>Thanks a lot for your input. I had no idea about a lot of this and it's all going to be very useful.</div><div> </div><div>Chris</div><div> <div class="gmail_quote">On 26 September 2012 20:31, Bryce Harrington <<a href="mailto:bryce@canonical.com" target="_blank">bryce@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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 </div>> wiki<<a href="https://wiki.ubuntu.com/FutureOfThePapercutsProject" target="_blank">https://wiki.ubuntu.com/FutureOfThePapercutsProject</a>>page <div>> consisting of ideas from both myself and anyone who has something to > say. </div>Hi Chris, thanks for taking on this work. <div> > 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? </div>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. </blockquote></div> </div>