580202 - Thunderbird problem/trouble reporting guideline at bugzilla.mozilla.org for general Thunderbird users

Status: RESOLVED WONTFIX

(support.mozillamessaging.com Graveyard :: Knowledge Base Articles, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Problem report from general Thunderbird user at B.M.O is usually;
- Problem descripton is unclear.
- User error is not sufficiently ruled out before bug open.
- Steps to reproduce is not provided, because general user reports one time
  failure or one time touble which he experienced during his daily use as if
  permanent problem. And, it's unclear even if STR is written by opener.
- Sufficient data is usually not provided.
  - Even for mail display issue, many of users don't(can't) see even mail
    source, and attached mail data since bug open is very rare.
  - When network related issue, POP3 log, IMAP log, SMTP log, NNTP log, ...,
    are required in many cases. But general user doesn't know about logging
    and about how to get log.
    I'm tired to write link to Mailnews-Logging page in each bug at B.M.O.
- As Thunderbird is mailer, user has to setup accounts etc. correctly.
  However, as written before, user usually doesn't rule out user's setup error.
  So, many of trouble reports from general user is merely help or support
  requests.
  It's one of big differences from problem reports by general Firefox users.
  When browser, URL with which he saw problem is usually sufficient as initial
  report if rendering issue.

As current "bug writing guidelines" of B.M.O is for developers and nightly testers who know about "what is bug(real bug)" well, I think document about "reporting Thunderbird problems at B.M.O" for general Thunderbird users is needed, in order to obtain high-quolity feedbacks from many general Thunderbird users.   
Can I start creation of a drafts for such document?

Comment 1

[WADA:World Anti-bad-Duping Agency]

As guide for general users, description like Opera's "How to submit good bug reports" is a start point.
> http://www.opera.com/support/
> http://www.opera.com/support/bugs/
And, many sections like "URL: What URL triggers this bug, if any?" are planed for "mail displaying issue", "mail downloading issue", "mail uploadig(IMAP) issue", "mail/news submission issue", "search messages issue", "filtering issue", etc. And, mandatory check items before open bug such as "rule out of no user's setup error", "check with -safe-mode", "check of Virtual memory Size, never Mem Usage only", ..., are also planned.

Note:
Opera's bug report page is similar to B.M.O's "guided page". 
> https://bugs.opera.com/wizard/
After it, "insident number" is sent via email. User can see his incidents only after reporting. To know other bugs, user need to go forums or newsgroup. It's reasonable as Opera is not free software nor open software. "Bug" is ordinaly confidential data.

Comment 2

[jenzed]

There is an old page on http://www.mozilla.org/support/thunderbird/bugs that is being retired and redirected to https://developer.mozilla.org/en/Bug_writing_guidelines. (See bug # 573283.) If you want to look at the content on the original page after the redirect has occurred, let me know - I saved a copy. 

I suggest you make your improvements on https://developer.mozilla.org/en/Bug_writing_guidelines. If you would to send me a draft I would be happy to help.

Comment 3

[WADA:World Anti-bad-Duping Agency]

> http://www.mozilla.org/support/thunderbird/bugs
Purpose of the page is same as Opera's one, but statements like Opera's is better for general Thunderbird users("customer" for you).
jenzed, there is no plan to create new version of support/thunderbird/bugs?

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> I suggest you make your improvements on
> https://developer.mozilla.org/en/Bug_writing_guidelines.

I have no plan to update Bug_writing_guidelines. I think that document is sufficient for Firefox users, even for general Fx users. (bug 279696 was closed as WORKSFORME by current Bug_writing_guidelines.)

Comment 5

[Wayne Mery (:wsmwk)]

The bug writing process definitely can use some help. getsatisfaction suffers the same issue. Ideally, the bugzilla UI creation *process* should guide user to a good report **based on the type of report**. For example these might be considered fundamentally different categories of issues, where different types of information are needed:
* stability
* connectivity
* UI

Unfortunately that's not likely to happen any time soon, unless we somehow provide our own front end to bugzilla. Personally, I think that's the best solution.  (That said, I do think there are few simple things that could be done on the guided bug form that would help immensely)

I don't want to splash cold water on what wada hopes to achieve, but frankly I don't hold out high hopes that improved documentation will greatly improve the situation - that is, to the extent that it reduces the number of bug comments needed to help a reporter. Because :
a) most bug reporters don't refer to documentation before reporting bugs
b) people who just created bugzilla accounts:
  b1) are not guided or educated by bugzilla itself whatsoever after creating their account, other than what's provided on the guided bug entry form
  b2) what they find is entirely dependent on them actively referencing some link buried in a super long bug entry web page
  b3) many don't even have a clue what they are reading or what to look for
c) newbies have short memories - the next bug they file often has errors

OTOH, web references for different situations *specific* to mail issues may ease the typing load of triagers. I say specific to mail issues, because there are plenty of other documentation available about crashes, filing good bug reports, etc. For example, the bugzilla references at
  http://quality.mozilla.org/docs/

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> I don't want to splash cold water on what wada hopes to achieve, but frankly I
> don't hold out high hopes that improved documentation will greatly improve the
> situation - that is, to the extent that it reduces the number of bug comments
> needed to help a reporter. Because :
> a) (snip) b) (snip) b1) (snip) b2) (snip) b3) (snip) c)

I absolutely agree with you.
My purpose of the document is:
  To simply write "read the document and re-state about problem, please"
  in a bug *specific* to mail issue,
  if problem description is unclear, if no STR is provided or STR is unclear,
  or if required data for diagnosis is not provided by bug opener.
I'll try to extract good statements from http://quality.mozilla.org/docs/
I'll try try to put links to good documents in the Guide. 

To improve current situation, I think Product=Thundebird-Feedback like one is needed. If BUG by general Tb users at B.M.O is opend with Product=Thunderbird-Feedback, develepers don't need to read such hard-to-understund reports. And, you can close such bugs with status=INCOMPLETE easier than current.
For tracking of incident(BUG if B.M.O), and for feedback of status of the incident to reporter, I believe B.M.O, which is based on Buzilla, is far better system than Web based systems like forums or current "Problem Report" or Feedback at getsatisfaction.
Product=Thundebird-Feedback is similar to current Evang bugs at B.M.O or bugs of Product=support.mozillamessaging.com.

Comment 7

[jenzed]

David Eaves is working on a project to make Bugzilla more usable for end users (and to make end user feedback more usable to Mozilla). (http://eaves.ca/2010/07/20/some-thoughts-on-improving-bugzilla/) I'd like to hear his comments about this issue.

In general, I think this is an issue much bigger than documentation (but I'm eager to help out with any documentation that will help).

Comment 8

[David Eaves]

Jenzed: thank you for the invite to this.

WADA: Love the idea, think it should be done and would love to know who needs to sign off on drafting new guidelines. My sense is go for it and lets debate something concrete rather than talk about abstract improvements.

Wayne: I completely agree with you as well... better guidelines isn't going to solve our problem (although they are always a good thing, especially for newbies).

The key, from my perspective is actually changing the choice architecture so that non-developers are weeded out of bugzilla before they even get to the "submit a bug" page. THat was my goal behind the bugzilla edits I made <a href=http://eaves.ca/2010/07/20/some-thoughts-on-improving-bugzilla/>on the post Jenzed referred to</a>.

Here we should go back to the landing page of bugzilla and see what we can do to shovel ordinary users to appropriate support queries.

In this regard I think we can do a lot to a) minimize the amount of junk that ends up in bugzilla and hopefully b) get people who need support to the right place faster - ideally without needed a human (like Roland).