Docs: Add information about closing accepted issues to docs (fixes #6979

)

docs/maintainer-guide/issues.md

@@ -48,13 +48,22 @@ The steps for triaging an issue are:
 1. Next steps:
     * **Questions:** answer the question and close the issue when the conversation is over.
     * **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), then add a comment saying you will champion the issue. As the champion, it's your job to gain consensus from the ESLint team on inclusion, guide the rule creation process until it's complete, so only champion a rule that you have time to implement or help another contributor implement. Once consensus has been reached on inclusion, add the "accepted" and "help wanted" labels.
-    * **Rule Changes:** if you are willing to champion the change, and the change would not be breaking (requiring a major version increment), then add a comment saying that you will champion the issue. As with new rules, the champion is expected to gain consensus from the ESLint team on inclusion and to guide the change through to completion. Once consensus has been reached on inclusion, add the "accepted" and "help wanted" labels.
+    * **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), then add a comment saying you will champion the issue. As the champion, it's your job to gain consensus from the ESLint team on inclusion, guide the rule creation process until it's complete, so only champion a rule that you have time to implement or help another contributor implement. Once consensus has been reached on inclusion, add the "accepted", "help wanted", and, optionally, "beginner" labels.
+    * **Rule Changes:** if you are willing to champion the change, and the change would not be breaking (requiring a major version increment), then add a comment saying that you will champion the issue. As with new rules, the champion is expected to gain consensus from the ESLint team on inclusion and to guide the change through to completion. Once consensus has been reached on inclusion, add the "accepted", "help wanted", and, optionally, "beginner" labels.
     * **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.
 
-**Note:** Don't add an "accepted" label to an issue unless it's a bug that you've been able to reproduce and verify (you're sure it's a bug), a new rule that you're championing, or a rule change that you're championing. The "accepted" label will be added to other issues by a project lead if it's appropriate for the roadmap.
+**Note:** Beginner 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 work on these issues, issues labeled "beginner" 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
+
+Issues may be labeled as "accepted" when the issue is:
+* A bug that you've been able to reproduce and verify (i.e. you're sure it's a bug)
+* A new rule that you're championing
+* A rule change that you're championing
+
+The "accepted" label will be added to other issues by a project lead if it's appropriate for the roadmap.
 
 ## Evaluating Core Features and Enhancements (TSC members only)
 
@@ -77,6 +86,8 @@ Team members may close an issue **immediately** if:
 1. The issue is a duplicate of an existing issue.
 1. The issue is just a question and has been answered.
 
+### Unaccepted Issues
+
 Team members may close an issue where the consensus is to not accept the issue after a waiting period:
 
 * Wait **2 days** if the issue was opened Monday through Friday.
@@ -86,6 +97,14 @@ The waiting period ensures that other team members have a chance to review the i
 
 Team members may close any **unaccepted** issue after it has been open for 21 days. These issues do not have enough support to move forward.
 
+### Accepted Issues
+
+Team members may close any **accepted** issue after 90 days if no one from the team or the community is willing to step forward and own the work to complete to it.
+
+### Help Wanted Issues
+
+Team members may close any issues labeled "help wanted" after 90 days if they not been completed.
+
 ## Consensus
 
 Consensus is reached on issues when there are at least three team members who believe the change is a good idea and no one who believes the change is a bad idea.