Simple but worthwhile to fix bugs?

[Bryce Harrington]

On Thu, Sep 13, 2012 at 11:22:09AM +0200, Daniel Holbach wrote:
> Hello,
> 
> On 13.09.2012 10:40, Martin Pitt wrote:
> > Daniel Holbach [2012-09-11 11:25 +0200]:
> >> Also with many projects using 'bitesize' for their bugs we now have
> >> tasks which might be 'bitesize' in the context of a particular package
> >> (ie if you know a bit about the code base already), but in general they
> >> might be hard for somebody who's new to everything.
> >>
> >> We should probably refer to the bitesize bugs in the wiki page, but have
> >> other tasks as well, which can be solved by the step-1-to-step-10 approach.
> > 
> > That seems to assume that there are significant classes of bugs which
> > affect all packages alike? It seems to me that this reduces the
> > opportunities pretty much to things like spelling errors or
> > translation updates, and these are already covered. For actual wrong
> > behaviour (what most bug reports are about), you necessarily have to
> > get some package specific knowledge?
> > 
> > The step 1 to 10 should certainly encompass how to get the source,
> > point to patch system docs, forwarding patch to upstream, put it into
> > the sponsoring queue etc, but I don't see how we can create steps to
> > fix actual bugs without knowing what package we are talking about?
> 
> Yes, I agree. There are different classes of bugs and different
> approaches. That's why we try to classify them on the wiki page.
> 
> All I tried to say with regard to 'bitesize' that we have a problem
> because it's not used very much generally (some teams like Unity do),
> and that 'easy' sometimes just means 'easy for somebody who knows the
> code' which leaves a bunch of new contributors wondering how to get
> started with the bug.

I completely agree.  'bitesize' X.org bugs are an excellent example.
Easy... *if* you already know the tech.

Have you surveyed new contributors about what types of things they
*want* to do?  Maybe that's the right question to ask first.  What is
motivating them to get involved, and how can we stimulate that further
and scale it up?

Is their interest to learn general packaging and gain experience over
the full breadth of packages, or are they more interested in specific
subsets?  Are they more interested in fixing a lot of simple problems,
or tackling big challenges?  Do they want clean straightforward tasks
that help them expand their skills or ugly complicated ones that will
solve longstanding issues?  Do they want to get involved in Ubuntu
distro work specifically, or are they more interested in upstream
development but weren't comfortable at that level so are starting here
with us?  What do they hope to get out of their involvement?

Bryce