[Sugar-devel] On Issues

James Cameron quozl at laptop.org
Tue May 5 20:28:11 EDT 2020


I'm often asked about how I see GitHub Issues and related workflow.

Issues are for reporting problems you don't plan to fix, in the hope
that someone else will fix them.

Problems rarely have a known fix.  If you know how to fix a problem,
fix it immediately in a pull request.  Cheaper than bothering everyone
with notifications, and having to track the issue.

Why not add labels to issues for new developers?  Because it requires
problem solving.  An assessment of difficulty levels can only arise
from a "known fix".  Moving a problem from "unknown fix" to "known
fix" is the first stage of problem solving, and is the most costly
stage.  Doing that stage for every issue without fixing the issue or
even explaining how to fix it is wasted effort and setting up a
beginner to fail.

Also, what is easy or hard for one developer is certainly not easy or
hard for everyone.  We all have different skills, and skill level is
not a single dimension continuum.

Also, adding labels or more comments to issues just creates
notification noise and activity pollution, making it harder for the
issue to be understood.

If an issue is hard to understand, ask questions about it.  If anyone
is still interested in the issue, they can answer.  If the issue owner
is available, they can edit their comment and then hide the questions.
Issue owners often disappear.  If questions continue to go unanswered,
then it's time to close the issue because nobody has an interest in it
any more.

Overall, it is better to fix things properly rather than leave little
bugs for beginners to chew on.

So before adding a new issue, see if you can fix it the problem, and
make a pull request instead.  There's no need to create an issue just
so the pull request has something to point at!  Add the problem
description to the commit message.

-- 
James Cameron
http://quozl.netrek.org/


More information about the Sugar-devel mailing list