Re: [Python-Dev] Re: 🍝 New keyword in bpo: `newcomer friendly`
See the thread 'The trouble with "Easy" issues' in core-mentorship@python.org. Essentially those "easy" issues aren't so easy, and we're starting over. (That list requires subscription before you can read it, but any core dev should be able to get a subscription.) On Fri, Jul 26, 2019 at 6:58 PM Skip Montanaro <skip.montanaro@gmail.com> wrote:
There is now a “newcomer friendly” keyword in bpo.
My hope is that going forward, we can tag issues that are suitable for first time contributors with this keyword.
Hmmm... I haven't looked lately, but didn't there used to be an "easy" tag which purported to serve roughly the same purpose? I see an "Easy issues" link in the left-hand sidebar:
This issue has the "easy" keyword:
https://bugs.python.org/issue19217
Are "newcomer friendly" and "easy" aimed at somewhat different targets?
Skip
Skip _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7C6WTTBS...
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On Fri, 26 Jul 2019 19:09:35 -0700 Guido van Rossum <guido@python.org> wrote:
See the thread 'The trouble with "Easy" issues' in core-mentorship@python.org. Essentially those "easy" issues aren't so easy, and we're starting over.
But how do we know that the same mistake won't be done again? :-) Regards Antoine.
On Sun, Jul 28, 2019 at 1:25 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 26 Jul 2019 19:09:35 -0700 Guido van Rossum <guido@python.org> wrote:
See the thread 'The trouble with "Easy" issues' in core-mentorship@python.org. Essentially those "easy" issues aren't so easy, and we're starting over.
But how do we know that the same mistake won't be done again? :-)
In part because the focus of the wording is different -- "easy" is very subjective, while "newcomer friendly" makes it clear to all core devs that this is about issues that are friendly for newcomers. Also it makes it clearer that the issue specifically should *not* be fixed by core devs looking for easy tasks. And in part because we will have specific guidelines (to be nailed down more precisely in the dev guide) about how to ensure that an issue is newcomer friendly. I don't have the thread handy but it's something about having a clear (to newcomers, not just to core devs) description, without too much jargon, and some (but not too many) hints for a solution. The issue should also be reproducible easily, and there shouldn't be too much discussion on the issue (a newcomer looking for somewhere to help usually doesn't have the background to follow a discussion of 10 or more messages between core devs debating whether something is a bug or a feature). If someone wants to submit a PR to the devguide with tentative wording that would be appreciated. I don't think we'll need too much bikeshedding on such a PR, and we can iterate easily (there's no fear of breaking anything with a PR to the devguide). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
Guido van Rossum writes:
And in part because we will have specific guidelines (to be nailed down more precisely in the dev guide) about how to ensure that an issue is newcomer friendly. I don't have the thread handy but it's something about having a clear (to newcomers, not just to core devs) description, without too much jargon, and some (but not too many) hints for a solution.
I don't think it's a good idea to put too much structure on this. Specifically, some newcomers are new programmers, and some are new to open source processes. Even if editing the code is really easy, such an issue is good "process" practice. In general, it's not obvious to me how much extra burden we want to put on triagers. This tag has basically the same problems that "easy" does, *except* that it deters experienced developers from snatching up easy issues. I think we should see how this works out in practice before reducing the number of issues tagged and at the same time increasing burden. Steve
participants (3)
-
Antoine Pitrou -
Guido van Rossum -
Stephen J. Turnbull