Thunderbird/Support/Workflow

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This page documents Mozilla Messaging Support Workflows for Mozilla Messaging Staff and volunteer champions including Bugzilla, SuMoMo Knowledge Base (SuMoMo is the codename for the KB only deployment of SUMO on support.mozillamessaging.com currently in preview/beta) and Get Satisfaction

Get Satisfaction

Roland's personal workflow

see my post on get satisfaction about my workflow

Normal Users' Workflow

1. pick a topic to help out with from http://getsatisfaction.com/mozilla_messaging/admin/topics or from email or RSS and click on it
2. Change the title if it's not helpful e.g. "help" is not helpful, profanity is not helpful usually the best thing is to remove the profanity from the title and replace with a concise description of the problem
3. Add tags
4. If necessary consult QA and Development, see "Workflow when dev & QA need to be consulted "
5. Formulate a reply and post it (replies should be brief and friendly: e.g. links to KB articles on MZ and SuMoMo, request for more information, links to other threads where the same problem was solved, etc)
6. If resolved, set to Answered or Closed (see "Resolve it! below)
7. If it's a problem (and most Questions are really Problems) change to a Problem and "In progress" if not solved
8. Change to an "Idea" if it's a feature request
9. If you think it's a blocker to a future Thunderbird release, tag it "review" (the review tag will be removed at a future, periodic GS Triage meeting)
10. If a SuMoMo kb article update or a new article is required, tag it "add to SuMoMo". (If the article is relevant to programmers instead of users, tag it "add to MDC".)
    • If you want to help further, create a bug in Bugzilla (under the product "support.mozillamessaging.com"). Link to the Get Satisfaction article in the bug description. On Get Satisfaction, tag it with the bug number "bug nnnnnn" (e.g. "bug 123456") and "docs bug added" and leave a comment with a link to the bug.
    • If you want to help even further, write the article in the Knowledge Base, then close the bug and update the Get Satisfaction issue with the tag "documented on SuMoMo" and a link to the URL of the article.
11. If there's an existing bug, post a link to it in a comment and tag it "bug nnnnn" e.g. bug 532489
12. If not, and you think a bug needs to be created, create a bug, see "Bugzilla"
13. URL Tags
    • If this Get Satisfaction topic is a duplicate of another GS topic THEN decide which one is canonical and tag the duplicate ones as "duplicate of shorturlOfCanonicalThread" e.g. "duplicate of http://gsfnustnr95"
    • "from:short url" "from:http://gsfn.us/kdjk", (GS URLs that feed into this topic)
    • "see:short url" e.g. "see:http://gsfn.us/kdjk" (GS URLs that this topic references)

Merge workflow

1. to be filled in

Workflow for Company Updates

When do you issue a company update on Get Satisfaction? no hard and fast rules, generally for news and not problems or solutions

• e.g. support over holidays
• new releases
• a tricky "official" solution that's been discussed in many other threads

Only MoMo Staff are allowed to do Company Updates

Workflow when dev & QA need to be consulted

1. do a quick Bugzilla Search for any existing bugs
2. if relevant bugs, tag topic "bug nnnnn" where nnnnnnn is the bug number e.g. "bug 529138"
3. if the team is working on the bug, reply with a link to the bug and then set to "Answered" or "Solved" if no further workaround or interim fix is coming, otherwise set to Problem, and then Status "In progress" if you are working on a user oriented workaround that's not in bugzilla
4. if you are not sure, then email the QA & Dev team and get their advice by clicking on "Share with employees..." and "Select employees..." and the selecting the relevant people->Email these people and then write a brief note contextualizing why you are consulting Dev and/or QA and then click "Share this topic"
   1. QA and triage - Ludovic Hirlmann, Wayne Mery (search, filters, imap,space, major and critical bugs), Mark Banner
   2. Lightning - Martin Schröder and Phillipp Kewisch
   3. UX, UI design, fit and polish - Andreas Nilsson and Bryan Clark
   4. Global Search and search in General - Andrew Sutherland
   5. IMAP and other tricky Thunderbird details - David Bienvenu
5. If a new Bug is required then create a bug (see "Bugzilla" below)

Resolve it!

If you feel your reply answers the question 80% and you have moderation abilities, i.e. you are a Mozilla Messaging Employee or champion, then:

1. use "Moderator Updates" on the right Sidebar and set the status to "Answered" for Questions and "Solved" for Problems after you have submitted your reply.
2. Folks get upset if you do this and they feel their question is NOT answered or their problem is not solved so of there's any doubt in your reply put an explanation e.g. "Setting this to Solved (or Answered) because I am pretty sure this [[[fill in the blanks]]] solves your problem." If it turns out that's it not Solved or Answered then set the topic to Problem, In progress.
3. If you look at a topic and leave a reply but it's not Answered or Solved then change it to a Problem and set status to "Acknowledged" or "In Progress" if that make sense.Try not to leave topics that you reply to without updating the status.
4. Duplicate Threads: Lots of times, users post multiple duplicate threads. This of course makes support harder than it should. Best thing is to catch it early and merge them using GS's merge facility. However 90% of the time, you won't catch it early. In this case it's best to anoint a "canonical thread" (or start a new one) and leave it at "Problem, In progress" and close (i.e. set to Question, Answered or Problem, Solved) the other duplicate threads (but of course link to the canonical thread and state clearly that you are leaving the canonical thread open so people won't be offended you are closing the duplicate threads). Tag the canonical thread "canonical" plus "canonical [1-3 word topic summary]" e.g. "canonical message preview". for an example see: http://gsfn.us/t/ooa7.

Give Thanks

If somebody solves a problem or answers a question and you notice it, please give thanks as follows

1. If it's a complete answer or solution, leave a comment e.g. something like "Thanks for contributing to community support."
2. If their answer or question is incomplete or a wee bit inaccurate, post a reply (comments are really only meant for short items) with a correction or an addition to make their answer/solution complete and thank the person as well
3. If a person helps does community support on a regular basis, please consider making them a GS "champion" for Mozilla Messaging

Bugzilla

New Bug Workflow

once a GS topic or through some other support channel) has been determined to be a bug that hasn't been previously filed, then

1. a bugzilla bug needs to be filed and linked and tagged into the GS topic
2. this bug needs to be triaged into an appropriate release and GS folks need to be informed
3. if necessary a workaround needs to be developed and then added to SuMoMo if substantial enough and/or as a GS topic

GS Triage

Triage means driving the number of topics tagged "review" in Get Satisfaction down to zero by creating a bug and setting the bugzilla flag(s) appropriately or by finding an existing bug

Triage process for periodic GS triage meetings

GS -> Bugzilla

For each GS topic tagged "review" i.e. for all bugs in getsatisfaction.com/mozilla_messaging/tags/review :

1. if it is a bug and there is an existing bug then
   1. add the tag "bug nnnn" where nnnn is the bug number to the GS topic
   2. in the URL field of the bug put in the short url (Right Sidebar->Share tab->Get a short URL) of the GS topic
   3. in the whiteboard field add "[GS]"
   4. nominate the bug as blocking if appropriate
2. else
   1. create a new Bugzilla bug
   2. add the tag "bug nnnnnn" where nnnnnnn is the bug number to the GS topic
   3. in the URL field of the bug put in the short url of the GS topic
   4. in the whiteboard field add "[GS]"
   5. nominate the bug as blocking if appropriate
3. triage the bug in bugzilla using the normal bugzilla flags for the appropriate release
4. post an reply to the GS topic stating an existing bug was found or a new bug was created and that a tentative release has been established (as always never promise a specific date or release for a fix). Mark this reply by clicking "Mark as company solution" so that this reply is highlighted
5. set the GS topic to Problem, In progress or Acknowledged as appropriate
6. remove the "review" tag from the GS topic, tag it "reviewedyyyymmdd" e.g. "reviewed20100111"
7. if the bug has been fixed, tag the GS topic as "fixed3xx" xx= release number e.g. "fixed301", "fixed302", "fixed310"

How to determine if a GS topic should be reviewed

If it causes customer pain, then it should be reviewed e.g. anti-virus problems, dataloss, a feature that requires further polish e.g. making autoconfig manual config easier or more obvious, a missing feature that would ease user pain, etc.

Some ways to detect customer pain in GS:

1. The ones with the most Me Toos i.e. http://getsatisfaction.com/mozilla_messaging/admin/topics and then click on "Me Toos" to get the topics that most folks have said they are having problems with
2. The ones with the most Replies i.e. http://getsatisfaction.com/mozilla_messaging/admin/topics and then click on "Replies" to get the topics that have the most replies, these generally are painful

Bugzilla query for GS bugs

bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;query_format=advanced;status_whiteboard=[gs];resolution=---

Bugzilla -> GS

Once a Bugzilla bug that has [gs] has been fixed:

• change [gs] to [gssolved] in the bug
• edit the GS topic and add a tag "bug nnnnn fixed" and fixedbuild e.g. "fixed3.1", "fixed3.2"
• ask users in the GS topic to test the fix in the build it is fixed in e.g. 3.1