A Quick Start Guide to contributing to this project

I've subscribed to the mailing list, joined the QA team and received privileges to modify all aspects of an IZ issue... what's next?

Great question! In the QA project, there is always something for anyone to do. The options and variety can be overwhelming, but hopefully this document can help guide you to the important tasks that make this project work and OpenOffice better!

The primary focus of the QA project is to review as many bug reports that we can so that we can improve OpenOffice software one bug and fix at a time. We'll come back to this in a bit.

That said, there are also other roles to be filled. Documentation, web site maintainence and FAQ's are examples of other roles that require different skills and interests. Check out the items under the tasks header on the right hand menu to find other tasks that the QA project needs help on.

Bustin' Bugs

Our goal is simple: we find bugs and/or review bugs users report and we make sure the bugs get the proper attention from the right people. We use IZ to help us find, track and work on bugs.

The rule of thumb is to:

Try to keep the number of issues in the current month that have not been looked at by a QA team member as low as possible.

Where do I get a list of issues to review?

When you are more familiar with OOo you probably will end up creating your own searches and saving them either as bookmarks or custom searches.

However, learning IZ takes a bit of time and persistence, so we've created some links to issues that have not been looked at by any QA team member. The menubar on the right side of this page has a section called "IZ Helper Links". In this section, there is a link called "This month's issues that need you!":

http://qa.openoffice.org/izhelperlinks/thismonth.html

If you follow this link, you will see a list of links to issues that have not been reviewed by a QA team member.

Hmmm, I have a list of issues, what next?

This part gets a bit involved, but this document hopes to solve your initial concerns.

The basic steps require you to log into the OpenOffice.org web site, then retrieve an issue of choice and then verify to make sure the bug is either reproducible or is a duplicate of an issue that has been already reported. Occassionally, we also change a bug report to an enhancement or feature request if it turns out OpenOffice is working fine, but the user wanted OpenOffice to do a task or function that it currently does not support.

In summary, this is what we do:

1. Log into OpenOffice.org
2. Get a list of untouched issues.
3. Load any issue of your choice.
4. Check the fields.
5. Make sure the issue is reproducible.
6. Add your comments if necessary.
7. Confirm the issue as "NEW".

Let's break down this process into basic steps and walk our way through an issue:

1. Log into OpenOffice.org

You can either use the "Login" link of the left hand menu, or go directly to this link:

http://www.openoffice.org/servlets/TLogin

2. Get a list of untouched issues.

The simplest way is to use the list from this link:

http://qa.openoffice.org/izhelperlinks/thismonth.html

With time and more practice you probably will end up creating your own custom lists using IZ's searching tool.

3. Load any issue of your choice.

After retrieving the list of issues in step 2, click on the number in left hand column called ID. This number is the issue number.

4. Check the fields.

Certain fields need to be set correctly so that the developers and the QA team can sort through and process the issue properly.

First of all, make sure the component field is set correctly.

Component
The component field should usually be set to:

Word Processor - Writer/Word Processor bugs
Spreadsheet - Calc/Spreadsheet bugs
Presentation - Impress/Presentation bugs
Drawing - Draw/Drawing tool bugs
Installation - Problems with installation or uninstall

Next, make sure the priority field is set correctly.

Priority
Priorities range from P1 ( very urgent ) to P5 ( will be considered when there is time ). Here is a general rule of thumb for priorities:

P1 - OpenOffice cannot be used for testing or development.

P2 - OpenOffice crashes or basic features do not work.

P3 - OpenOffice bugs that usually involve a feature not working as expected.

P4 - OpenOffice bugs that do not affect basic features and usually have workarounds.

P5 - OpenOffice very minor bugs that are annoying.

You can read more details on priorities here:

http://www.openoffice.org/issues/bug_status.html#priority

The QA contact field is used by developers to monitor bugs. The email address is usually a mailing list, not an individual. We need to make sure it's set correctly.

QA Contact

Writer/Word Processor
issues@sw.openoffice.org

Calc/Spreadsheet
issues@sc.openoffice.org

Impress/Presentation
issues@graphics.openoffice.org

Draw
issues@graphics.openoffice.org

Installation
issues@installation.openoffice.org

The keyword field is used to help further sort and identify special bugs. You can specify more than one keyword in this field. Just use commas to separate multiple keywords.

Keyword

oooqa
When you do anything to an issue, please add the oooqa keyword to the keyword field.

ms_interoperability
Bugs that involve compatibility with OpenOffice and MS Office

crash
Bugs where OpenOffice crashes

valgrind
Bugs found using the Valgrind memory tool

Finally make sure there is a valid attachment if the issue requires one.

Attachment
Request an attachment if it simplifies reproducing the bug or is required to demonstrate the bug.

For example, problems with importing MS Word documents should usually have an attachment.

Complex document layouts are best demonstrated with an attachement.

5. Make sure the issue is reproducible.

In any bug report, it is crucial that in the comments include:

A clear list of steps to reproduce the bug on any system

The following list of details also is useful:

Stack dumps from OpenOffice.

How often does the problem occur?

Actual Results experienced by the user.
Sometimes screenshots or a small sample document that demonstrates the problem is the better than a written description.

Expected Results experienced by the user.
We need to know what the user is expecting OpenOffice to do. The problem might not be a bug, just a feature that OpenOffice does not support.

Description of the problem.

Operating system version, driver version, library version, etc.
This type of detailed information is useful with installation or display problems )

6. Add your comments if necessary.

You can add your comments in the "Additional Comments" text area:

7. Confirm the issue as "NEW".

To confirm an issue and mark it as "NEW" click on the "Confirm issue (change status to NEW)" option and then the "Commit" button.

What makes a good or bad bug report?

It can be daunting at first when trying to figure out what is a good bug report and what is a bad bug report. The mailing list and IRC ( channel #openoffice at irc.libera.chat ) is a good place to get help from other members of the team.

The key rule to remember is:

A clear list of steps to reproduce the bug on any system.

Without a clear list of steps, it is most likely impossible to reproduce the bug that the user is experiencing. Subtle things such as the menus the user used, which mouse button was clicked or the exactly keyboard sequence that was typed make a huge difference when trying to reproduce the bug.