Skip to content

Commit

Permalink
chore: Add PRs to triage project (#17421)
Browse files Browse the repository at this point in the history 
* chore: Add PRs to triage project

* Update docs/src/maintain/manage-issues.md

Co-authored-by: Amaresh  S M  <amareshsm13@gmail.com>

* Update docs/src/maintain/manage-issues.md

Co-authored-by: Nitin Kumar <snitin315@gmail.com>

* Fix broken links

---------

Co-authored-by: Amaresh  S M <amareshsm13@gmail.com>
Co-authored-by: Nitin Kumar <snitin315@gmail.com>
  • Loading branch information
@nzakas @amareshsm @snitin315
3 people authored Jul 28, 2023
1 parent ee68d1d commit 0aa0bc3
Show file tree
Hide file tree
Showing 3 changed files with 29 additions and 24 deletions.
3 changes: 3 additions & 0 deletions .github/workflows/add-to-triage.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,9 @@ on:
issues:
types:
- opened
pull_request:
types:
- opened

jobs:
add-to-project:
Expand Down
4 changes: 2 additions & 2 deletions docs/src/contribute/work-on-issue.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,10 @@ Our public [issues tracker](https://github.com/eslint/eslint/issues) lists all o

## Issue Labels

We use labels to indicate the status of issues. The most complete documentation on the labels is found in the [Maintain ESLint documentation](../maintain/manage-issues#when-an-issue-is-opened), but most contributors should find the information on this page sufficient. The most important questions that labels can help you, as a contributor, answer are:
We use labels to indicate the status of issues. The most complete documentation on the labels is found in the [Maintain ESLint documentation](../maintain/manage-issues#when-an-issue-or-pull-request-is-opened), but most contributors should find the information on this page sufficient. The most important questions that labels can help you, as a contributor, answer are:

1. Is this issue available for me to work on? If you have little or no experience contributing to ESLint, the [`good first issue`](https://github.com/eslint/eslint/labels/good%20first%20issue) label marks appropriate issues. Otherwise, the [`help wanted`](https://github.com/eslint/eslint/labels/help%20wanted) label is an invitation to work on the issue. If you have more experience, you can try working on other issues labeled [`accepted`](https://github.com/eslint/eslint/labels/accepted). Conversely, issues not yet ready to work on are labeled `triage`, `evaluating`, and/or `needs bikeshedding`, and issues that cannot currently be worked on because of something else, such as a bug in a dependency, are labeled `blocked`.
1. What is this issue about? Labels describing the nature of issues include `bug`, `enhancement`, `feature`, `question`, `rule`, `documentation`, `core`, `build`, `cli`, `infrastructure`, `breaking`, and `chore`. These are documented in [Maintain ESLint](../maintain/manage-issues#types-of-issues).
1. What is this issue about? Labels describing the nature of issues include `bug`, `enhancement`, `feature`, `question`, `rule`, `documentation`, `core`, `build`, `cli`, `infrastructure`, `breaking`, and `chore`. These are documented in [Maintain ESLint](../maintain/manage-issues#types-of-issues-and-pull-requests).
1. What is the priority of this issue? Because we have a lot of issues, we prioritize certain issues above others. The following is the list of priorities, from highest to lowest:

1. **Bugs** - problems with the project are actively affecting users. We want to get these resolved as quickly as possible.
Expand Down
46 changes: 24 additions & 22 deletions docs/src/maintain/manage-issues.md
View file
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
---
title: Manage Issues
title: Manage Issues and Pull Requests
eleventyNavigation:
key: manage issues
parent: maintain eslint
title: Manage Issues
title: Manage Issues and Pull Requests
order: 2

---

New issues are filed frequently, and how we respond to those issues directly affects the success of the project. Being part of the project team means helping to triage and address issues as they come in so the project can continue to run smoothly.
New issues and pull requests are filed frequently, and how we respond to those issues directly affects the success of the project. Being part of the project team means helping to triage and address issues as they come in so the project can continue to run smoothly.

## Things to Keep in Mind

Expand All @@ -17,53 +17,54 @@ New issues are filed frequently, and how we respond to those issues directly aff
1. **Not all requests are equal.** It's unlikely we'll be able to accommodate every request, so don't be afraid to say that something doesn't fit into the scope of the project or isn't practical. It's better to give such feedback if that's the case.
1. **Close when appropriate.** Don't be afraid to close issues that you don't think will be done, or when it's become clear from the conversation that there's no further work to do. Issues can always be reopened if they are closed incorrectly, so feel free to close issues when appropriate. Just be sure to leave a comment explaining why the issue is being closed (if not closed by a commit).

## Types of Issues
## Types of Issues and Pull Requests

There are four primary issue categories:
There are five primary categories:

1. **Bug**: Something isn't working the way it's expected to work.
1. **Enhancement**: A change to something that already exists. For instance, adding a new option to an existing rule or fixing a bug in a rule where fixing it will result in the rule reporting more problems (in this case, use both "Bug" and "Enhancement").
1. **Feature**: Adding something that doesn't already exist. For example, adding a new rule, new formatter, or new command line flag.
1. **Documentation**: Adding, updating, or removing project documentation.
1. **Question**: An inquiry about how something works that won't result in a code change. We prefer if people use GitHub Discussions or Discord for questions, but sometimes they'll open an issue.

The first goal when evaluating an issue is to determine which category the issue falls into.
The first goal when evaluating an issue or pull request is to determine which category the issue falls into.

## Triaging Process

All of ESLint's issues, across all GitHub repositories, are managed on our [Triage Project](https://github.com/orgs/eslint/projects/3). Please use the Triage project instead of the issues list when reviewing issues to determine what to work on. The Triage project has several columns:
All of ESLint's issues and pull requests, across all GitHub repositories, are managed on our [Triage Project](https://github.com/orgs/eslint/projects/3). Please use the Triage project instead of the issues list when reviewing issues to determine what to work on. The Triage project has several columns:

* **Needs Triage**: Issues that have not yet been reviewed by anyone
* **Triaging**: Issues that someone has reviewed but has not been able to fully triage yet
* **Ready for Dev Team**: Issues that have been triaged and have all the information necessary for the dev team to take a look
* **Evaluating**: The dev team is evaluating these issues to determine whether to move forward or not
* **Needs Triage**: Issues and pull requests that have not yet been reviewed by anyone
* **Triaging**: Issues and pull requests that someone has reviewed but has not been able to fully triage yet
* **Ready for Dev Team**: Issues and pull requests that have been triaged and have all the information necessary for the dev team to take a look
* **Evaluating**: The dev team is evaluating these issues and pull requests to determine whether to move forward or not
* **Feedback Needed**: A team member is requesting more input from the rest of the team before proceeding
* **Waiting for RFC**: The next step in the process is for an RFC to be written
* **RFC Opened**: An RFC is opened to address these issues
* **Blocked**: The issue can't move forward due to some dependency
* **Ready to Implement**: These issues have all the details necessary to start implementation
* **Implementing**: There is an open pull request for each of these issues
* **Implementing**: There is an open pull request for each of these issues or this is a pull request that has been approved
* **Completed**: The issue has been closed (either via pull request merge or by the team manually closing the issue)

We make every attempt to automate movement between as many columns as we can, but sometimes moving issues needs to be done manually.

### When an Issue is Opened
### When an Issue or Pull Request is Opened

When an issue is opened, it is automatically added to the "Needs Triage" column in the Triage project. These issues need to be evaluated to determine next steps. Anyone on the support team or dev team can follow these steps to properly triage issues.
When an issue or pull request is opened, it is automatically added to the "Needs Triage" column in the Triage project. These issues and pull requests need to be evaluated to determine the next steps. Anyone on the support team or dev team can follow these steps to properly triage issues.

**Note:** If an issue is in the "Triaging" column, that means someone is already triaging it, and you should let them finish. There's no need to comment on issues in the "Triaging" column unless someone asks for help.
**Note:** If an issue or pull request is in the "Triaging" column, that means someone is already triaging it, and you should let them finish. There's no need to comment on issues or pull requests in the "Triaging" column unless someone asks for help.

The steps for triaging an issue are:
The steps for triaging an issue or pull request are:

1. Move the issue from "Needs Triage" to "Triaging" in the Triage project.
1. Move the issue or pull request from "Needs Triage" to "Triaging" in the Triage project.
1. Check: Has all the information in the issue template been provided?
* **No:** If information is missing from the issue template, or you can't tell what is being requested, please ask the author to provide the missing information:
* Add the "needs info" label to the issue so we know that this issue is stalled due to lack of information.
* Don't move on to other steps until the necessary information has been provided.
* If the issue author hasn't provided the necessary information after 7 days, please close the issue. The bot will add a comment stating that the issue was closed because there was information missing.
* **Yes:**
* If the issue is actually a question (rather than something the dev team needs to change), please [convert it to a discussion](https://docs.github.com/en/free-pro-team@latest/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion). You can continue the conversation as a discussion.
* If the issue is reporting a bug, try to reproduce the issue following the instructions in the issue. If you can reproduce the bug, please add the "repro:yes" label. (The bot will automatically remove the "repro:needed" label.) If you can't reproduce the bug, ask the author for more information about their environment or to clarify reproduction steps.
* If the issue is reporting something that works as intended, please add the "works as intended" label and close the issue.
* If the issue is reporting a bug, or if a pull request is fixing a bug, try to reproduce the issue following the instructions in the issue. If you can reproduce the bug, please add the "repro:yes" label. (The bot will automatically remove the "repro:needed" label.) If you can't reproduce the bug, ask the author for more information about their environment or to clarify reproduction steps.
* If the issue or pull request is reporting something that works as intended, please add the "works as intended" label and close the issue.
* Please add labels describing the part of ESLint affected:
* **3rd party plugin**: Related to third-party functionality (plugins, parsers, rules, etc.)
* **build**: Related to commands run during a build (testing, linting, release scripts, etc.)
Expand All @@ -72,7 +73,7 @@ The steps for triaging an issue are:
* **documentation**: Related to content on eslint.org
* **infrastructure**: Related to resources needed for builds or deployment (VMs, CI tools, bots, etc.)
* **rule**: Related to core rules
* Please assign an initial priority based on the importance of the issue. If you're not sure, use your best judgment. We can always change the priority later.
* Please assign an initial priority based on the importance of the issue or pull request. If you're not sure, use your best judgment. We can always change the priority later.
* **P1**: Urgent and important, we need to address this immediately.
* **P2**: Important but not urgent. Should be handled by a TSC member or reviewer.
* **P3**: Nice to have but not important. Can be handled by any team member.
Expand All @@ -82,7 +83,8 @@ The steps for triaging an issue are:
* **Low**: Doesn't affect many users.
* **Medium**: Affects most users or has a noticeable effect on user experience.
* **High**: Affects a lot of users, is a breaking change, or otherwise will be very noticeable to users.
* If you can't properly triage the issue, move the issue back to the "Needs Triage" column in the Triage project so someone else can triage it.
* If you can't properly triage the issue or pull request, move the issue back to the "Needs Triage" column in the Triage project so someone else can triage it.
* If a pull request references an already accepted issue, move it to the "Implementing" column in the Triage project.
* If you have triaged the issue, move the issue to the "Ready for Dev Team" column in the Triage project.

## Evaluation Process
Expand All @@ -102,7 +104,7 @@ When an issue has been moved to the "Ready for Dev Team" column, any dev team me

**Note:** "Good first issue" issues are intended to help new contributors feel welcome and empowered to make a contribution to ESLint. To ensure that new contributors are given a chance to work on these issues, issues labeled "good first issue" must be open for 30 days *from the day the issue was labeled* before a team member is permitted to work on them.

## Accepting Issues
## Accepting Issues and Pull Requests

Issues may be labeled as "accepted" when the issue is:

Expand Down

0 comments on commit 0aa0bc3

Please sign in to comment.