A repo used by the Web Compatibility community to track issues reported via webcompat.com

Labels are used for helping to filter bugs into groups but also to track the status of the bug. Here’s what each label means:

• browser-xyz - The bug exists in xyz browser
• ios - The bug exists in an iOS browser
• mobile - The bug exists on mobile devices
• nsfw - The website has content that could be considered offensive
• os-android - The bug exists in an Android browser
• windows - The bug exists in a Windows browser

Status labels which should only be used when a bug report is still open. These are in the order the bug process should typically follow, with the exception of needsinfo and leaveopen.

• status-needstriage - The issue needs to be screened and prioritized
• status-needsdiagnosis - Issue needs further analysis to find the cause
• status-needscontact - The issue has been analyzed, a contact for the site is required
• status-contactready - A contact has been found, it is ready for someone to contact the site
• status-sitewait - The web site with the issue has been contacted
• status-needsinfo - Issue needs more information, usually means process is blocked until info is provided.
• status-leave-open - The issue has been analyzed, and for some reason it was decided that this issue needs to remain open. The person who labeled it this way, will handle it further.

Status labels which should only be used when a bug report is closed.

• status-duplicate - Issue is the same as an already-reported issue
• status-fixed - Issue is fixed
• status-incomplete - The report requires more information to be actionable
• status-invalid - Issue is not a web compatibility issue
• status-wontfix - The issue will not be fixed
• status-worksforme - The issue can't be reproduced

If you’re using Webcompat.com already, you’re probably pretty awesome. So why do you need to read this? Well from experience we know a few tricks that make the web compatibility process go even smoother. And who doesn’t want to learn sweet new tricks?

• Fill the bug report form out completely. The more information you provide the easier it is for volunteers to understand the problem
• List any other browsers you tested the site with
• Try to avoid reporting issues for sites that are broken in all browsers. We like to focus our energy on sites that work in one browser but not others
• If you feel comfortable dig in and analyze the bug as well

• Confirm that you can reproduce the error. Ideally you should use a clean browser profile. See this tutorial for Firefox.
• Set any related labels - if the bug appears on Chrome for Android, set the “browser-chrome” and “os-android” labels
• Provide details on which piece of code is broken
• List out any relevant error codes
• If possible, suggest a way to fix the code to work in all browsers
• Once complete, add the “status-contactready” label
• If you feel comfortable find a contact at the site and reach out

• Once a bug is set to “status-contactready” the site can be contacted
• After you have attempted to make contact remove the "status-contactready" label and add "status-sitewait" so others don't attempt to contact
• Leave details about who you are contacting, example “Joe Webmaster - Developer at Company X”
• Be careful not to leak any private information like email addresses, phone numbers
• If you post somewhere public like twitter, include the link to the tweet in the bug for easy tracking
• If you receive an issue tracking number from the site include this in the bug
• When you receive responses, leave some information on the bug (paraphrasing is fine)
• If no response is received after a week or two, try another method. After a month or three contact attempts we can stop and revisit it later