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 ) 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:

Change the Status

• 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.

Always explain status changes

• Folks get upset if you change the status of a GS topic. The GS web page usability is not clear when a status changes; folks get upset when a status change is not explained so of whenever you change the status of a reply (e.g. to "not a problem" or to "Solved" or "Answered") always add 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.

Change to a Problem if appropriate

• 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.

Merge 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.

Create a summary thread if users post their problem across multiple threads

• Lots of times, desperate users post fragments or all of their problems as replies to multiple (let's call it 'n') threads. This would be great if their problems were 100% identical to the problems in the multiple threads and if the threads were active. Unfortunately 99% of the time the problem is not the same and more than 50% of the time the thread is inactive or hopelessly muddled and confusing with several users asking for help with multiple similar but not identical problems.

• In their desperation, they don't realize that this makes it more difficult to help them. They figure that this will maximize the exposure and likelihood of getting a response.

• Recommendation: Create a new "summary" support topic for them with a relevant title and with content paraphrasing all of their problem across all the threads. And then post a reply (using the "use one topic, not multiple topics boilerplate") on all 'n' (or at least 2 of n) of their threads linking to the summary support topic and unsubscribe from the other threads in Get Satisfaction.

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 supports the community on a regular basis (e.g. several worthwhile replies a month), please consider making them a GS "champion" for Mozilla Messaging

Dealing with Profanity, Insults and Personal Attacks

Get Satisfaction's Company-Customer Pact and Mozilla's community culture requires both staff and users to be respectful and considerate.

If you see a post on Mozilla Messaging's Get Satisfaction site that contains profanity or insults and you are not a GS moderator, email the link and a request for removal of either just the the profanity or the entire reply or topic to:

• (Mozilla staff) support AT getsatisfaction.com
• (Mozilla contributors) roland AT mozillamessaging.com

Get Satisfaction Moderators

Removing Replies that contain attacks and/or profanity

If you are a Get Satisfaction Moderator, then feel free to remove replies that are attacks or have profanity without useful information (if you want to retain the reply but redact the profanity see "Removing Profanity and Attack Language from Replies"). Use the boilerplate for Removing Replies that contain attacks and/or profanity

Archive the topic if there's profanity and only 1 ranter & ranter doesn't really want help

If there's only 1 user (or several users all of whom are profanely ranting and not helping) is merely ranting with profanity or attack language and doesn't really want help from the community, use the GS "Archive" feature to archive the topic so it doesn't show up in search results. Use "Archive the topic if there's profanity and only 1 ranter & ranter doesn't really want help" boilerplate explanatory language

Removing Profanity and Attack Language from Replies

If the user does really want community support despite the rant, then reply with "Removing Profanity and Attack Language" reply text and emoticon text

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(s) (e.g. if the bug is bug 62345 make sure all relevant GS topics are tagged "bug 62345") and please fill in the GS tag url (e.g. http://getsatisfaction.com/mozilla_messaging/tags/bug_62345 ) into the bug's URL field and add "[gs]" to the whiteboard
2. this bug needs to be triaged into an appropriate release and GS folks need to be informed by adding a reply to the GS topic with the results of the triage
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

Bugzilla GS related whiteboard conventions

• "[gs?]" if there is a need to find matches in Get Satisfaction or to see if this bug has been reported by users in Get Satisfaction

Triage process for periodic GS triage meetings

GS -> Bugzilla

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

1. if the problem is actually a bug, search for an equivalent existing BMO bug
2. if there is no existing BMO bug, create a new one
3. in the GS topic: add the tag "bug nnnnnn" (where nnnnnn is the BMO bug number)
4. in BMO bug nnnnnn: in the whiteboard field, add "[GS]"
5. in the URL field, add a link to the GS tag, like this: http://getsatisfaction.com/mozilla_messaging/tags/bug_nnnnnn
6. in a new comment, add the short URL of the GS topic (Right Sidebar->Share tab->Get a short URL) and the current GS topic summary; add "(canonical)" after the short URL if the GS topic has been tagged "canonical", like this:

 http://gsfn.us/t/xyz (canonical)
 Problem with Thunderbird

1. nominate the bug as blocking if appropriate
2. triage the bug in bugzilla using the normal bugzilla flags for the appropriate release
3. 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
4. set the GS topic to Problem, In progress or Acknowledged as appropriate
5. remove the "review" tag from the GS topic, tag it "reviewedyyyymmdd" e.g. "reviewed20100111"
6. 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:

• add [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