QA/Community/Bug Day

From MozillaWiki
< QA‎ | Community
Revision as of 20:00, 3 April 2007 by Aleksej (talk | contribs) (→‎Schedule: made the colors lighter and removed the old table)
Jump to navigation Jump to search

« back to Mozilla_QA_Community

Welcome to the Mozilla QA Community Bug Day wiki!!

Note - New bugday times throughout the world. See the new schedule below. After discussion with several community members, we decided to move bugday times a bit earlier for each region. This change is an attempt to increase bugday participation by having regional session in the afternoon when people are at work or on university campus rather than in the evening when most people aren't willing or able to volunteer their time.

Join us on IRC in #bugday every Tuesday for your regional time to discuss and work on Bugzilla bug topics and get help from the Mozilla QA team.

Bug Days are an excellent way to contribute to Mozilla's 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. We gather together at predetermined times to focus on particular areas in Bugzilla. The exact area or topic for Bug Day may vary week to week. But the general idea is to work through some sort of bug list as a team.

Topic of the Day

Tbird 2.0 unconfirmed triage

With the pending release of Thunderbird 2.0 we'd like to make a pass over the unconfirmed bugs to be certain nothing creeps into the release undetected.

Let's triage this bug list. http://tinyurl.com/25yfo5

please use these builds or even nightlies to test with.

Schedule

Bug days are arranged into three sessions so as to be convenient for participants around the world. The three sessions target "prime time" for those in Asia/Australia, Europe/Africa, and North/South America, but anyone may attend the sessions as they wish.

note: After considering input from a few regular Bugday participants, we will try another time of day for each session. Instead of in the evening, we'll try afternoons. This change will occur for the Bugday sessions on April 3rd.

I've replaced the table, but it still needs some polishing and adding to (particulary, the colors may have to go) -- Aleksej

A bit simpler 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 +2 hours (Berlin) (12:00-14:00 UTC)
Amer. session - 12:00-14:00 UTC/GMT -7 hours (Los Angeles) (19:00-21:00 UTC)

Please use that and the tools at The World Clock to help determine when a session is happening for you.

Timezone / Session E. Asia/Australia session Europe/Africa session Americas session
Los Angeles, USA (PST=UTC-8+DST) Mon 23:00-01:00 Tue 05:00-07:00 *Tue 12:00-14:00
UTC Tue 06:00-08:00 Tue 12:00-14:00 Tue 19:00-21:00
UK (BST=UTC+DST) Tue 07:00-09:00 Tue 13:00-15:00 Tue 20:00-22:00
Berlin, Germany (CEST=UTC+1+DST) Tue 08:00-10:00 *Tue 14:00-16:00 Tue 21:00-23:00
Moscow, Russia (UTC+3+DST) Tue 10:00-12:00 Tue 16:00-18:00 Tue 23:00-01:00
Beiging, China (UTC+8, DST n/a) *Tue 14:00-16:00 Tue 20:00-22:00 Wed 03:00-05:00


Some of us hang around between or after sessions, so you may find someone in #bugday outside of this time, and if not, you can always find people in #qa.

Community Representatives

Bug days are led by Mozilla's QA staff and by experienced volunteers from our community.

  • Asia - Tracy (future - Emily?)
  • Euro - Tomcat
  • Americas - Tracy (future - Triona?)

Staying Connected

  • Click here to join the mailing list.
  • Hang out in #qa when we're not scheduled in #bugday or #testday
  • Keep an eye on this page. Weekly updates will be posted by Thursday afternoon (California time)
  • Read the Mozilla QA blog

FAQ

Where do I start? While the topic of day may have a particular focus for the session, we usually want to try to do the following:

  • Replicate the problems specified in bug reports and mark them as "confirmed" whenever we are able to do so.
  • Clarify bug reports whenever we can do so without distorting the problems.
  • Close bug reports as WORKSFORME or INVALID when it's appropriate to do so.
  • Ask reporters to provide missing information that would help to replicate and ultimately fix the bugs they report.

Note: If you don't have the necessary rights to make a change to a bug, add a comment to the bug detailing what should be changed and why. You can also make this known in the #bugday channel, and one of the moderators or an experienced volunteer will assist you.

What build should I be testing with?

Bug Day History

Bug Day Planning For contributors planning and hosting Bug Days please see the Bug Day Plannner