Skip to content

Latest commit

 

History

History
74 lines (48 loc) · 4.72 KB

issue-triage-checklist.md

File metadata and controls

74 lines (48 loc) · 4.72 KB

Issue triage checklist

Helping process and understand new issues is a great way to help the project. To review a new issue, follow these steps. It looks lengthy, but with practice, many issues can be processed in a few minutes.

Close irrelevant issues fast

Avoid wasting time on issues which are not relevant to the repository by closing them quickly.

  • Is it obvious spam? Close it without comment and label it spam.
  • Is the issue template wholly incomplete? Close it and label it invalid.
  • Is the issue template largely incomplete? Close it with a suggestion to reopen with more details and label it invalid.
  • Is the issue a duplicate of another issue? Close it with a comment stating it is a duplicate, mentioning the original issue number, and label it duplicate.
  • Is the issue a request for web development or other unrelated help? Close it with a brief explanation of what the repository is for and label it invalid.

Confirm the title, description, and metadata

Make sure the issue is well-described. If these details aren't satisfied, ask for more information or update the issue title, description, or labels yourself (or @ mention a Peer or Owner who can do this for you).

  • Does the title summarize the issue?
  • Does the issue uniquely identify relevant feature(s)? Ideally with a dotted path to a feature (e.g., javascript.builtins.Date.now) or an unambiguous name (Date.now()).
  • Is the issue labeled correctly? For example, if it's about CSS, does it have the CSS label?
  • As applicable, are specific browsers, versions, and operating systems identified?
  • If applicable, is there a link to a relevant MDN page?

Confirm the existing data

Make sure the data is consistent with the issue reported before investing time in more research or testing.

  • Check if the existing data makes sense. Sometimes there's confusion about what the data shows (e.g., ranged data) or where it should be recorded (e.g., different event features).
  • Check if the data has already been updated. Data doesn't reach consumers immediately; make sure the data hasn't been fixed already.
  • Link to the relevant data files. If the data does in fact need changes, link to the source files that will need be changed.

Related information

Make sure the issue is connected to other relevant information.

  • Link to related issues. Search for other issues with the same dotted path to a feature (or a parent feature) or using similar keywords.

  • If the issue is a duplicate, close it. Follow these steps:

    1. Copy any new information into the original issue.
    2. Comment to thank the reporter and link to the original issue.
    3. Label the issue duplicate.
    4. Close the issue.

  • If there are related issues, link to them. Comment or edit the issue description.

  • For new features, link to relevant specifications.

Fill in additional details

Most reporters won't do these things on their own, but these are important steps to confirming a report, testing for verification, or invalidating an issue.

Get testing details

  • If there is an mdn-bcd-collector test for this feature, link to it.
  • If there's a live sample or interactive example on MDN that can be used as a test, link to it.
  • Ask the reporter if they have a minimal test case (e.g., on CodePen).
  • If applicable, comment if a more detailed or specific test is required. For example, tests often work by checking whether a prototype has a particular member, not the actual behavior of that member.
  • If there is a bug or commit, link to it. Bugs can be found using the links provided in the helpful resources section of the contributing document.

Propose next steps

After we've collected all of the required information, make a plan for what to do next.

  • Comment suggesting next steps, such as:

    • Finding or writing a minimal test case.
    • Running tests in BrowserStack or Sauce Labs.
    • Updating the data files with a pull request.

    Or, if you're not sure what the next step is, ask for ideas, input, or help.

  • If applicable, set labels seeking help. Use the good first issue or help wanted labels.

  • Thank the reporter.