Init

Issue-Triaging-Guide.md

@@ -0,0 +1,57 @@
+## Preamble
+
+This page should be a rough guideline for people triaging issue in the Nuxt.js ecosystem.
+We know that triaging is a case-by-case decision in the end but want to provide a guiding thread to ensure issue handling can be somewhat unified.
+
+Also, this document shows that a GitHub bot (in addition to the current CMTY one) would improve the triaging a lot, especially when it comes to implementing bug fixes and features.
+
+# Closed issues
+
+## Stale issues
+
+- Ideally, let a bot comment on stale issues automatically that people who are still experiencing problems should open a new issue with a reproduction and link the old one there.
+
+## Closed bug reports
+
+- If the bug re-occurs after several versions, advise to create a new issue with a new reproduction
+- Issues **can** be re-opened if the bug persisted throughout the linked PR which should fix it
+
+## Issues closed by CMTY
+
+- Issues closed by CMTY are not following the issue template
+- Thus, they **should** **not** be reopened or answered. Otherwise we would kind of encouraging not using the template and dedicate more time to people who are not able to follow these simple instructions
+- Exceptions can be made but **must** result in a **reopening** of the issue and **transformation** into a feature request, discussion or bug report. Examples for exceptions
+    - Severe bug report
+    - Technical issues with CMTY
+
+# Open issues
+
+## Bug reports
+
+- If the bug report is a **duplicate**, immediately close it with a reference to the other bug report issue
+- If the bug report does not contain a reproduction and such is necessary to triage, add the **needs repro** label
+- When the bug doesn't contain enough information to solve, add the **needs info** label.
+- When the bug **is reproducible** through the reproduction repo/codesandbox and the repro is near-minimal (no large application where the bug could be userland code), add the **pending** label
+
+## Feature requests
+
+- If the feature request is a **duplicate**, immediately close it with a reference to the other feature request issue
+- If the feature is already implemented in a **released** Nuxt version, close the issue and link the implementation PR and the doc entry.
+- If the feature implemented but **not yet released**, it should have
+
+# Bot tasks
+
+## Fixing a bug
+
+- When there is a (fix) PR mentioning the issue, it will be linked in the issue already through GitHub. The bot should apply a **wip** label.
+- When the PR is merged, the bot **should re-open the issue** and apply the labels **fixed**, **pending release.** In addition, it should comment on the state (not released yet, next Nuxt edge build will have it, link to nuxt edge introductions)
+- When the Nuxt release containing the bugfix came out, the bot should comment again, remove the **pending release** label and **close the issue**
+
+## Implementing a feature
+
+- Feature requests have to be evaluated at first. Not every feature is suitable for the core or a module
+- If you have someone in mind who could be an expert for the feature category and want his expertise/opinion, create a comment and **ping** him.
+- After the feature has been discussed and **you are working on the feature**, **assign yourself**.
+- When an implementation PR is present, the bot should apply a **wip** label.
+- When the PR is merged, the bot **should re-open the issue** and apply the labels **implemented**, **pending release.** In addition, it should comment on the state (not released yet, next Nuxt edge build will have it, link to nuxt edge introductions)
+- When the Nuxt release containing the feature came out, the bot should comment again, remove the **pending release** label and **close the issue**