Docs: Triage process #14014
Docs: Triage process #14014
Conversation
nzakas
added
documentation
|
Hi @nzakas!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
There was a problem hiding this comment.
This looks good. One question though, i think it is require to explain or a short note about what is dev/triage team or who all are in it. Like there can be wrong assumptions from contributors/community that they might not be a part of a team so they should not get involved in it?
WDYT?
|
@anikethsaha yes, that is coming. Short answer for now: we want to recruit a triage team whose job is to get issues ready for review by the dev team. People will be made aware of which team they are on. (You and I, for example, are on the dev team.) |
|
okay cool |
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
|
@mdjermanovic @mysticatea thoughts? Keep in mind that until we put together a triage team, the dev team will be doing the triaging portion as well. We'll need to try it out to determine if there's any issues before recruiting others to help. |
nzakas
added
the
tsc agenda
|
TSC Summary: This documents a new issue triage process. TSC Question: Shall we adopt this process and start using it going forward? |
| * **Bugs:** if you can verify the bug, add the "accepted" label and ask if they would like to submit a pull request. | ||
| * **New Rules:** if you are willing to champion the rule (meaning you believe it should be included in ESLint core and you will take ownership of the process for including it), add a comment saying you will champion the issue, assign the issue to yourself, and follow the [guidelines](#championing-issues) below. | ||
| * **Rule Changes:** if you are willing to champion the change and it would not be a breaking change (requiring a major version increment), add a comment saying that you will champion the issue, assign the issue to yourself, and follow the [guidelines](#championing-issues) below. | ||
| * **Breaking Changes:** if you suspect or can verify that a change would be breaking, label it as "Breaking". | ||
| * **Duplicates:** if you can verify the issue is a duplicate, add a comment mentioning the duplicate issue (such as, "Duplicate of #1234") and close the issue. | ||
| 1. Regardless of the above, always leave a comment. Don't just add labels, engage with the person who opened the issue by asking a question (request more information if necessary) or stating your opinion of the issue. If it's a verified bug, ask if the user would like to submit a pull request. | ||
| 1. If an RFC is required, move the issue to the "RFC Needed" column and comment on the issue that an RFC is needed. |
There was a problem hiding this comment.
Should we add the "needs rfc" label instead, as mentioned in eslint/eslint-github-bot#136 ?
There was a problem hiding this comment.
Not instead, no. The project is meant to show where the issue is in the acceptance process, so having a column indicates that we are waiting for an RFC. (We could rename it “Waiting for RFC” if that helps.)
I’m not sure we need a label anymore.
There was a problem hiding this comment.
Make sense to me, we should just update tasks in eslint/eslint-github-bot#136 (comment) if we won't have the label.
There was a problem hiding this comment.
I'd rather wait a bit before saying we're going to remove the label. As I said, I'm not sure if we need it, but maybe we do? In the original task list it appears I thought we'd still use it. I guess the question is if we want a way to flag that a particular issue needs an RFC vs. saying that the next step in process is to create an RFC?
nzakas
removed
the
tsc agenda
eslint-github-bot
bot
added
the
archived due to age
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[x] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
Wrote up a draft of a new triage process for issues. This new process uses a project board and eliminates a lot of the labels we use for tracking progress. The primary goal is to separate issue management into a triage phase (done by a triage team) and then an evaluating phase (done by the dev team).
Is there anything you'd like reviewers to focus on?
Does the process make sense? Is there anything missing or unclear?
This is intended to be a draft to spur discussion rather than a full-fledged solution.
(Note: This is focused strictly on issues and does not take into account triaging of PRs. If this works for issues we can discuss the best way involve PRs in the process.)