You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
What Bugzilla fields mean in Mozilla Site Evangelism.
| Where Used | Code | Definition |
|---|---|---|
Product |
Tech Evangelism |
All Tech Evangelism bugs are filed in the Tech Evangelism product in Bugzilla. |
Component |
Language-based |
Tech Evangelism is organized by language into components. Choose the most appropriate component based upon the language of the site. |
Priority |
P1 |
Major Site, Major problem - Take care of these
first. Each component owner is responsible for
maintaining a list of top sites and for marking
top site bugs with the |
Priority |
P2 |
Major Site, Minor problem - Take care of these along with the P1 bugs if possible, especially if the problem can be easily addressed. |
Priority |
P3 |
Minor Site, Major Problem - Handle these sites on a time available situation. We need to make sure that we get the most bang for the buck in terms of investing our time. If Evangelizing the site will help develop helpful documentation that can be leveraged in helping other sites then it can be addressed before a higher priority issue. |
Priority |
P4 |
Minor Site, Minor Problem - Unfortunately we don't have time for these now. We will have to address them at some later date. |
Keywords |
evang500 |
Use the evang500 keyword to distinguish important sites that need to be to be handled with care and with a high priority. Use the top site list for each component to find Top Evangelism sites in each language. |
Severity |
Major |
|
Severity |
Normal |
|
Severity |
Minor |
|
Status |
UNCONFIRMED |
A status of UNCONFIRMED is assigned to bugs that are filed by new members of the community who have not yet developed a proven track record. QA these as they come in according to the ideas outlined in this document. |
Status |
NEW |
New bugs are those that have been confirmed or have been filed by someone with automatic confirmation rights in Bugzilla. |
Status |
ASSIGNED |
Change an Evangelism bug's Status to Assigned only when you have completed analyzing the site and have sent the Evangelism Letter to the site. When analyzing a site for the first time, do more than look at the originally reported page. Look at several pages and determine the overall nature of the problems on the site and send an Evangelism Letter with the originally reported URL plus the list of other pages you tested and a description of what they need to do in particular as well in general. Update the bug with the Status Whiteboard qualifiers described later in this document and include in the bug description specific descriptions of the problems the site has: using LAYER tags, LAYER API, IE4 only API, Incorrectly Nested Tags,... Remember that we are asking them to do extra work. Be polite, professional and respectful. We don't want to piss anyone off. |
| Target Milestones | Month for follow-ups / Future |
Use Target Milestones to determine when an evangelism bug should be followed up. Tech Evangelism milestones are now Month oriented. Revisit bugs that have been evangelized [status == ASSIGNED]. Do not set a Target Milestone unless you have Accepted and Evangelized the site. A site that will not respond to two Evangelism Letters and will not fix their site is to have the Target Milestone set to FUTURE. |
Resolution |
WORKSFORME |
Can't reproduce problem |
Resolution |
DUPLICATE |
The Site has already been reported for similar problems. |
Resolution |
FIXED |
Site fixed the problem |
Resolution |
WONTFIX |
Do not use WONTFIX as a Tech Evangelism resolution. Instead
mark sites that have responded that they do not intend to
update their content with a |
Resolution |
INVALID |
In general, Do not use INVALID as a Tech Evangelism resolution. However some bugs may be marked as INVALID according to the component owner's discretion. |
Summary |
domain - short specific description of the problem with the site in terms of the user experience. |
Use the following format when entering the summary: For example, if http://mail.netscape.com/ has a problem with Layer based JavaScript, the summary might look like: netscape.com - mail uses document.layers |
Status Whiteboard |
not-responsive |
Use not-responsive in Status whiteboard mark sites which are not responsive. |
Status Whiteboard |
technote-needed |
If an issue is common enough to benefit from documentation,
mark the bug with |
Status Whiteboard |
plugin |
Use |
Status Whiteboard |
author |
Use |
Make sure you read the Getting Started before entering new bugs.
Mozilla Tech Evangelism is not intended to be your complaint service. Before filing a Tech Evangelism bug on a site, first complain to the site regarding their lack of support for Mozilla.
Be certain that the problem you are reporting is due to a Tech Evangelism issue. If you do not know for certain that the issue is Tech Evangelism, file a bug against the most appropriate product.
Choose the Component to which your bug belongs by Language.
Choose the Platform and Operating System
If you know for certain that the problem with a site is not Platform or Operating System specific, set the Platform and Operating System to All.
Choose the Initial State
Use Initial State of UNCONFIRMED to ask the Mozilla Evangelism Community to investigate the site for compatibility with Mozilla. Use the Initial State of NEW to record a site with known problems supporting Mozilla.
Choose the Severity
Use major, normal or minor Severities when reporting an Evangelism Bug. The other Severities do not have any real meaning for our purposes. Use your best judgment on how severe the problem is.
Assigned To
If you wish to handle contacting the site yourself, set the Assigned To field to your email address. Otherwise leave Assigned To blank which will assign the bug to the Owner of the component you have chosen.
Enter the URL
Enter the URL of the page or site that exhibits problems supporting Mozilla. If a particular page on a site has problems with Mozilla it is probable that other pages on the site exhibit similar problems. Visit the home page of the site and determine if it also has problems and what they are. If the site has problems in most of its content, then use the site's home page as the URL.
Enter the Summary
Enter the 'major portion' of the URL of the site followed by a - and a short description of the problem as related to what kind of problem you experienced with the site. You do not have to be technical in your description.
For example, if you were reporting on the web page
http://www.foo.bar.com/help/support/, the
'major portion' of the URL would be bar.com.
This will allow people to sort Evangelism bug queries by
their summaries and group bugs against the same company
together.
The summary is something that an end user would be able to write and understand. More technical descriptions of the problem will be added to the Status Whiteboard later when the bug is triaged and assigned.
Give a reasonably detailed description of the problem you have with the site. Many of the fields in Bugzilla we will use to track the bug are only available after a bug has been entered. Therefore give a reasonably concise description of the problem here. You will add more detailed information after you have filed the initial bug.
Enter in any information regarding your initial contact with the site. Customer complaints are more effective than an anonymous Mozilla Technology Evangelist email. If you want the site to support Mozilla you must register a customer complaint!
If you don't commit the bug it won't be saved!
If the page does not properly display, attach a screen shot of the page to the bug. Make sure to assign the proper MIME type when attaching the image. Please try to minimize the size of the image. We do not need to have a 1-megabyte jpg file of the screen shot. Reduce your color depth and the size of the area contained in the screen shot to reduce size. All you need to do is make sure the attached image illustrates the problems you are reporting.
If the page has invalid HTML or JavaScript, save the HTML or JavaScript to a local file on your machine and attach the file to the bug as text/plain. This gives us a record of how the page originally was written and allows us to compare later versions to the version you reported the problem with.
Review the bug and if necessary follow the QA procedures
Determine the Site owner
Try to determine the correct person to contact at the site using information from the site itself. If you cannot find the appropriate person then use the Internic's Whois to determine the necessary information.
Send Evangelism Letter
Use the Mozilla Evangelism Letters to send a letter to the Site owner describing the problems with their site and what they can do to update their content to support Mozilla and the Standards.
Remember to always be polite and professional when contacting sites. The E-Mail Message will be coming from your personal E-Mail account and you will be responsible for any statements you make.
Record the contact
Record in the bug that you have sent the Evangelism letter along with a general description of any comments you added to the basic Evangelism letter template as well as the contact information but do not attach the E-Mail you send to the Site owner.
Set the milestone for the bug to be at least a calendar month after the site is contacted. You can then query the milestone by month to follow up on sites that need to be retested.
Assign the bug to yourself and mark it ASSIGNED.
If the Evangelism Letter bounces...
Record the fact that the contact failed in the bug
If possible try to determine another contact at the site and resend the Evangelism letter. If you cannot determine a new contact, then record that fact in the bug and mark the Milestone to Future.
If the site responds negatively....
Mark the bug as with not-responsive in the
status whiteboard and move on.
We have plenty of sites to contact and can always revisit the ones that
initially refused to support us.
You must have permission to Confirm a bug in Bugzilla before you can QA a bug. You should also be well acquainted with the Evangelism process and have discussed the procedures either with Zach Lipton(irc: zach), Asa Dotzler (irc: asa) or another active member of the Evangelism Community before proceeding. Visit #evangelism or #mozillazine on irc.mozilla.org to find other members of the community.
Search Bugzilla for duplicates
If the site has already had an Evangelism bug filed on it, and if that bug has not been marked VERIFIED then change the Resolution to DUPLICATE by entering the number of the bug you wish to duplicate this bug against.
If there is any new information about problems with the site, then verify that the problems exist and record the information in the original bug's comments.
Visit the site
Visit the site to determine if it has any problems supporting Mozilla. If it supports Mozilla without any problem, then mark the bug resolution as WORKSFORME.
If the site does have problems and the bug is UNCONFIRMED, then change its status to NEW by confirming it.
Analyze the site
Determine if original bug report is accurate. Add additional comments as necessary
Review Assigned Bugs with milestones prior the current month
Visit the site and determine if problems still exist on the site. Visit more than one page to make sure the site has been completely updated. If the site still exhibits problems, then contact the site again or add non-responsive to the status whiteboard. If the site works fine in Mozilla then set the state to FIXED.
If the RESOLUTION is FIXED or WORKS FOR ME
Visit the site and determine if problems still exist on the site. Visit more than one page to make sure the site has been completely updated. If the site still exhibits problems then set the status to REOPENED. If the site works fine in Mozilla then set the resolution to VERIFIED.
If the RESOLTION is DUPLICATE
Visit the site and determine if the bug marked duplicate is actually a duplicate of the original bug. Make sure that the original bug contains all the information from the Duplicate bug.