Mobile/Evangelism/Outreach plan

Goal

This document describes the process that we are using to discover, analyse and help reach Web sites not working consistently between Firefox for Android and other mobile browsers.

We want to insure that Firefox for Android users have as good an experience as when using a competing browser. For Web sites that needs to be fixed, we want to push standard solution that will allow any standard-compliant mobile web browser to display the web site correctly.

We want to do it with responsibility: we want to open the Web for all actors by pushing the use of standards. Except when this is not possible, we shouldn't recommend modification that would fix the Web site only for Firefox!

Process

The process is divided in three phases:

1. Detecting problematic web sites: what web site is not working well
2. Triage / Analyse of the problem: why is it not working well, and prioritize the
3. Outreach: telling the site why it is not working well

Phase 1: detecting problematic web sites

This phase consists in testing Web sites and determining if the experience is correct or not.

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_Android/Compatibility_Testing

Open point 1: how to report working sites? I guess a lot of the white sites on http://people.mozilla.org/~lmandel/arewecompatibleyet/#about may be just working ones.

Open point 2: a way to report without a bugzilla account?

Open point 3: asking Moz Reps of the different countries to bring a Top-100 for their countries

Who can help: anybody with an Android phone Result: a bug entry per non-working web sites.

Events that can be done: - The testing 1/4 hour (or longer). In the middle of another event, pause, test, report. This can be done online too. To coordinate with QA. - Mini-contest: by showing progress in testing by locale (25% of the Top-100 pl Web sites tested vs 12% of the sk ones), we can foster emulation. To coordinate with reps

Phase 2 : triage / analyse of the problematic

This is the most complex phase as: it needs to be carefully done not everybody have the technical background to do it. a. replicating the problem (anybody can help) b. categorizing the problems: [Critical point] UA: different web sites Android/iPhone/Fx layout: something doesn't look ok, what. Behavioural problem: an action doesn't work. Library problem Automatic tools to help c. determining the problem building team of “specialists” (UA, layout, DOM, …) each team make the basic analysis call for help of devs if needed

How: Triage meeting once a week → people take a few web sites to analyse. [Analysis in progress] in Whiteboard, Assignee to the person performing the analyse.

Contact in the regular team if more help is needed?

Phase 3 : outreach

Is there a contact address on the web page. Use it If not, internal call for help. Building a list of contact address (both internal/external). This list must be private. Special case for library problem: these are critical case, and we should try to use our dev engage team to reach them. This will likely be more efficient. Especially for “big” libraries.

How: Once analysis is complete → [Analysis complete], assignee = nobody. At triage people try to reach them (or to make the Original Reporter) to report using standard letter. Workflow [Letter sent] with bugzilla entry with the date and eventually address (if public). If no response after one week, second letter by internal (if external first) or by external (if internal first). If no response after two weeks, priority to be set to see if we can escalate – internally (big site) or to via Moz Reps of the country (“Who know somebody at …”)

When answer received: [Contact established]

When Fixed: [Resolved/Fixed or Resolved/Worksforme] and clearing whiteboard.

Events: statistics by country → mini-competition between countries Reps.