Compatibility/Epic Jira

From MozillaWiki
Jump to: navigation, search

The Web Platform is reviewing the core of the work for the task which are more than 2 weeks long. Sometimes they need to make an assessment if there is a Web Compatibility priority in executing this work.

Let's introduce some criteria and help to determine if there is a Webcompat concern for a work.

Implementation gaps are not necessary webcompat issues. Chrome or Safari might have a feature which is already implemented but not really used on the Web, hence not creating webcompat issues. Implementation gaps may become webcompat issues for multiple reasons. Note that sometimes fixing a core issue will create a cascade of events. It is possible that more breakage will surface as a result of fixing the Webcompat Core issue. `window.event` is an example of this. Once Mozilla added it, the result was a cascade of breakages because some sites were using !window.event as a way to identify Firefox.

How does the webcompat team define Webcompat priority?

There is a list of bugs ordered by Webcompat Priority. Some of them are still in the process of being triaged.

  • Are there many sites impacted? (large surface)
  • Does the site have a high rank (international or locale)? (depth of the issue)
  • Is it cosmetic or functional? (severity of the issue)

How do I know if there is a webcompat issue?

You can check on bugzilla bugs associated with the Jira Epic:

  • Check if a Webcompat Priority flag has been set.
  • Check if SeeAlso contains links to webcompat issues.
  • Double check what is the Counter Usage of the feature for Firefox and other browsers?
  • Assess if it is already implemented in both WebKit and Blink.

Do I need site interventions mitigation?

Some core bugs take time to solve, the webcompat team can provide websites hotfix for some categories of issues.

I’m not sure?

Ask in #webcompat channel on matrix or slack about the bug you need to assess the priority