-
-
Notifications
You must be signed in to change notification settings - Fork 779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide more guidance on what makes an issue "easy" #38
Comments
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. |
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:
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:
*: 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. |
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. |
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:
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)
The text was updated successfully, but these errors were encountered: