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
If the bug report can be resolved by e.g. explaining an intended feature, close it with the explanation.

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