QA Database - Mission Statement

+ + + + + +
+The OOo QA Database Team has the main responsibility to assure and improve the quality of the OOo/SUN Staroffice database area. To this area mainly belongs: data sources & data bases, address book, dbase, ODBC, JDBC, ADO and also the form and control handling and the accessibility capability inside this areas. +The testing happens mainly by using the office, sporadic functional testing, testing with TCS (Test Case Specification) and with automatic tests mainly on Windows, Linux and Solaris. +
+ + + +

Revision: 2.00

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseMS.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseResp.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseResp.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseResp.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseResp.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,57 @@ + + + + + + + + Team Database: Quality Assurance - OpenOffice.org + + + +

Team Lead: Marc Neumann

+ +

QA Database - Responsibilities

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+	+
Marc Neumann +	Team Lead QA Database +
Christoph Lukasiak +	Team Member QA Database +
+	+

Revision: 2.00

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseResp.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseToDo.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseToDo.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseToDo.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseToDo.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,30 @@ + + + + + + + + Team Database: Quality Assurance - OpenOffice.org + + + +

Team Lead: Marc Neumann

+ +

QA Database - ToDo

+ + + + + +
+At the moment we have a lot of unconfirmed issues that have to be confirmed, so please support the team with this work.
+
+ + + +

Revision: 2.00

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/ooQAReloaded/ooQA-TeamDatabaseToDo.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/basic_rules.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/basic_rules.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/basic_rules.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/basic_rules.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,199 @@ + + + + + Basic IssueTracker rules + + +

Basic IssueTracker rules

Why you should read this

Imagine how many people later on will read your issue (means the +issue which you submitted, or which you participated in)

community members who are triaging defects
developers who are finally fixing the defect
sometimes developers who need to do preliminary work
QA engineer(s) who needs to verify the fix
everybody who has the same problem and tries to understand +whether

your defect also +describes his/her problem.
or whether your issue is one they like to vote for

possibly a user experience team member evaluating a feature +request
possibly a release team member evaluating whether the defect is +important enough to be included in some maintenance update such as +1.1.1.

+You see, there are a lot of people who may read what you wrote. +Thus, the majority of the rules below focuses on making reading easier: Though they +sometimes take you some little time to follow, they often save others a +lot of time later on. +

So please, not only when you submit new issues, but also when you +add comments to existing issues, try to help others by obeying these +simple rules.
+Since not obeying them makes defect handling more difficult (sometimes much more difficult), people may +tend to not deal with your issues until they are in a shape to +reasonably do so.

The rules

For those of you who like it short and simple:

One problem +- One issue
Provide a +meaningful summary
Provide +step-by-step descriptions
Provide sample +documents, if possible
Use +Attachments reasonably

One problem - One issue

When you report a problem, please submit one issue per problem. +There are various reasons for this, amongst them:

The more crowded an issue is, the more likely is it that some +problems may get lost over time.
Different problems are most likely to be handled by different +people (both in engineering, where the problem is fixed, and in QA, +where it's verified). The more problems you put into the issue, the +more difficult is this issue to handle for all involved parties.

+In particular, if you're going to write sentences like "Besides this, I +noticed that ...." or "There are several problems with....", then +please seriously ask yourself whether you should submit multiple issues +instead of a single one.
+If you don't follow this rule, be prepared for people asking you to +split up your issue. +

Provide a meaningful summary

A lot of people have to deal with a high number of issues on a +regular basis. Usually, this happens with generating reports about +issues, where the summary of all issues, plus some additional data, is +displayed. Thus, the summary of an issue is of very high importance: If +properly chosen, it allows to
+

easily recognize +an issue in a list of dozens of others
find an issue. +Since duplicate issues are draining a lot of work from engaged +community members, we always ask people to look whether the problem, +which they are going to submit as issue, is already known and reported. +Of course this works best if the summaries of the existing issues are +as descriptive as possible.
judge the importance +of an issue. "Spreadsheet problem" is less likely to be handled +appropriately than "Spreadsheet: Data loss when ...." or "Label X in +dialog Y has a wrong offset (2 pixels)"

+Thus, please avoid summaries like "Big Bug in OpenOffice.org" or +"Impress problem" - they are of no real help, and force people to waste +time to actually browse to the issue (instead of seeing it in a report) +to see what it is about.
+

Provide step-by-step descriptions

You, as the submitter of a problem, know exactly what you were +doing when you were hit by the problem. However, most other people +probably don't. For instance, they may have a completely different +workflow for doing the same things you are doing.

Even an phrasing as innocent as "format the text as bold" bears the +potential for a misunderstanding: You can get a bold text by assigning +a style to it, by selecting it and pressing the respective button in +the toolbox, by choosing "Style|Bold" +from the context menu, by choosing "Format|Character" from the menu +or "Character" from the +context menu and then doing the change in the dialog. Thus, a problem +description such as "When I try to format the text as bold +OpenOffice.org crashes" is of nearly no use, since it forces other people to ask back +what you meant.

This may be a trivial example, and you could argue that other +people can simply try, and then they will eventually encounter the +problem and thus know what you meant. But, there are reasons against +this:
+

Though the problem may seem simple to you, there may be deeper +reasons which prevent others from trying. For instance, it may crash +only if you customized the "Bold" +icon into a non-standard toolbox. In such a case, people will try for +no avail, without encountering your problem at all, and thus waste time.
+
Writing down exactly +what you did costs you some time once, +but every reader (there may +be numerous during the lifetime of an issue!) needs time for guessing +and trying. It's more efficient if you do it, and QA and engineering +can concentrate on fixing the problem, instead of triaging it.
There are a lot of scenarios where the set of possibility is +much larger. Formatting a text as bold may be simple and easy (though +you've already seen that there are at least 5 ways to do so), but other +tasks may require more steps which you +implicitly know, but your reader +doesn't.

+You may be tempted to consider it stupid to write a description like
+

open a new writer document
enter some arbitrary text
select the whole text via "Edit|Select +all"
from the context menu of the text, chose "Style|Bold"
=> OpenOffice.org crashes

+, and indeed there may be cases where this level of detail is +superfluous. But believe us, more often than not, it in the final +consequences saves more time than it takes. +

Please always be aware that often enough, the reader of your issue +description does not have the same background, with respect to the +particular task you're doing, that you yourself have.

Provide sample documents, if possible

If there is a problem with a particular document, then attach it. +This most often allows people to really easily reproduce your problem +by simply opening the attached document.
+

If the description how to reproduce a defect (see Provide step-by-step descriptions) exceeds +a certain limit, ask yourself whether you can submit the result of the description as sample +document, and attach it to the issue.
+

Oh, and one thing: If there is a problem on page 3 of your +1000-page diploma thesis, then please first try if the problem also +occurs if you strip all pages except the third one. If so, then please +simply attach the stripped version of the document, not all 1000 pages +....

Use attachments reasonably

Don't paste large files into the description. For instance, if +you're asked to provide a stack of a crash, copy this stack into a +file, then attach +this file. If you have some Basic macro or Java code which triggers a +problem, copy it into a separate file, and attach this file.

The reason here is simple: A 3-pager within the description of an +issue makes reading the issue really difficult. Everybody who wants to +get an impression of the issue needs to scan through a lot of +information which, though definitely important, is of only peripheral +interest for them at the moment.

+
+The author of the original document is Frank Schönheit. Constructive +feedback is welcome. You may +also consider visiting the +mailing list dedicated to discussing issue handling.
+
+

Last change: $Date: 2004/01/07 +12:54:47 $ / $Author: fs $
+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/basic_rules.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/bug_writing_guidelines.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/bug_writing_guidelines.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/bug_writing_guidelines.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/bug_writing_guidelines.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,206 @@ + + + + + Issue Writing Guidelines + + +

Issue Writing Guidelines

Last updated 2004-01-06
+
+ +

Consider the rules
+

We strongly encourage you to read the Basic + IssueTracker rules - for those who work with IssueTracker on a day-by-day + base, they have proven to + immensely + reduce their work. It's really easy for you to report issues in a way which + cost all others a lot of time, but if you invest a little more effort in the + beginning, you save others a lot thereof afterwards.
+

Thus, if you're new to OpenOffice.org's IssueTracker, please + read the rules. And, of course, please follow them :-), to make our all + work easier, so we can concentrate on improving the product, instead of wasting + time with bad issue reports.

And, please don't take be offended if we ask you to follow + some rules: Simply put, the more effectively you report an issue, the + more likely an engineer will actually fix it, and this is what we all are + interested in. +

How to Write a Useful Issue Report

+
Useful issue reports are ones that get issues fixed. A useful issue report + normally has two qualities:
+

+ Reproducible. If an engineer can't see it or conclusively prove that it + exists, the engineer will probably stamp it "WORKSFORME" or "INVALID", and move + on to the next issue. Every detail you can provide helps. +

+ Specific. The quicker the engineer can isolate the issue to a specific + problem, the more likely it'll be expediently fixed. (If a programmer or tester + has to decipher an issue, they spend more time cursing the submitter than + fixing or testing the problem.) +

Let's say the application you're testing is a spreadsheet + application. You crash at when you open the file foo.sxc, and want to write up + an issue report:

Bad: "My spreadsheet crashed + when I tried to open a document. I think it contained a chart. My computer uses + Windows. I think that this is a really bad problem and you should fix it now. + By the way, your icons really suck. Nobody will use your software if you keep + those ugly icons. Oh, and my grandmother's has a problem with the word + processor. Nothing works right, either. Good luck." +
+
+ Good: "I crashed each time when I opened the attached spreadsheet + document using the 10.13.00 build on a Win NT 4.0 (Service Pack 5) system. I + also rebooted into Linux (RedHat 6.2), and reproduced this problem using the + 10.13.00 Linux build. +
When I removed the chart from the document I was able to load it without any + trouble." +
+

How to enter a useful Issue Report into IssueTracker

In order to file an Issue, you must be a registered user of + OpenOffice.org. Registering is easy: simply click on the "Join" link in the + left navbar and follow the instructions. It takes all of a few minutes. If you + are a registered user, click on the "My Issues" link in the left navbar or on + the "Bugs and Issues" link on + the navbar. The latter is a more comprehensive page which provides a + explanation of IssueTracker and also has some useful IssueTracker links, such as a + query link. +
+ Go to the IssueTracker + Query Page to determine whether the defect you've discovered is a known + issue and has already been reported. (If your issue is the 37th duplicate of a + known issue, you're more likely to annoy the engineer. Annoyed engineers fix + fewer issues.) +
+
Next, be sure that you've reproduced your issue using a recent build. + (Engineers tend to be most interested in problems afflicting the code base that + they're actively working on, rather than those in a code base that's hundreds + of issue fixes obsolete.)
+
+ If you've discovered a new issue using a current build, report it in + IssueTracker: +
+
+
+ If you're not already logged in, please enter your username & password in + the appropriate filds at the top of this page (or any other page on this site)
+
+ From your IssueTracker main page, choose "Enter a new issue".
+
+ Select the product that you've found an issue in.
+
+
regarding 2., there is a link "File Issue" as well, accessible from the "My + Pages"-tab (When logging in you're automatically directed to "My Pages", you + can then access issueTracker using the links in the "My Tools" box on the left + side of your screen)
+

Now, fill out the form. Here's what it all means:

Where did you find the issue?

Product: + In which product did you find the issue?
+ You just filled this out on the last page.

Version: + In which product version did you find the issue?
+ If applicable.

Component: In which component does + the issue exist?
+ IssueTracker requires that you select a component to enter an issue. (If they all + look meaningless, click on the Component link, which links to descriptions of + each component, to help you make the best choice.)

+ Platform: On which hardware platform did you find this issue? (e.g., + Sun, PC)
+ If you know the issue happens on all hardware platforms, choose 'All'. + Otherwise, select the platform that you found the issue on, or "Other" if your + platform isn't listed.

OS: On which Operating System + (OS) did you find this issue? (e.g. Linux, Windows NT)
+ If you know the issue happens on all OSs, choose 'All'. Otherwise, select the + OS that you found the issue on, or "Other" if your OS isn't listed.

+
+ How important is the issue?

+ Issue Type: Is this a defect, enhancement, feature-request, task or + patch?
+ This item defaults to 'defect'. (To determine the most appropriate type of + issue, click on the Issue Type link for a full explanation of each choice.)

+ Priority: How urgent is a fix required?
+ This item defaults to '3'. 1 is the highest, 5 the lowest priority.

+
+ Who will be following up on the issue?

+ Assigned To: Which engineer should be responsible for fixing this issue?
+ IssueTracker will automatically assign the issue to a default engineer upon + submitting an issue report; the text box exists to allow you to manually assign + it to a different engineer. (To see the list of default engineers for each + component, click on the Component link.)

Cc: Who + else should receive e-mail updates on changes to this issue?
+ List the full e-mail addresses of other individuals who should receive an + e-mail update upon every change to the issue report. You can enter as many + e-mail addresses as you'd like; e-mail addresses must be separated by commas, + with no spaces between the addresses.

+
+ What else can you tell the engineer about the issue?

+ URL: On what URL did you discover this issue?
+ If you encountered the issue on a particular URL, please provide it (or, them) + here.

Summary: How would you describe the + issue, in approximately 60 or fewer characters?
+ A good summary should quickly and uniquely identify an issue report. + Otherwise, developers cannot meaningfully query by issue summary, and will + often fail to pay attention to your issue report when reviewing a 10 page issue + list.
+
+ A summary of "Abort trying to install on RedHat 7.0, Kernel 2.2.14" is a useful + title. "Software fails" or "install problem" would be examples of a bad title.

+
+ Description: What else can you tell the engineer about this issue?
+ Please provide as detailed of a problem diagnosis in this field as possible. A + precise step-by-step description is the best way to do it.
+ For crashing issues it might help to have additional information in case you're + able to provide that:

+ Target + Milestone: Think of it as a deadline; targets are "not determined" + or "next build"--for most issues, stipulate "not determined." +
+
+
Attachments. It may be the case you need to add an + attachment(s) to an Issue, either the one you file or another one. You can do + it; the limit is 10MB, but please keep any attachment small, as most people use + 56K connections. Attaching a file to an issue is a two-step procedure and is + not obvious. You must first submit the issue or locate the issue to which you + wish to attach the file. Then, you can add the file as an attachment to that + issue. There will be a link in the issue body that reads: +
+
Create a new attachment (proposed patch, testcase, etc.)
+
+ Note: You cannot add OpenOffice.org files natively. They must + be added as "binary" files. This is a temporary problem. +
+
+ Hints: Reduce the size of your file as much as possible. And, if you are + uploading an HTML document, be sure to compress it first (Zip or tar it), + otherwise it gets corrupted when others try to download it. +
+
You're done! After double-checking your entries for any possible errors, press + the "Commit" button, and your issue report will now be in the IssueTracker + database.
+
+
+
(These Bug Writing Guidelines were originally written for Mozilla by + Eli Goldberg. Thanks to Claudius Gayle, Peter Mock, Chris Pratt, + Louis Suarez-Potts, Tom Schutter, and Chris Yeh for contributing to this + document. Constructive suggestions + and feedback are welcome.) +
+

+ + Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/bug_writing_guidelines.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/pre_submission.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/pre_submission.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/pre_submission.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/pre_submission.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,61 @@ + + + + + Submit an Issue + + + +

Submit an issue

Thank you for taking the time to submit an issue! We really appreciate your help in constantly improving +OpenOffice.org!
+Before you proceed, +please consider the following

+ +

Did you check if your problem is already +reported?

Unfortunately, too many issues get reported twice (or much more often). +You, as the submitter who exactly knows the problem, often are much +faster in finding the duplicates than other people. So please take some +minutes to see if +your problem is already reported. If so, you can add yourself to +the cc-list of the issue, to be notified whenever something in this +issue changes (e.g. when it's fixed).

+ +

Please follow the rules

If this is the first issue you submit, please take a moment to read the +the basic rules. They take you very +little time to follow, but potentially, they save a lot of other people +a lot of time. Short and simple, these are:
+

+ +

Please log in

For submitting an issue, you need to log in. If you do +not yet have an OpenOffice.org account, please join us. This is +necessary, as issues are bound to their submitter, which, for example, enables other people who work on the reported +problem to ask you back in case of uncertainties.

+ +

Go on - submit the issue +
+

+ + \ No newline at end of file Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/pre_submission.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/project_issues.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/project_issues.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/project_issues.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/project_issues.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,241 @@ + + + + + Bugs&Issues Explained + + + +

About Issues

+ Finding and Filing Issues
+ About Issue Tracker +
+ Why Use Issue Tracker? +
+ OpenOffice.org Issues +
+ OpenOffice.org Infrastructure Problems +

Finding and Filing Issues

+ Search for your bug/issue. +
Quick search
+ Enter one or more of the main words having to do with your issue. For example: + 'LDAP', 'crash justify' or 'copy paste Writer' +
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
Summary contains:
Description contains: +
+ include closed issues +
+
+ +
Advanced search
+ If the quick search does not yield results, try the + advanced search. +
+
Direct jump
+ If you know the issue number you are looking for, you can jump to it directly +
+
+ +
+
+
+
+ Enter a new issue +
If your issue has not been reported (see above), then you need to + submit a new issue. Read the guidelines + for reporting issues page to learn how to report an issue/bug. See also + A Quick Introduction to IssueTracker.
+
Attachments.
+ You can add attachments to issues. The + limit is 10MB, but please keep any attachment small, as most people use 56K + connections. Attaching a file to an issue is a two-step procedure and is not + obvious. You must first submit the issue or locate the issue to which you wish + to attach the file. Then, you can add the file as an attachment to that issue. + There will be a link in the issue body that reads: +
+
Create a new attachment (proposed patch, test case, etc.)
+
+
+

About Issue Tracker (Formerly IssueZilla)

OpenOffice.org uses a modified version of mozilla.org's + BugZilla to track issues. Issue + Tracker is integrated into CollabNet's + SourceCast, upon which the OpenOffice.org website runs. This document was + written for IssueZilla, Issue Tracker's predecessor. It is still relevant. + However, an excellent account of the current Issue Tracker can be found in the + Help. +

If you are a registered user of OpenOffice.org, you can use Issue Tracker to + browse existing issues, enter new issues, or modify the details of an existing + issues. Please be aware that you'll need to enable cookies in your browser to + use IssueZilla. +

Why Use Issue Tracker?

+ Why use Issue Tracker and not a mail list? Because it allows everyone to keep + track of the many big and small tasks, requests, enhancements, whatever that + circulate throughout an Open Source project. What is more, the issue tracker + makes it easier to determine if any another user has had similar problems. And + if the problem has been resolved, it can alert the relevant people to the + solutions found. In short, by registering and then filing issues with Issue + Tracker, you become a contributing member of OpenOffice.org.

Note: You can delete your SourceCast account and thereby + disable your Issue Tracker account at any time. However, if you then decide to + re-register using the same account information, you will not be able to file + issues. This is because Issue Tracker accounts are never full deleted, only + disabled. You thus have to initiate a new account.

+ Issue Notifications

Issue Tracker will notify you via email about changes made to issues you + reported. Please do not reply to these messages but login the website and add + your comments to the issue. If you don't want to receive these notification + emails you may want to edit your Issue Tracker preferences and change the email + settings. +

OpenOffice.org Issues

You can report and query issues in the OpenOffice.org + code/documentation/ui/definition. Issue Tracker currently reports and tracks + the following issue-types: DEFECT, ENHANCEMENT, FEATURE, TASK and PATCH (we + can, of course, add new issue types as necessary). For example, you could + report a bug as DEFECT; Track ENHANCEMENT requests to existing features; + discuss adding new FEATURES; track a TASK for others to do (delegating or + requesting help). Furthermore Issue Tracker is also used to track PATCH + submissions.

+ OpenOffice.org Infrastructure Problems

If you find an issue with some part of the OpenOffice.org infrastructure (not + the application), such as a problem with the site search engine, or a problem + with CVS, please use the following table to guide you in reporting the problem: +

+
+ + + + + + + + + +

Issue Links

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Concurrent Version Control (CVS)	Query + Reports	Enter + Report
Issue Tracking (Issue Tracker)	Query + Reports	Enter + Report
Web-based Source and Revision Browsing (CVSWeb)	Query + Reports	Enter + Report
Site-wide Search (Swish-E)	Query + Reports	Enter + Report
Site, User and Project Administration (SourceCast)	Query + Reports	Enter + Report
Mailing Lists (ezmlm)	Query + Reports	Enter + Report
+ Downloads	Query + Reports	Enter + Report
Website Documentation and Instructions (HTML)	Query + Reports +	Enter + Report
General Website Issues ( Look, Links, + Workings)	Query + Reports	+

+ $Revision: 1.9 $ $Date: 2007/02/23 10:42:35 $ + + Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/project_issues.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/quickstart.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/quickstart.html?rev=1202908&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/quickstart.html (added) +++ incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/quickstart.html Wed Nov 16 22:14:47 2011 @@ -0,0 +1,254 @@ + + + +OpenOffice.org QA Project - Quick Start + + + + + + + +

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 #qa.openoffice.org at irc.freenode.net ) 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. + +

+ +

Do you have any training issues I can look at?

You can always look at issues that other team members have worked on. Try taking a look at the Fixed issues links on this page: +

http://qa.openoffice.org/izhelperlinks/members.html +

Here are some training issues we have created to help you along: +

http://www.openoffice.org/issues/show_bug.cgi?id=20979 +

http://www.openoffice.org/issues/show_bug.cgi?id=20981 +

http://www.openoffice.org/issues/show_bug.cgi?id=20982 +

+ + + + + + + Propchange: incubator/ooo/ooo-site/trunk/content/qa/wwwstaging/tasks/quickstart.html ------------------------------------------------------------------------------ svn:eol-style = native

Summary contains:
Description contains:		+
+	include closed issues	+

QA Database - Mission Statement

QA Database - Responsibilities

QA Database - ToDo

Basic IssueTracker rules

Why you should read this

The rules

One problem - One issue

Provide a meaningful summary

Provide step-by-step descriptions

Provide sample documents, if possible

Use attachments reasonably

Issue Writing Guidelines

Consider the rules +

How to Write a Useful Issue Report

How to enter a useful Issue Report into IssueTracker

Now, fill out the form. Here's what it all means:

Submit an issue

Did you check if your problem is already +reported?

Please follow the rules

Please log in

About Issues

Contents

Finding and Filing Issues

About Issue Tracker (Formerly IssueZilla)

Why Use Issue Tracker?

+ Issue Notifications

OpenOffice.org Issues

+ OpenOffice.org Infrastructure Problems

A Quick Start Guide to contributing to this project

Bustin' Bugs

Where do I get a list of issues to review?

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

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".

What makes a good or bad bug report?

Do you have any training issues I can look at?

General Info

Things to do

Join this project

Documentation

IZ helper links

Tools

Localization QA

Members

Statistics

About Us

Accessibility

Consider the rules
+