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 <[email protected]> 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. > > > >
-- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
