UDS Prep: Making it easier to fix bugs

[Emmet Hikory]

Daniel Holbach wrote:
> at UDS I'd like to discuss how we can make it easier to fix bugs,
> especially for new contributors.
>
> I documented the steps that are necessary at
>
>        http://people.canonical.com/~dholbach/Fixing%20a%20bug.png

    A couple complications to add :)

1) Under "Finding the solution", there's also other distributions, and
downstream.
2) Under "Follow conventions", there's also often writing test cases

> We all know the steps that are necessary and why they are. They are all
> documented (somewhere on the wiki). Sometimes there's different choices
> along the way, sometimes steps are mandatory, sometimes optional,
> depending on the case and who you talk to.
>
> When I looked at the resulting diagram I realised how incredibly hard it
> is for new contributors to just "do the right thing".
>
> What can we do to make this easier?

    A lot of this process grew because we had one or another issue
that ended up causing us to add something.  Some of it comes from an
attempt to preserve choice (either by us, or inherited from Debian).
I think we'd do best to avoid attempting to develop a
one-size-fits-all *the way* for new folk to get stuff done.  Instead,
I think we'd do better to enage in two parallel paths:

A) Break down the process of finding a bug to having the fix as far
upstream as makes sense into lots of little steps, and encourage
newcomers to pick some step and repeat it for N bugs.  This makes the
barrier to entry for any of the steps fairly low, and lets someone
contribute effectively quickly.  It also fosters communication and
coordination within the community as people hand off things from one
stage to the next.

    Note that nothing here would involve any of the messiness of
dealing with Ubuntu packaging, Ubuntu conventions, release-stage
considreations, multiple parallel review processes, etc.  Just find
bugs, identify the responsible bit, track down fixes, test them (local
direct conventionless builds are probably fine), and get them
upstream.  While nothing here directly appears to affect Ubuntu, every
bugfix patch that gets upstream improves Ubuntu in the long term, and
it often is not hard to cherrypick such patches if there is some
special need to have them in Ubuntu sooner, or as an SRU.

B) Much more heavily encourage each of the growing number of
development teams to document some realtively easy tasks that can be
done through completion, following procedures, conventions, etc. (the
annoying bits), but using known bugfixes for known packages (e.g.
cherrypicks, backports, merges, upstream updates, etc.).

    People who just want to do *something* or fix *this* bug would use
the (A) processes, either handling one step for many bugs, or all the
steps for one bug, or whatever mix they prefer.  People who want to
focus on some particular development area (e.g. Xubuntu Desktop,
CLI/Mono, etc.) would have an easy way to get involved with the
relevant development team, and help improve whatever "product" is
produced by that team.

    Those folk who stick around a long time will eventually understand
larger and larger portions of the big messy diagram, but it's just too
much to grasp at first, and we can easily produce much more palatable
chunks of work.

-- 
Emmet HIKORY