| Component | Open | Closed |
|---|---|---|
| African | 2 | 9 |
| Asian | 76 | 40 |
| Authors | 55 | 34 |
| China | 28 | 10 |
| English: Non-US | 141 | 121 |
| Europe: Central | 31 | 82 |
| Europe: East | 75 | 31 |
| Europe: West | 723 | 809 |
| Middle Eastern | 82 | 40 |
| Pacific Islands | 7 | 4 |
| Plugins | 49 | 36 |
| The Americas | 82 | 65 |
| US Banks | 46 | 77 |
| US Ecommerce | 174 | 149 |
| US Edu | 35 | 67 |
| US General | 893 | 1561 |
| US Gov | 26 | 48 |
| Total | 2525 | 3183 |
Language vs Region based Components
There appear to be two positions on the component organization for Tech Evangelism in Bugzilla. One view is that keeping the region-based component structure is the way to go while the other is that having a single owner for regions which encompass multiple langauges is a problem.
Recommendation: I think that using language based components for languages supported by active evangelists is better than the region-based approach. Language-based components would allow the recruitment of individuals familiar with the language and would trancend regional boundaries. For example, A French Component would be able to handle France, French Language Canadian sites, etc without mixing in other languages from Europe. If a current owner wishes to keep a region-based component, they should not be forced to change if they are an active participant.
Based upon current participation, I recommend the following components. If more active participation is found for particular languages, they can be added to this list and the bugs moved from International to a new component. If country based distinction needs to be made it can be done via the URL or via a comment in the status whiteboard.
If there is a language not listed here and you wish to become the "owner" of such a language component, please contact bc@bclary.com.
Recommendation: Use Email aliases
for Component Owners and QA assignments.
This will allow easy transition of ownership/qa in the
future and allow easy watching of specific Tech
Evangelism components. For example,
us@evangelism.bugs.
We still need people who will commit to watching the
Email Aliases
for each component who will be
responsible for triaging bugs, proactively contacting
top-sites, responding to questions from site
administrators or developers. Contact
bc@bclary.com if you wish to sign up to handle a
component!
Eliminate unnecessary status whiteboard markers
The existing Status whiteboard markers in http://www.mozilla.org/projects/tech-evangelism/site/procedures/bug-fields.html
such as SYNTAX-xxx,
PROPRIETARY-xxx,MIME-xxx,XBROWSER-xxx,
PERFORMANCE-xxx,xxx-HTML,XXX-JS,
USERAGENT,DENY,TOOL,
DOCTYPE,LAYER have not been
effective and should be eliminated.
Add following status whiteboard markers
Use wontfix in Status whiteboard instead
of WONTFIX resoluton to mark sites which are not
responsive.
Retain the technote-needed status
whiteboard marker to identify needed support
documentation.
Used to replace plugin component
Used to replace authors component
Focus on User Complaints
If a user considers a site to be important to them, it should be their responsibilty to take action and complain to the site. It is not our responsibilty as Mozilla Tech Evangelists to do their complaining for them.
We must provide a mechanism for users to record their complaints about sites in our bug system. Ideally an automated method that would either file a bug or comment an existing bug for a site would be available. All the user would have to do it click on a button and fill in the necessary forms. Not sure how we can do that without requiring them to have an active bugzilla account.
Until such an automated means of users submitting site issues to bugzilla is available, we will have to reply upon Documentation.
Provide proactive support for important sites
For top sites we should make the effort to contact the site and provide guidance, references and support to help them support Mozilla.
Update Tech Evangelism Documentation
The Tech Evangelism site http://www.mozilla.org/projects/tech-evangelism/ needs to be updated to reflect the new policies, components, procedures, etc. In particular we will need a page that users can visit to learn how to properly handle site compatibility issues and a page for site owners/adminiatrators/developers to visit to learn how to query bugzilla for issues on their site, where to find resources, how to request help in a bug etc.