FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Desktop

 
 
LinkBack Thread Tools
 
Old 09-26-2012, 07:31 PM
Bryce Harrington
 
Default Future of the Hundred Papercuts project

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
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 09-28-2012, 10:14 AM
Chris Wilson
 
Default Future of the Hundred Papercuts project

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@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.









--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 

Thread Tools




All times are GMT. The time now is 11:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org