Simple but worthwhile to fix bugs?

[Bryce Harrington]

On Tue, Sep 04, 2012 at 11:47:32AM +0200, Daniel Holbach wrote:
> Another question is: what kind of fixes do we want new contributors to
> work on? How simple is too simple? Are we afraid of typo fixes piling up
> in the queue?

Bad spelling and bad grammar are pet peeves of mine.  I try to submit
patches upstream when I spot errors myself.  But admittedly these are
typically minor issues.  I think it's good to identify them, but it's
more efficient for these to go directly upstream.  The sponsorship
process adds overhead and uses up time of reviewers that would be better
to spend on more substantial issues.


One area I think this audience could have a bigger impact on is
backporting of existing fixes from upstream.  This involves doing SRUs,
which might be a bit much for newbies, but it usually requires little or
no coding skill, just packaging/process know-how.

Much of the trouble of backporting fixes is figuring out how to
reproduce a problem and locating the upstream fix; but this is good
"many hands make light work" type stuff that makes good use of the
community.  The remainder of the work is straightforward packaging and
process type stuff; quite learnable via sponsorship and with plenty of
ready pilots and mentors.  We can't effectively mentor someone to learn
C++ to fix a bug, but given an existing patch we can certainly mentor
someone through the rest of the process of packaging/testing/sru'ing
it.

Bryce