🍝 New keyword in bpo: `newcomer friendly`
🍝 copy-pasta from core-mentorship mailing list. 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. It would be great for experienced contributors already familiar with our workflow to not work on issues tagged with newcomer friendly and leave that to new contributors. I’ve added the keyword to Devguide’s Triaging section, with additional guideline of what can be tagged as newcomer friendly. Typically it should be straightforward, well-defined issue, and low-risk. https://devguide.python.org/triaging.html#keywords Thanks. ᐧ
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: https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cstatus&@dispname=Easy%20issues&@startwith=0&@group=priority&keywords=6&@action=search&@filter=&@pagesize=50 This issue has the "easy" keyword: https://bugs.python.org/issue19217 Are "newcomer friendly" and "easy" aimed at somewhat different targets? Skip Skip
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
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-c...
On Fri, Jul 26, 2019 at 7:29 PM Kyle Stanley
Essentially those "easy" issues aren't so easy, and we're starting over.
Is "easy" still going to be used for intermediate level issues or will it be no longer used? Apologies if this was already discussed in the initial thread, I don't have access to core-mentorship.
I don't know yet. You can watch updates to the devguide to find out. -- --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-c...
Not sure if this would be the right place to mention it, but the side menu url/button "Easy issues" in bpo should probably be renamed to "Newcomer friendly" and the "dispname" property in the url could also be similarly updated. This could be done by changing the url from: [current](https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cstatus&@dispname=Easy%20issues&@startwith=0&@group=priority&keywords=6&@action=search&@filter=&@pagesize=50&nosy=31554) => [updated](https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cstatus&@dispname=Newcomer%20friendly&@startwith=0&@group=priority&keywords=6&@action=search&@filter=&@pagesize=50&nosy=31554) Apologies if this should be posted somewhere other than the mailing list, but I figured there probably wouldn't be an issue tracker for the issue tracker, that would be some serious BPO inception and quite the paradox.
Clarification: The url change is only for updating the "dispname" property, which is shown at the top of the page. It would change the header from: "List of issues - Easy issues" => "List of issues - Newcomer friendly" Also, I realized that I accidentally included the "nosy" property at the end, which sets it to only show anything that I'm on the nosy list for. The "keywords" property would also have to be updated, it looks like 6 currently represents Easy, not sure what the value for Newcomer friendly would be. If the Easy keyword is going to stick around, it might be better to just have a separate Newcomer friendly link on the side menu.
On 26Jul.2019 1909, Guido van Rossum wrote:
See the thread 'The trouble with "Easy" issues' in core-mentorship@python.org mailto:core-mentorship@python.org. Essentially those "easy" issues aren't so easy, and we're starting over.
Couldn't that be achieved just as easily by removing the "Easy" and "Easy (C)" tags from everything and coming up with a better definition? I agree they haven't been a great source of bugs for the sprints I've helped coordinate, but I don't think the problem is the label. But I assume the bikeshedding over the name has been done on the private list. Most of the trouble is there are many pending PRs that have not been merged, and so maybe 3/4 of the issues are not actually available. (My suspicion is that the delay in CLA handling is a significant factor here, as many PRs can't be merged during the sprint itself, and we're not so good at following up later.) (As an aside, the best first issue is usually the one the new contributor cares about most, regardless of difficulty. Finding something "suitable" for someone with no preferences or interests is never going to be easy.) Cheers, Steve
On Sat, Jul 27, 2019 at 8:46 PM Steve Dower
On 26Jul.2019 1909, Guido van Rossum wrote:
See the thread 'The trouble with "Easy" issues' in core-mentorship@python.org mailto:core-mentorship@python.org. Essentially those "easy" issues aren't so easy, and we're starting over.
Couldn't that be achieved just as easily by removing the "Easy" and "Easy (C)" tags from everything and coming up with a better definition?
I agree they haven't been a great source of bugs for the sprints I've helped coordinate, but I don't think the problem is the label. But I assume the bikeshedding over the name has been done on the private list.
Hardly. But a new label is easier to set up, and doesn't erase any information.
Most of the trouble is there are many pending PRs that have not been merged, and so maybe 3/4 of the issues are not actually available. (My suspicion is that the delay in CLA handling is a significant factor here, as many PRs can't be merged during the sprint itself, and we're not so good at following up later.)
(As an aside, the best first issue is usually the one the new contributor cares about most, regardless of difficulty. Finding something "suitable" for someone with no preferences or interests is never going to be easy.)
That's so true! --Guido -- --Guido (mobile)
On Fri, 26 Jul 2019 19:09:35 -0700
Guido van Rossum
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
On Fri, 26 Jul 2019 19:09:35 -0700 Guido van Rossum
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-c...
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
IMHO such label should be removed at some point from an issue when
there is too much disagreement about the issue and/or the proposed
solutions. You can find 5 years old "easy" issue with 30+ messages.
Such issue even scares me who is used to old bugs. Such issue is no
longer "newcomer friendly".
Victor
Le dim. 28 juil. 2019 à 22:37, Antoine Pitrou
On Fri, 26 Jul 2019 19:09:35 -0700 Guido van Rossum
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.
_______________________________________________ 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/IWJLWGOB...
-- Night gathers, and now my watch begins. It shall not end until my death.
Stephen J. Turnbull wrote:
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
That's why I think we should continue to use the "easy" tag to describe easier issues targeted towards those with some basic familiarity, but with less experience and "newcomer friendly" to be the easier version of "easy". Newcomer friendly should optimally be reserved for incredibly quick/trivial fixes that serve as an introduction to the process more than an actual issue which needs to be addressed.
participants (8)
-
Antoine Pitrou
-
Guido van Rossum
-
Kyle Stanley
-
Mariatta
-
Skip Montanaro
-
Stephen J. Turnbull
-
Steve Dower
-
Victor Stinner