Thunderbird:Bugdays: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
m (Refine the draft)
Line 7: Line 7:
= Bug Day March 27, 2008 =
= Bug Day March 27, 2008 =


Our first bug day is March 27, 2008 according to the schedule below. Please be patient if we have to work any "bugs" out of our first bugday.
Our first bug day is March 27, 2008, using the time schedule below. Please be patient if we have to work any "bugs" out of our first bugday.


See the FAQ below before starting about what to do. Don't be concerned if you don't understand everything, just ask for help.
Before starting, see the FAQ below for information about what to do. Don't be concerned if you don't understand everything, just ask for help.


The focus of our first bug day is bugs with status unconfirmed, emphasizing on bugs created pre-Thunderbird 2 release. But you may certainly work on any open bugs that interest you. The page [[Thunderbird:Bug_Queries|Bug queries]] identifies several classes and categories of bugs, with some ratings of what areas are in most need of attention.
The focus of our first bug day is bugs with status unconfirmed, emphasizing on bugs created pre-Thunderbird 2 release. But you may certainly work on any open bugs that interest you. The page [[Thunderbird:Bug_Queries|Bug queries]] identifies several classes and categories of bugs, with some ratings of what areas are in most need of attention.
Line 15: Line 15:
= Schedule =
= Schedule =


Bug days are arranged into three sessions so as to be convenient for participants around the world. The three sessions target for those in Asia/Australia, Europe/Africa, and North/South America.  Of course, anyone may attend any or all sessions as they wish. Some help may hang around between or after sessions, so you may find someone in #bugday to help you outside of the scheduled times.
Bug days are arranged into three sessions so as to be convenient for participants around the world. The three sessions target Asia/Australia, Europe/Africa, and North/South America.  Of course, anyone may attend any or all sessions as they wish. Some assistance may hang around between or after sessions, so you may find someone in #bugday to help you outside of the scheduled times.


<table border="1">
<table border="1">
Line 62: Line 62:
</table>
</table>


A bit simpler schedule:
Simplified schedule:


'''Asia session - 14:00-16:00 UTC/GMT +8 hours (Beijing) (06:00-08:00 UTC)<br>
'''Asia session - 14:00-16:00 UTC/GMT +8 hours (Beijing) (06:00-08:00 UTC)<br>
Line 68: Line 68:
'''Amer. session - 12:00-14:00 UTC/GMT -8 hours (Los Angeles) (19:00-21:00 UTC)'''
'''Amer. session - 12:00-14:00 UTC/GMT -8 hours (Los Angeles) (19:00-21:00 UTC)'''


Please use [http://www.timeanddate.com/worldclock/ The World Clock] to help determine when a session is happening in your time zone.  
Please use [http://www.timeanddate.com/worldclock/ The World Clock] to determine when a session is happening in your time zone.  


= FAQ - How to I do this? =
= FAQ - How to I do this? =


What we want to accomplish is pretty simple:
What you want to do is pretty simple:
* Replicate the problem specified in the bug report and mark as "confirmed" if you are able to replicate '''and''' the steps to reproduce are documented and clear '''and''' the problem does not exist in trunk builds.
* Replicate the problem specified in the bug report and mark as "confirmed" if you are able to replicate '''and''' the steps to reproduce are documented and clear '''and''' the problem does not exist in trunk builds.
* Clarify bug reports without distorting the problems.
* Clarify bug reports without distorting or changing the original problem.
* Close bug reports as WORKSFORME or INVALID when it's appropriate to do so.
* Change the summary to be more accurate of the problem being reported, and if appropriate remove words so summary is less wordy
* Close bug reports as [https://bugzilla.mozilla.org/page.cgi?id=fields.html#status WORKSFORME, INVALID, or INCOMPLETE] when it's appropriate to do so.
* Ask reporters to provide missing information that will help to replicate and ultimately fix the bugs they report.
* Ask reporters to provide missing information that will help to replicate and ultimately fix the bugs they report.


You will want to test with [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Nightly Trunk Builds]. If you do not know how, ask for help on how to set it up. Or, if you are not permitted to use trunk, then use the [http://www.getthunderbird.com/ latest update of Thunderbird version 2] - currently 2.0.0.12.
Please check the following documentation for more about this process:
* [[Thunderbird:Bug_Triage|Bug triage]] 
* Read [http://www.mozilla.org/quality/bug-writing-guidelines.html Bug Writing Guidelines] to learn what is an effective bug report that will lead to bug fixes


Note: If you don't have the necessary rights to make a change to a bug see the [[Thunderbird:Bug_Triage|Bug triage]] page about how to get privileges, then add a comment to the bug detailing what should be changed and why. You can also make this known in the #bugday channel and someone will assist you.
You will want to test with [http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Nightly Trunk Builds]. Ask for help if you do not know  how to set it up. Or, if you are not permitted to use trunk, then use the [http://www.getthunderbird.com/ latest update of Thunderbird version 2] - currently 2.0.0.12.
 
If you don't have the necessary rights to change to a bug see the [[Thunderbird:Bug_Triage|Bug triage]] page about how to get privileges, then add a comment to the bug detailing what should be changed and why. You can also make this known in the #bugday channel and someone will assist you.


* Please check the following documentation
** [[Thunderbird:Bug_Triage|Bug triage]] process.
** Mozilla QA linked to from the "For Testers" section of mozilla.org/developer
** A good document on how to find existing bugs
** Read [http://www.mozilla.org/quality/bug-writing-guidelines.html Bug Writing Guidelines] to learn what is an effective bug report that will lead to bug fixes.


[[category:Thunderbird|*]]
[[category:Thunderbird|*]]

Revision as of 14:49, 24 March 2008

<< Back to Thunderbird Testing

Welcome to the Thunderbird Bug Day wiki!

Join us on IRC in #bugday at your regional time to discuss and work on bugs and get help from the Thunderbird / Mozilla Messaging team. Bug Days are an excellent way to contribute to QA efforts. It doesn't matter if you've been involved with Mozilla for years or if this is your first step into our amazing open source community. Anyone can participate and be a valuable contributor.

Bug Day March 27, 2008

Our first bug day is March 27, 2008, using the time schedule below. Please be patient if we have to work any "bugs" out of our first bugday.

Before starting, see the FAQ below for information about what to do. Don't be concerned if you don't understand everything, just ask for help.

The focus of our first bug day is bugs with status unconfirmed, emphasizing on bugs created pre-Thunderbird 2 release. But you may certainly work on any open bugs that interest you. The page Bug queries identifies several classes and categories of bugs, with some ratings of what areas are in most need of attention.

Schedule

Bug days are arranged into three sessions so as to be convenient for participants around the world. The three sessions target Asia/Australia, Europe/Africa, and North/South America. Of course, anyone may attend any or all sessions as they wish. Some assistance may hang around between or after sessions, so you may find someone in #bugday to help you outside of the scheduled times.

Timezone / Session E. Asia/Australia session Europe/Africa session Americas session
Los Angeles, USA (PDT=UTC-8 +1) Wed 21:00-23:00 Thu 04:00-06:00 *Thu 12:00-14:00
UTC Thu 06:00-08:00 Thu 13:00-15:00 Thu 19:00-21:00
UK (BST=UTC) Thu 06:00-08:00 Thu 13:00-15:00 Thu 19:00-21:00
Berlin, Germany (CEST=UTC+1) Thu 07:00-09:00 *Thu 14:00-16:00 Thu 20:00-22:00
Moscow, Russia (UTC+3) Thu 9:00-11:00 Thu 16:00-18:00 Thu 22:00-00:00
Beijing, China (UTC+8) *Thu 14:00-16:00 Thu 21:00-23:00 Fri 04:00-06:00

Simplified schedule:

Asia session - 14:00-16:00 UTC/GMT +8 hours (Beijing) (06:00-08:00 UTC)
Euro session - 14:00-16:00 UTC/GMT +1 hours (Berlin) (13:00-15:00 UTC)
Amer. session - 12:00-14:00 UTC/GMT -8 hours (Los Angeles) (19:00-21:00 UTC)

Please use The World Clock to determine when a session is happening in your time zone.

FAQ - How to I do this?

What you want to do is pretty simple:

  • Replicate the problem specified in the bug report and mark as "confirmed" if you are able to replicate and the steps to reproduce are documented and clear and the problem does not exist in trunk builds.
  • Clarify bug reports without distorting or changing the original problem.
  • Change the summary to be more accurate of the problem being reported, and if appropriate remove words so summary is less wordy
  • Close bug reports as WORKSFORME, INVALID, or INCOMPLETE when it's appropriate to do so.
  • Ask reporters to provide missing information that will help to replicate and ultimately fix the bugs they report.

Please check the following documentation for more about this process:

You will want to test with Nightly Trunk Builds. Ask for help if you do not know how to set it up. Or, if you are not permitted to use trunk, then use the latest update of Thunderbird version 2 - currently 2.0.0.12.

If you don't have the necessary rights to change to a bug see the Bug triage page about how to get privileges, then add a comment to the bug detailing what should be changed and why. You can also make this known in the #bugday channel and someone will assist you.