Skip to content
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

Docs: Triage process #14014

Merged
merged 3 commits into from Feb 11, 2021
Merged

Docs: Triage process #14014

merged 3 commits into from Feb 11, 2021

Conversation

nzakas
Copy link
Member

@nzakas nzakas commented Jan 18, 2021

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.)

@nzakas nzakas added documentation Relates to ESLint's documentation accepted There is consensus among the team that this change meets the criteria for inclusion labels Jan 18, 2021
@eslint-deprecated
Copy link

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.

  • The commit message tag must be one of the following:

    The Tag is one of the following:

    • Fix - for a bug fix.
    • Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
    • New - implements a new feature.
    • Breaking - for a backwards-incompatible enhancement or feature.
    • Docs - changes to documentation only.
    • Build - changes to build process only.
    • Upgrade - for a dependency upgrade.
    • Chore - for anything that isn't user-facing (for example, refactoring, adding tests, etc.).

    You can use the labels of the issue you are working on to determine the best tag.

  • There should be a space following the initial tag and colon, for example 'New: Message'.

Read more about contributing to ESLint here

@nzakas nzakas changed the title Triage process Docs: Triage process Jan 18, 2021
Copy link
Member

@anikethsaha anikethsaha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@nzakas
Copy link
Member Author

nzakas commented Jan 20, 2021

@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.)

@anikethsaha
Copy link
Member

okay cool

Copy link
Member

@btmills btmills left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flow makes sense, and I'm excited to give it a try. LGTM

docs/maintainer-guide/issues.md Outdated Show resolved Hide resolved
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
@nzakas
Copy link
Member Author

nzakas commented Jan 26, 2021

@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 nzakas added the tsc agenda This issue will be discussed by ESLint's TSC at the next meeting label Jan 28, 2021
@nzakas
Copy link
Member Author

nzakas commented Jan 28, 2021

TSC Summary: This documents a new issue triage process.

TSC Question: Shall we adopt this process and start using it going forward?

docs/maintainer-guide/issues.md Show resolved Hide resolved
docs/maintainer-guide/issues.md Show resolved Hide resolved
docs/maintainer-guide/issues.md Show resolved Hide resolved
* **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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add the "needs rfc" label instead, as mentioned in eslint/eslint-github-bot#136 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense to me, we should just update tasks in eslint/eslint-github-bot#136 (comment) if we won't have the label.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

This was referenced Mar 17, 2021
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Aug 11, 2021
@eslint-github-bot eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion documentation Relates to ESLint's documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants