<div dir="ltr">In the mypy project we've definitely experienced the problem with "beginner" issues that they would be fixed by disinterested folks who just wanted to score some GitHub points, and we stopped doing that. While we've not kept track carefully, my impression is that we've not seen the quantity of contributions go down, and we've seen fewer one-time contributors. There's still the occasional contributor who fixes a doc typo and then is never heard from again, but those are easy to accept (but CPython's PR process is much more heavy-weight than mypy's.)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 10:18 PM Stephen J. Turnbull <<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp">turnbull.stephen.fw@u.tsukuba.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Steve Dower writes:<br>
<br>
> I'm sympathetic to wanting to have tasks for the PyCon sprints, but at <br>
> the same time it feels exclusionary to "save" them from people who want <br>
> to volunteer at other times.<br>
<br>
It's already possible to do this sub rosa. Just get a mentor to<br>
"claim" the issue, and have a separate page listing them for the<br>
mentored sprint attendees. I think it's reasonable for each mentor to<br>
claim a couple of issues. Worth a try for a year at multiple sprints,<br>
no?<br>
<br>
If people worry that once it's been done for a year, the mentors will<br>
claim it in perpetuity, they can lobby the Council to explicitly<br>
sunset the practice, so that the Council would have to act to extend<br>
the privilege of reserving issues in this way.<br>
<br>
> I'm 100% in favor of discouraging regular contributors from fixing<br>
> them - we should be *generating* easy issues by describing how to<br>
> fix it and then walking away.<br>
<br>
"Generate", of course! But creating a bug report clear enough for<br>
another to reproduce and then fix a problem is far more effort than<br>
doing it yourself in many, probably most, cases. Some people are<br>
already doing this, I'm sure, but to dramatically increase the number<br>
of such issues, there would need to be strong incentive for<br>
experienced developers to do the extra work.[1] One such incentive<br>
might be to require mentors to tag one (or more) easy issue(s) for<br>
each one they "claim" for sprints. ("More" would compensate for the<br>
possibility that a PR would be generated and applied significantly<br>
faster.)<br>
<br>
The point of Cheryl's proposal is specifically NOT to walk away, but<br>
to rather provide in-person mentoring at a sprint. True, this is<br>
creating a privileged class from people who can be present at PyCon.<br>
We shouldn't award such privileges lightly. But ISTM there are two<br>
kinds of mentoring: the first is "patch piloting" the contribution<br>
through the contribution process. The second is helping the<br>
contributor navigate the existing code and produce new or modified<br>
code in good core Python style.<br>
<br>
It's not clear to me why the first needs to take place at a sprint.<br>
The contribution process is entirely formal, and there is no<br>
overwhelming need to privilege a subset of potential contributors for<br>
"trivial" changes.<br>
<br>
If this is a reasonable way to look at it, the "reserved for sprint"<br>
issues should be difficult enough coding to deserve some mentoring, of<br>
a kind that is best done in person. Eg, doc issues (including message<br>
and error strings) should be excluded from the reservable class. The<br>
mentored sprint new contributors should be encouraged to work on some<br>
trivial issues before the sprint. ("Required" doesn't make sense to<br>
me, since there are probably a lot who are new to coding entirely.)<br>
<br>
> I'm just not entirely comfortable with trying to also hide them<br>
> from first time contributors.<br>
<br>
I too feel that discomfort, but there are a number of good reasons to<br>
privilege PyCon attendees. The special "mentored sprints" are<br>
intentionally diversity-enhancing. If restricted as I suggest, the<br>
issues themselves benefit from personal mentoring, and so this will<br>
both improve education of new contributors and be an efficient use of<br>
mentor time. Finally, these contributors have demonstrated both a<br>
financial commitment and a time commitment to Python, an interest in<br>
contributing *to Python*, and so are more likely to become consistent<br>
contributors than, say, GSoC students who just want to demonstrate<br>
that they understand the PR process to qualify for the $5500.[2]<br>
<br>
Finally, if my analysis above is correct, these issues aren't hidden<br>
in any important way. The hidden issues are the ones that get fixed<br>
"en passant" as core devs work on something else.<br>
<br>
> Either way, I'll keep marking issues as Easy when I think they are<br>
> good first contributions.<br>
<br>
Of course!<br>
<br>
<br>
Footnotes: <br>
[1] Please tell me I'm wrong about Python! But fixing minor issues<br>
"en passant" is my experience in every other project I've contributed<br>
to, including as a non-committing "new contributor" in the first few<br>
patches.<br>
<br>
[2] Not saying that GSoC students don't want to contribute *to<br>
Python*, just that their financial incentive goes "the wrong way"<br>
relative to PyCon attendees.<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>