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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com