Mobile/Evangelism/Mechanics

This page suggests some technical details and tools for implementing the Mobile/Evangelism project.

Site Lists and Triage

We need a shared spreadsheet with the list of sites, and the following fields:

• Name - canonical site name, or owning company (e.g. "AT&T", "Basecamp")
• Root URL
• Language - the language the site is in, so people can pick up sites in languages they speak
• Tester (email) - the person who has the current responsibility to properly test this site, and file any necessary bugs
• Testing completed (date) - the last time the site was fully checked for problems
• Problems? (Y/N) - the outcome of that check
• Problem Type (not mobile aware / serious / minor ) - a simple summary of how bad things are
• Bugzilla query for mobile-evang bugs about that site - how you find all the bugs - searches in right product, with the mobile-evang keyword and domain as substring in URL
• Contact established? (Bug number which has info) - how you can find the info on how to contact the webmasters at the site
• Notes - freeform notes field

The hope is that this info, plus data mined from the Bugzilla query, can give us sensible metrics.

See also Mobile Web Compatiblity This page has historical content and might need to be adjusted.

Bugzilla

There is a Bugzilla product, Tech Evangelism, which currently has a large number of language-based components. We should use it for these bugs.

We need a way of distinguishing the bugs which are specific to the mobile evangelism effort. A meta bug is likely to get too unwieldy to track the large numbers involved. So we should use a keyword - mobile-evang or something similarly simple.

Other fields:

• The URL field should contain the full URL of the page with the problem; we can do site-based querying using substring searches
• We should have whiteboard markers relating to common problems ([webkit-css], [ua-sniffing] etc.)
• We should use severity to indicate the seriousness of the problem (blocker == site unusable; trivial == cosmetic glitch)
• We can use depends to track any engineering bugs which need to be fixed to make the site work
• We might use meta bugs (blocks) to track the single-point-of-contact interaction with a site, if we are contacting a particular site about multiple problems

Many of the language-based components have never been used. There is no need to bloat the component list to be "fair". We do have an "Other" component (which has lots of bugs in, suggesting that often people don't bother to file in the right language component anyway), and so we should delete all components which currently do not have any bugs (42 of the 78). The two "English" components are the most heavily used.