[Python-Dev] "Good first issues" on the bug tracker

[Stephen J. Turnbull]

Steve Dower writes:

 > I'm sympathetic to wanting to have tasks for the PyCon sprints, but at 
 > the same time it feels exclusionary to "save" them from people who want 
 > to volunteer at other times.

It's already possible to do this sub rosa.  Just get a mentor to
"claim" the issue, and have a separate page listing them for the
mentored sprint attendees.  I think it's reasonable for each mentor to
claim a couple of issues.  Worth a try for a year at multiple sprints,
no?

If people worry that once it's been done for a year, the mentors will
claim it in perpetuity, they can lobby the Council to explicitly
sunset the practice, so that the Council would have to act to extend
the privilege of reserving issues in this way.

 > I'm 100% in favor of discouraging regular contributors from fixing
 > them - we should be *generating* easy issues by describing how to
 > fix it and then walking away.

"Generate", of course!  But creating a bug report clear enough for
another to reproduce and then fix a problem is far more effort than
doing it yourself in many, probably most, cases.  Some people are
already doing this, I'm sure, but to dramatically increase the number
of such issues, there would need to be strong incentive for
experienced developers to do the extra work.[1]  One such incentive
might be to require mentors to tag one (or more) easy issue(s) for
each one they "claim" for sprints.  ("More" would compensate for the
possibility that a PR would be generated and applied significantly
faster.)

The point of Cheryl's proposal is specifically NOT to walk away, but
to rather provide in-person mentoring at a sprint.  True, this is
creating a privileged class from people who can be present at PyCon.
We shouldn't award such privileges lightly.  But ISTM there are two
kinds of mentoring: the first is "patch piloting" the contribution
through the contribution process.  The second is helping the
contributor navigate the existing code and produce new or modified
code in good core Python style.

It's not clear to me why the first needs to take place at a sprint.
The contribution process is entirely formal, and there is no
overwhelming need to privilege a subset of potential contributors for
"trivial" changes.

If this is a reasonable way to look at it, the "reserved for sprint"
issues should be difficult enough coding to deserve some mentoring, of
a kind that is best done in person.  Eg, doc issues (including message
and error strings) should be excluded from the reservable class.  The
mentored sprint new contributors should be encouraged to work on some
trivial issues before the sprint.  ("Required" doesn't make sense to
me, since there are probably a lot who are new to coding entirely.)

 > I'm just not entirely comfortable with trying to also hide them
 > from first time contributors.

I too feel that discomfort, but there are a number of good reasons to
privilege PyCon attendees.  The special "mentored sprints" are
intentionally diversity-enhancing.  If restricted as I suggest, the
issues themselves benefit from personal mentoring, and so this will
both improve education of new contributors and be an efficient use of
mentor time.  Finally, these contributors have demonstrated both a
financial commitment and a time commitment to Python, an interest in
contributing *to Python*, and so are more likely to become consistent
contributors than, say, GSoC students who just want to demonstrate
that they understand the PR process to qualify for the $5500.[2]

Finally, if my analysis above is correct, these issues aren't hidden
in any important way.  The hidden issues are the ones that get fixed
"en passant" as core devs work on something else.

 > Either way, I'll keep marking issues as Easy when I think they are
 > good first contributions.

Of course!


Footnotes: 
[1]  Please tell me I'm wrong about Python!  But fixing minor issues
"en passant" is my experience in every other project I've contributed
to, including as a non-committing "new contributor" in the first few
patches.

[2]  Not saying that GSoC students don't want to contribute *to
Python*, just that their financial incentive goes "the wrong way"
relative to PyCon attendees.