Thunderbird:Bugdays

<< Back to Thunderbird Testing

Welcome to the Thunderbird Bug Day wiki!

Join us to improve the bug reports in Thunderbird's bug database.

You might also visit Planning for bugdays, and other Thunderbird wiki pages for information about the state of Thunderbird, planning, and ways you can help and provide feedback.

Who

You

In contributing to improving Thunderbird's quality, you'll feel that the program you use daily is a bit yours. Rub elbows with new and experienced contributors as you take a break from your boring everyday routine. No coding, (almost*) no experience required, no heartache.

If you are new to our amazing open source community, the information below will help you get started. Anyone can participate and be a valuable contributor. And people are available to assist you.

Why

Resolving bugs is the goal. To do that, some first need cleaning, and there are lots (LOTS!) of bugs:

• some are in a state that makes them hard to fix
• some might not be real bugs and need confirmation
• some are poorly worded

Bugdays are help newcomers join with experienced people in cleaning up the database and drive down the red (UNCONFIRMED) line in this chart. another chart view

Schedule

Staffed sessions allow you to participate, day or evening, at any location in the world. Attend all sessions, or just part of one. If you can't attend a scheduled session just drop in between sessions - someone might be hanging out who can help you. If you can't participate today, we invite you to participate in a future bugday. Or work on any bug any day or time - see Where about getting help.

Click in a UTC link below to get the session start time for your point on the globe.

	Sessions
Timezone	Session 1 13h-15h UTC	Session 2 19h-21h UTC	Session 3 02h-05h UTC
Los Angeles, USA   (PDT=UTC-8+1)	Thu 06h-08h	Thu 12h-14h	Thu 19h-22h
New York, USA   (EDT=UTC-5+1)	Thu 09h-11h	Thu 15h-17h	Thu 22h-01h
São Paulo, Brazil   (UTC-4+1)	Thu 10h-12h	Thu 16h-18h	Thu 23h-02h
UK   (BST)	Thu 14h-16h	Thu 20h-22h	Fri 03h-06h
Berlin, Germany   (CEST=UTC+1+1)	Thu 15h-17h	Thu 21h-23h	Fri 04h-07h
Moscow, Russia   (UTC+3+1)	Thu 17h-19h	Thu 23h-01h	Fri 06h-09h
Beijing, China   (UTC+8)	Thu 21h-23h	Fri 03h-04h	Fri 10h-13h

Where

#bugday IRC channel is the place to get help. It's easy to prepare ahead - choices include:

• Web service (free mibbit)
  1. open Mibbit #bugday
  2. pick a nickname
  3. click Go
• Chatzilla plugin for Firefox
  1. Get ChatZilla Firefox extension
  2. Connect to server - click irc.mozilla.org
  3. Join the channel - click #bugday, #tb-qa
• Client application
  1. Get one of the following: Windows clients, MacOS clients, Linux clients
  2. Connect to server - /server irc.mozilla.org.
  3. Join the channel - /join #bugday or /join #tb-qa

On non-bugdays you can get help at #tb-qa or #qa. More about mozilla IRC and mozilla channels. More IRC help.

How

Need help? Get on IRC and post a note in the bugday or tb-qa IRC channel.

New to bugzilla?

• Searching in bugzilla can be tricky. Quicksearch tricks and Andvanced Search can help.
• You probably can't change most bug fields. But you can add a bug comment detailing what should be changed and why. Or inform someone in the IRC channel and they will assist you.
• See Bug triage about how to get upgraded privileges to change bug fields.

Go:

1. Get an account - easily created at bugzilla account.
2. Protect - Backup your data. Use a test profile esp. if bugs might cause dataloss (see next point).
3. Make a test environment (optional) - Testing_pre-release_versions and Profile manager describe to how test and not disturb your production setup.
4. Get a build - Testing is best done with nightly trunk builds - trunk is where Thunderbird 3 is currently in development and it has all the latest fixes. If you cannot use trunk, please make sure you use the latest update of Thunderbird version 2.
5. Pick bugs - current bugday "Focus" offers suggestions about which bugs to work on.
6. Work bugs - For UNCONFIRMED bugs, you should attempt to replicate the problem specified in the bug report, and mark as "confirmed" if you are able to replicate and the steps to reproduce are well documented and easily followed and the problem exists in trunk build. If you are not running trunk but can replicate with current release, please comment but do not confirm. If you are running trunk and cannot replicate, you might close it dupe, WFM, INVALID, or perhaps the issue is not easily reproduced.

   Other helpful steps include:

   • Clarify bug reports without distorting or changing the original problem.
   • Change the summary to be more accurate to the problem being reported, and if appropriate remove words so summary is less chatty - a bug should not read like a book
   • Close bug reports as WORKSFORME, INVALID, or INCOMPLETE when it's appropriate to do so (see status descriptions to find out what is appropriate).
   • Ask bug reporter in a bug comment to provide missing information that will help to replicate and ultimately fix the bugs they report.
   • Remember to cite what version(s) of Thunderbird you are using.
7. Give feedback (see feedback heading below)

For more helpful information see:

• Thunderbird Bug triage - expert tips, extensions, reference documents
• Bug Writing Guidelines describes how to write an effective bug report that leads to bug fixes.

Give us feedback

Please post a note in #bugday or #maildev about your experience: problems, questions, ideas to improve documentation, number of bugs touched, where you learned about bugday, and overall thoughts about Thunderbird. We really appreciate your help today and your feedback is very valuable.

Thanks!

Thanks so much for your help. Your efforts help us to improve Thunderbird. We could never do this without you and the entire volunteer community.