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. Read our [ contribution guide ](https://github.com/mdn/content/blob/main/CONTRIBUTING.md) to learn more. 
  * If you have a question, you can ask it in the [ MDN Web Docs chat rooms ](/en-US/docs/MDN/Community/Communication_channels#chat_rooms) instead of filing an issue. 

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. 

##  Guidelines for reporting an issue

[ Issues ](https://docs.github.com/en/github/managing-your-work-on-
github/about-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

If you think you've found a bug with the content on MDN Web Docs or with the
look and feel of the website, search the current open issues in the [ relevant
repository ](/en-US/docs/MDN/Community/Contributing/Our_repositories) and make
sure nobody else has reported the issue.

###  Reporting an issue

  * Depending on the type of problem you've discovered, report it by filing an issue on one of the followings: 
    * [ documentation ](https://github.com/mdn/content/issues/new/choose)
    * [ translation ](https://github.com/mdn/translated-content/issues/new/choose)
    * the website's [ look and feel ](https://github.com/mdn/yari/issues/new/choose)
    * the "Try it" [ interactive example ](https://github.com/mdn/interactive-examples/issues/new/choose) section 
    * [ DOM examples ](https://github.com/mdn/dom-examples/issues)
    * [ Learning area ](https://github.com/mdn/learning-area/issues)
    * the [ browser compatibility ](https://github.com/mdn/browser-compat-data/issues/new/choose) information 
  * Choose the appropriate category to report the issue. For example, to report a content bug, use the [ Content issue ](https://github.com/mdn/content/issues/new?assignees=&labels=needs+triage&template=content-bug.yml) 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 the action required to resolve the issue. It must also list the task or sub-tasks to be completed to resolve the issue. Some other guidelines include: 
      * Use the description field to indicate the status of the task or sub-tasks by using checklists. 
      * Update the status of a task in the issue description instead of commenting on the issue. Use [ task lists ](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists) in the description if an issue has multiple parts. 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 resolve the issue. 
  * If the information you provide in the issue is incomplete, then you might be contacted later during the  issue triaging process  . 
  * If you find yourself in one of the following situations, move the conversation to [ MDN's discussion on GitHub ](https://github.com/orgs/mdn/discussions) : 
    * A discussion needs to take place to clarify an issue. 
    * A discussion begins after opening the issue. 
    * The issue has no clear consensus on its resolution. 
    * The requirements for completing the task expand while it's being resolved or the work is unclear. 
  * For minor and small bugs, you can  make the changes yourself  and submit a pull request. 

###  Creating a task list issue

If the issue you're opening is not to report a bug