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?
Filing web compatibility bugs
- 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
Analyzing web compatibility bugs
- 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
Contacting the site/company
- 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