Provide more guidance on what makes an issue "easy"

[ncoghlan]

https://github.com/python/devguide/blob/master/triaging.rst#keywords currently states that "easy" issues shouldn't take more than a day for someone new to CPython development, but @gvanrossum pointed out in http://psf.upfronthosting.co.za/roundup/meta/issue605 that that at least needs to be qualified for C level changes based on whether or not the contributor already knows how to program in C.

Guido's specific concern is going to be addressed by splitting the "easy" keyword into "easy (Python)" and "easy (C)", but I think it may be worth providing more concrete guidance to developers and triagers on when it makes sense to mark an issue as "easy". Specifically, I think the main things that make for good first contribution opportunity for folks that aren't sure yet if they want to commit a lot of time are:

• clearly defined scope (specific reproducer for a bug, clear API design for a minor feature)
• already approved-in-principle by a core developer (as this means the issue is likely to have someone willing to review and merge a patch, and is unlikely to get bogged down in debates over whether the bug is actually a bug, or whether the feature addition is a good idea)

Guido also pointed to https://medium.com/@shubheksha/finding-your-first-open-source-project-or-bug-to-work-on-1712f651e5ba#.36q7njkjd as a good overview of the perspective of folks that we're aiming to reach with these "easy" tags.

(To be clear, I'm offering to write a couple of paragraphs for the Triaging page that explains how we seek to use the "easy" keywords, but wanted to discuss our aims for those keywords explicitly before submitting a PR)

[willingc]

Partially addressed here: https://devguide.python.org/triaging/?highlight=easy#keywords

Updates to https://devguide.python.org/fixingissues/ would be beneficial to add clarity and be more welcoming to contributors.

[ezio-melotti]

I think the problem with the "easy" keyword, is that what makes an issue "easy" actually depends on a very wide range of factors.

First of all, "easy" means different things to different people: for some it's something (possibly difficult) they can fix in a day, for others it might also include some (possibly long) work that doesn't actually require particular skills (e.g. reformatting a whole package to follow the PEP 8).

Even if we follow the current definition of "something that shouldn't take more than a day", estimating how long it takes is in itself a fairly difficult task. The time depends on at least three major factors:

1. the time it takes to understand the issue and the consequences of the changes;
2. the time it takes to get the changes approved;
3. the time it takes to do the actual work;

When a triager marks an issue as easy, they are usually making assumptions on all these factors. They assume that: a potential contributor possesses the necessary skill set to understand and solve the issue, the change is not controversial, and the time required to write the PR is relatively short.

However, each issue requires a somewhat different set of skills: knowledge of Python and/or C, of the specific module(s) affected by the issue, of specific platforms, of specific areas (e.g. Unicode, SSL), etc. Rewriting a doc paragraph about Unicode might seem trivial to a native English speaker familiar with Unicode, but can actually be difficult for non-native speakers or people unfamiliar with Unicode.

Perhaps we should stop trying to use a single "easy" keyword to encompass all these different cases and:

1. try to indicate the magnitude of the issue based on how long the patch is expected to be and how controversial is the change (I've seen bite-sized proposed in the past) *;
2. provide enough metadata to allow the contributor to filter the issues depending on their skill set;
3. encourage contributors (even new) to try tackling a broader range of issues, not just easy/bite-sized ones **;

*: This is still an estimation, but if we leave the knowledge of the contributor out of the equation, it should be accurate enough.

**: IME plenty of issues have a fairly limited scope and can be fixed in a reasonable amount of time. Many of these will probably affect functions or modules unfamiliar to the contributor, but this is not a reason to disqualify them a priori. Often, reading the doc of the module and looking at the function and its tests is enough to understand how to fix the problem. On top of this, getting out of one's comfort zone and tackling new problems is one of the most effective ways to improve and learn.

[ncoghlan]

Unassigning since I don't want to get in the way of anyone else coming up with improved wording. Beyond that, I agree with Ezio's discussion of why defining this clearly is trickier than it initially sounds.