Monday January 31st, 2000
Another BugDay is upon us tomorrow. With the slew of M13 bugs, the Browser-General component is once again in need of volunteers to pre-screen the 120+ bugs, and weed out the deadwood and assign the valid bugs to a more suitable engineer/component. It's really easy --- here's how to prescreen them. Then, if you can, reassign them to the correct component/engineer/QA engineer. It's a great way to get acquainted and involved with Bugzilla and Mozilla QA! Between 3pm and 4pm PST (PST is GMT-0800) tomorrow there should also be QA people on hand in #mozillazine to help out with the effort.
However, BugDay isn't all about bug pre-screening. The #mozillazine channel is also there if you have any questions about running Mozilla or aiding the project. You can also just come and hang out with the gang.
So, stop on by using your favorite chat client (point it at irc.mozilla.org, channel #mozillazine), our java chat client, or ChatZilla (see this news item for more on how to try out ChatZilla).
#1 BugDay! What Is It?
Tuesday February 1st, 2000 7:33 AM
BugDay is a collaborative effort to find and report new bugs in Mozilla. We meet every Tuesday afternoon and work into the night (USA time). BugDay is a great oportunity to get help reporting that first bug, to learn to use Bugzilla (mozilla.org's bug reporting and searching tool), to get verification across platforms for newly discovered bugs (we ususally have the major platforms represented), and to help out the Quality Assurance team in pre-screening newly reported bugs and verifying resolved bugs. BugDay is the perfect place to get started helping out and a great way to make mozilla better faster. Hope to see you all there.
(posted with mozilla)
#2 First Bugday experience
Tuesday February 1st, 2000 9:47 PM
I'm not a programmer. But I've been testing out the latest Mozilla builds for a while now, so I thought I would stop by Bug Day to see what it was all about. Asa got me started right away on prescreening the New bugs. I mainly looked at linux bugs, since that's what I've been using Mozilla on. In a couple of hours I had marked 2 Linux bugs as duplicates, and one as possible invalid. I came to realize what a huge challenge it is for the developers to wade through all these bug reports, so many of which are rather poorly written, duplicates, or not even real bugs. Also I realized that you don't have to be a programmer to help Mozilla succeed. I gave a few hours of my time, using what I knew about an operating system and the Mozilla browser. That is a few less hours that developers have to spend on the bug reports. That time can be used by someone with more knowlege than me to make Mozilla work better.