Set out expectations for good first issue label
#14686
Conversation
|
Thanks for making a pull request to jupyterlab! |
|
Note: this PR is meant to first seek consensus (especially interested in opinions from @andrii-i and @JasonWeill who run the triage meetings) and then codify them as guidance. Alternatives/suggestions welcome! |
Co-authored-by: Jason Weill <93281816+JasonWeill@users.noreply.github.com>
There was a problem hiding this comment.
Current version looks good to me and includes all the necessary requirements for a good first issue. Docs preview also looks good. Re-running failed CI tests, otherwise good to merge. Thank you for working on this @krassowski, @JasonWeill.
|
While reviewing this PR, I thought if it might be also useful to automatically post a link to "Contribute" section of the docs when PR is marked with "good first issue"? Link can be a part of a "welcome" message for potential new contributors. From experience of being both new contributor and someone who helps new contributors, reading "Contribute" section of the docs is very useful and I post it often trying to help new contributors. I can look into implementing this if you think this would be useful for onboarding new contributors. |
| @@ -251,6 +251,17 @@ pass without a reply that unblocks it. | |||
| Our expectation is that every new issue should be examined within a week of | |||
| its creation. | |||
|
|
|||
| Triagers should label easier issues as ``good first issue`` to | |||
There was a problem hiding this comment.
Suggest replacing "easier" with a less ambiguous term such as low effort/low complexity
There was a problem hiding this comment.
That's a bit tricky. I think we should not say that good first issues are low effort - this can be demotivating especially if it ends up being a lot of effort for a beginner; they certainly should not be high complexity issues as there is a compelxity in learning a new codebase and contribution process itself. It might be hard to put this into words. I will use "easier/lower complexity" for now (29cd2ea), please suggest a better wording if something comes to mind.
For example, GitHub uses "selected for its relative approachability" (https://github.com/jupyterlab/jupyterlab/contribute):
Each issue displayed here is a "good first issue," selected for its relative approachability for first-time contributors.
That's a mouthful, but maybe good?
Co-authored-by: Frédéric Collonval <fcollonval@users.noreply.github.com>
Co-authored-by: Tania Allard <taniar.allard@gmail.com>
There was a problem hiding this comment.
Thanks @krassowski
I suggest we wait a bit before merging to let time to @trallard to comment back on Mike reply.
Co-authored-by: Tania Allard <taniar.allard@gmail.com>
|
CI failures are not related |
|
@meeseeksdev please backport to 4.0.x |
…#14719) Co-authored-by: Michał Krassowski <5832902+krassowski@users.noreply.github.com>
References
This came out of todays Jupyter Accessibility call discussion where we brainstormed how to improve the experience of beginner contributors: a point was raised that not all
good first issues in JupyterLab are actually good issues for beginners, specifically sufficient context and links to the codebase are missing at times (thank you @trallard!). Since this label is occasionally applied by the triage team during weekly triage call, this PR is to build consensus on (minimum) expectations for good first issues, and encourage the triage team to add (or ask for) any necessary context/links to codebase to facilitate beginner contributions.Code changes
None
User-facing changes
None
Backwards-incompatible changes
None