Creating and working on issues

General guidelines for participation

While reporting an issue or participating in a conversation in an issue, always ensure that your inputs are contributing to the overall progress of the project. Consider whether the issues you open and your comments in an issue are constructive and on topic and are not just adding noise.

Do the following:

• If you have a question, you can ask it in the MDN Web Docs chat rooms instead of filing an issue.
• If there's many ways to fix a problem, consider if you need to discuss it with the staff/community. Use discussions to gain different viewpoints and to converge on an agreed-upon course of action. This helps to keep issues focused and productive.
• After filing an issue, try to fix the problem yourself. There's a guide about Pull request submission and reviews that covers everything you need to know about the contribution process.

Avoid doing the following:

• Complicating issues by trying to discuss multiple topics or by making off-topic comments.
• Opening lots of issues asking vague questions.
• Asking questions without trying to solve the problem yourself first.

If you want to suggest new documentation or ways to improve the website, see Proposing new content or features.

Guidelines for reporting an issue

Issues are used to track bugs. An issue must be a single actionable task or a collection of related actionable tasks and must have a clear outcome.

Before filing an issue

First, based on the type of problem you've discovered, identify the appropriate MDN GitHub repository to create the issue so the right people can handle it. Then, before creating an issue, check that it hasn't already been reported.

Reporting an issue

Here are some hints for opening issues:

• Choose the appropriate category to report the issue. For example, to report a content bug, use the Content issue template in the mdn/content repository.

• Provide sufficient information while reporting the issue:

  • Issue title must convey succinctly the required action.

  • Issue description must clearly describe the bug and, if possible, the action required to resolve the issue.

    For complex issues that need multiple steps to resolve, break down the work into smaller tasks using a task list. Update the status of a task in the issue description instead of commenting on the issue. This helps others who may otherwise need to scroll through comments on the issue to determine the status of various tasks. Comments in an issue should be limited to details or context that help with resolving the issue.

• If you find yourself in one of the following situations, move the conversation to MDN's discussion on GitHub:

  • You are unsure if the issue is valid or what the required action is.
  • The issue has no clear consensus on its resolution.

• For minor bugs, you can make the changes yourself and submit a pull request.

If the information you provide in the issue is incomplete, you might be asked to provide more details during the issue triaging process (look out for the needs info label).

Creating a task list issue

If the issue you're opening is not to report a bug but to perform a series of tasks, you can create the issue as a task list. Explain the context or reason for performing the tasks in the description. Ensure that you list all the actionable tasks as a checklist.

For example:

// Issue title
Ensure sections follow the order defined in the CSS property template

### Description

The CSS property page template is defined [here](/vi/docs/MDN/Writing_guidelines/Page_structures/Page_types/CSS_property_page_template).
The task list in this issue will be used to compare the documented CSS properties with the template and track changes to the property pages for compliance.

### List of pages checked

- [x] [accent-color](/vi/docs/Web/CSS/Reference/Properties/accent-color) - checked, okay
- [ ] [backdrop-filter](/vi/docs/Web/CSS/Reference/Properties/backdrop-filter)
- [ ] [letter-spacing](/vi/docs/Web/CSS/Reference/Properties/letter-spacing) - open pull request to move `Accessibility concerns` and `Internationalization concerns` sections before the `Specifications` section.

Guidelines for working on an issue

Remember that if you take on an issue, the expectation is for the work to be completed in a timely manner. If you are unable to progress work on a claimed issue, please add a comment so that maintainers are aware, and so that the issue can be picked up by another contributor.

These are the general steps for working on an issue:

1. Find an issue: If you're looking to contribute, search for issues with a priority label, p2 or p3 (see what these priority labels mean). Alternatively, look for issues with one of these labels that indicate we're inviting PRs from the community: good first issue, accepting PR, and help wanted. Most repositories have issues with these labels. You are welcome to browse and pick an issue that is suitable for your skill set.

   Another useful place to look for issues is the MDN Contributor Board. This project view lists open issues from multiple repositories. You can filter the list based on the topics (Labels column) you're interested in. If you're curious, read the meanings of the labels that get applied during the issue triage process.

   Note: An issue with the needs triage label indicates that the MDN team has not reviewed the issue yet, and you shouldn't begin work on it.

2. Check that no one is already working on the issue:

   Before starting work on an issue, first check that no one is assigned to the issue (the Assignees field should be "Unassigned").

   Then check that there are no linked Pull Requests, as these may indicate that another contributor has claimed the issue and started working on it.

3. Do the research:

   Most issues need some investigation before work can start.

   • Scope out the work that needs to be done. If the issue is not well-described, and/or you are not sure what is needed, feel free to mention the person who opened the issue (using @username) and ask for more clarifying information.
   • You can also ask for advice in the MDN Web Docs chat rooms.

4. Claim the issue:

   You can "claim" an unassigned and unclaimed issue by following these steps:

   1. Fork the repository and create your working branch.

   2. Fix the issue and then open a Pull Request (PR) in the repository.

   3. In the PR description, include the text Fixes #<issue_number> (if the PR only partially fixes the issue add the text Related to #<issue_number>).

      Adding this text is what creates a cross-reference between the issue and the PR, and implicitly marks the issue as claimed by you.

      Note: If you have the necessary permissions, you should also explicitly assign the issue to yourself.

   Depending on the files you've updated in the pull request, a reviewer will be assigned to your pull request automatically. (Teams per topic area are defined in the CODEOWNERS file).

   Warning: After opening the pull request, if you find you no longer have the time to make changes or incorporate review feedback, let the team know as soon as possible in a comment in the pull request. This will help the team assign another interested contributor to complete the work on the pull request and close the linked issue.

5. Close the issue as completed:

   If you opened the pull request with Fixes #<issue> in the description, the issue will be closed automatically when the PR is merged. Otherwise, you can add a comment to the issue linking to one or more pull requests that fix it, and a maintainer will close the issue as completed.

Fixing issues yourself

If you spot a bug — whether it's a problem with the website's look and feel or an error in documentation — you can try to fix it yourself in a pull request. If the bug is small (such as a typo or a minor sentence improvement) or involves a quick fix, you can submit a pull request with the appropriate changes.

For any other type of bug, begin by opening an issue. Add a comment about your intent to work on the issue and, if possible, describe your proposed solution or steps to fix it.

Using the guidelines on working on an issue, try to fix the problem by updating the appropriate source, such as:

• The MDN Web Docs content (in English) in the mdn/content repository
• The MDN Web Docs translated content in the mdn/translated-content repository
• The MDN Web Docs frontend in the mdn/fred repository

Each repository includes useful information to guide you on how to contribute. For more information, see our main GitHub repositories.

Guidelines for triaging issues

If you are a maintainer or an owner in the MDN Web Docs GitHub organization, you are responsible for triaging issues in one or more MDN Web Docs repository.

The overall process for triaging includes some general and some issue-specific tasks.

General triaging tasks

• When an issue is opened, the needs triage label is set on the issue automatically. You can search for this label to look for issues that need to be triaged. Contributors or anybody else should not work on the issue until the issue has been triaged. (Triagers should remember to remove the needs triage label after triaging the issue.)

• In the mdn/content repository, an additional Content: label, such as Content:CSS or Content:WebAPI, is set on the issue automatically. This gets set based on the MDN URL mentioned in the issue. You can use the content-specific label to look for issues to be triaged in your specific topic area.

• If an issue concerns an active, non-en-US locale, set the appropriate label, such as l10n-fr, l10n-zh, or l10n-ja. The teams for those locales will pick these issues up and triage them.

• You don't need to actively triage issues all the time. Set aside time, say 30 minutes every week, to triage issues on a regular basis in your area of responsibility. Triaging doesn't have to be done as part of a synchronous meeting or even at the same time as everyone else, but it should be done regularly to make sure that the backlog of untriaged bugs doesn't get too high.

• Apart from triaging incoming issues every week, review the list of old bugs to see if there are any that are stalled, need closing, or are no longer relevant. The idle label is automatically set on issues that have had no activity for 30 days.

  • Check assigned issues that are still open to see if the assignee is making progress. If there is no progress after a week of being assigned, ask them if they still have time to work on the issue. If another week passes by without any progress, unassign them and leave a comment indicating that you're making the issue available for other interested contributors.
  • If a pull request has been opened to fix the issue but has not been reviewed for a week, give the reviewer a gentle ping to ask if they can get to it.
  • If a pull request to fix the issue is waiting on review comments to be addressed after a week, then ask the author if they can respond to their review. If another week goes by, either fix the review comments yourself if you have time, or close the pull request and unassign the related issue.

Issue-specific triaging tasks

These are the guidelines to follow while triaging each issue.

Review if the issue is valid

These are some of the things to keep in mind while reviewing the validity of an issue:

• Check if the issue raised is valid.
• Evaluate if the fix will improve the content for the readers and the website.
• Evaluate if the impact of the fix will be small or site-wide.
• Evaluate if the fix for the issue will need a discussion first, in which case, point the author to open a discussion instead.
• Check if the issue complies with our writing guidelines and templates. For example, whether suggestions for adding links comply with our external links policy.
• Check if the issue is a duplicate of an existing issue. If it is, you can close the issue as a duplicate.

Review the issue for completeness of information

Review each issue against the following checklist to ensure that the issue contains the described information for someone to start working on the bug:

• URL of the MDN Web Docs page with the problem or URL of an example MDN Web Docs page if the problem exists on multiple pages
• The specific heading or section on the MDN Web Docs page where the problem was found
• A clear description of the incorrect, unhelpful, incomplete, or missing information

If any of the above information is not present, then you should ask the author of the issue to provide these details, and add the needs info label to the issue. Resume triaging the issue only after those details have been provided (after which, you can remove the needs info label). It is okay to wait for up to a week to get a response from the author.

Set a priority label

For each bug, set a priority label based on the severity of the issue to help people who want to work on the most important issues or areas.

• Critical issue: This type of issue needs to be fixed as soon as possible, regardless of where it appears on the site. This type of issue could damage MDN's reputation severely and/or harm users. Examples of this issue include an incorrect code snippet, which if used in production, could create a severe security problem and undesirable content such as malware, profanity, pornography, hate speech, or links to such content.

  • Label: p0 (will be addressed immediately)

• Major issue: This type of issue could severely affect a page's usefulness. For example, a significant amount of out-of-date information, a complex and important code example that doesn't work, a significant amount of prose that is badly written and hard to understand, or a large number of broken links.

  • Labels: p1 (will be addressed soon) and p2 (will be addressed soon, but higher priority items will take precedence)

• Minor issue: This is a type of improvement issue that can make the existing content better but does not affect learning or only has a minor effect on learning. Since these types of issues are not actively planned for, help from contributors to fix these issues is welcome and much appreciated. Fixing some of these issues can also provide the necessary practice to beginner contributors who are starting to get familiar with the contribution process. Examples include typos, bad grammar, a broken link, a small amount of out-of-date information or badly-written prose, or a code snippet that doesn't work.

  • Labels: p3 (no visibility when the issue will be addressed)

In general, critical issues should be fixed immediately and are most likely handled by MDN staff and peers. If not specified, p3 is the default priority level.

Add helpful information

If possible, add information that can help contributors to fix the issue. The information can be in the form of steps, general approach, links to other similar fixed issues, or reading resources. A well-laid out plan or steps is especially required in issues that are labeled good first issue and can help ramp up new contributors quickly. You can time-box this task to 5-10 minutes.

For example, as a triager, you can add the following information to the issue you are triaging:

To whoever fixes this issue, it looks like the following is needed:

- Update the first paragraph below heading X to correct the problem with Y
- Add a description of X
- Update the compatibility data at Link-X

Apply type, goal, and effort labels

Next, set the following labels where possible:

• A label to indicate the "type of problem" that needs to be fixed, if applicable:

  • broken link external: The issue reports a broken link to an external page.
  • document not written: The issue reports a necessary document that has not been written yet, usually because a link points to it. Note that we have a Web Docs Backlog project that already tracks many unwritten reference pages, so if the issue is about one of those, you can close the issue with closed: duplicate and point to the backlog.
  • screenshot: The issue reports a missing or outdated screenshot.
  • baseline: The issue reports an incorrect baseline banner. Note that the data displayed in the baseline banner does not come from the mdn/content repository; instead, it's determined by a combination of inputs from browser compat data, front-end code, and web-platform-dx/web-features. You should almost always either close the issue to indicate it's working as intended or transfer it to the appropriate repository.

• A "goal" label to indicate what the fix is trying to achieve:

  • goal: accuracy: The issue reports incorrect or inaccurate information. If the content was accurate at the time of writing, use goal: up-to-date instead.
  • goal: clarity: The issue reports misleading or unclear information (but is technically correct).
  • goal: completeness: The issue reports missing information, usually important caveats or explanations.
  • goal: consistency: The issue reports inconsistent information. Use this label only for editorial consistency, such as code examples and their descriptions; if at least one place is technically incorrect, use the goal: accuracy label instead.
  • goal: up-to-date: The issue reports out-of-date information, usually because of changes in the web platform.
  • goal: best practices: The issue reports anti-patterns used in code examples or content.
  • goal: discoverability: The issue reports missing links to related content or missing keywords that would help search engines find the page.

• An "effort" label to help contributors find issues that match the time and effort they can spend. Use your best estimate to apply the appropriate label, since the actual effort ultimately depends on the contributor's skill set and experience. In reality, the effort put in may be more significant than the amount of work delivered (e.g., the work requires significant prior research) or vice versa (e.g., it only involves a single change that affects many pages).

  • effort: small: The fix would likely be under 50 lines (corresponding to an xs or s-sized PR).
  • effort: medium: The fix would likely be between 50 and 1000 lines (corresponding to an m or l-sized PR).
  • effort: large: The fix would likely be over 1000 lines (corresponding to an xl-sized PR).

• An "accepting contribution" type of label that indicates we're inviting PRs from the community:

  • good first issue: Add this label if the fix for the issue is really simple and would provide good practice for a newcomer who is getting used to the contribution process. Apply this label only if all these are true:
    • There are instructions, either from the author or the triager, about what exactly needs to be written (preferably verbatim text, or a step-by-step guide).
    • The fix targets one single page (so the contributor can easily fix it via the web interface).
    • The fix does not involve writing significant new content or code, which may require deeper technical understanding.
  • help wanted: Set this label if the issue requires help from someone who knows about or is familiar with the topic. This is a popular label, and some contributors use it to search for issues to work on in open source projects in their areas of familiarity or expertise.
  • accepting PR: Add this neutral label if the issue is not as straightforward as a good first issue, but not so complex or niche to require a help wanted label.

  If an issue doesn't have any of the these labels, it generally indicates that community contributions are discouraged for the issue. This may be the case when further discussion is needed, the work requires someone familiar with MDN editorial conventions to take it on, or a team member intends to work on it. Contributors can still work on these issues if they are familiar enough with the process.

• Issue status: If an issue doesn't have a label showing that we're accepting PRs or that work on it is in progress, add one of the following labels to indicate what it's blocked on:

  • needs BCD update: Set this label if the issue involves documentation for new features or behavior that would first need data about when it's implemented.
  • needs content update: Set this label if the issue fix in another repository will need an equivalent fix in the mdn/content repository.
  • needs decision: Set this label if the issue involves a team consensus on the approach. The consensus can be reached via a discussion or a synchronous internal meeting.
  • needs example update: Set this label if the issue involves synchronizing code examples in another repository. If the repository is external, it probably needs to be converted to an internal live sample or transferred under MDN first.
  • needs info: As mentioned above, set this label if any information is requested, either from the issue author, from the author of the content in question, or from someone else, in order to proceed with the issue.
  • on hold: A generic label to indicate that the issue should not be worked on yet.
  • waiting for implementations: Set this label if the issue involves a feature that is not yet implemented in browsers and therefore don't qualify for our documentation criteria.

After you've analyzed and validated the issue, and applied the appropriate labels (type, goal, effort, open to community), the triage process is complete and you can remove the needs triage label.

Closing an issue as not planned

If an issue does not map to any actionable task, you should consider closing the issue as not planned. Click the dropdown next to the Close issue button, and select Close as not planned. Post a comment explaining the reason for closing the issue. Also add one of the following labels:

• closed: browser bug: The issue reports unexpected behavior in the reporter's code or in MDN's code, but the cause is a browser bug. The issue is also not significant enough to warrant a BCD note.
• closed: question: The issue is based on the reporter's error or misunderstanding, and the content is already correct and clear. However, you should still acknowledge the report and consider whether the content can be clarified further to prevent similar questions in the future.
• closed: wontfix: The issue reports a valid problem, but MDN decides not to fix it. Common reasons include the work being out of scope, the required effort outweighing the benefit, or content and code working as intended.

Closing an issue as a duplicate

When an issue reports a problem that is already tracked elsewhere, you can close the issue. They don't have to be exact duplicates; if the issue is similar enough to an existing issue, they can be merged as a single issue that's fixed together.

If there is a GitHub issue that tracks the same problem, click the drop down next to the Close issue button, select Close as duplicate, and paste the URL of the other issue. If the duplication is apparent, no comment is necessary; otherwise, post a comment explaining why the issues are duplicates.

If the problem is tracked but not via a GitHub issue (such as web docs backlog), you can close the issue as not planned, post a comment, and add the closed: duplicate label. This label is optional for issues closed via the Close as duplicate option, but helps with searching for duplicate issues later.