This is an automated email from the ASF dual-hosted git repository.
wave pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/openoffice-org.git
The following commit(s) were added to refs/heads/main by this push:
new a634fc5 Migration of bugs html content
a634fc5 is described below
commit a634fc5a813c8e4f8ed5c6223c78f8e8ff55554e
Author: Dave Fisher <d...@davefisher.tech>
AuthorDate: Sun Nov 1 13:01:50 2020 -0800
Migration of bugs html content
---
content/bugs/bug_writing_guidelines.html | 117 ++++++++++++
content/bugs/issues.html | 306 +++++++++++++++++++++++++++++++
2 files changed, 423 insertions(+)
diff --git a/content/bugs/bug_writing_guidelines.html
b/content/bugs/bug_writing_guidelines.html
new file mode 100644
index 0000000..3bc6328
--- /dev/null
+++ b/content/bugs/bug_writing_guidelines.html
@@ -0,0 +1,117 @@
+<!DOCTYPE html>
+<html><head>
+<title>Issue Writing Guidelines</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>Issue Writing Guidelines<br>
+</h2>
+
+<h4>Why you should read this</h4>
+
+
+<p> Simply put, the more effectively you report an issue, the more likely an
engineer will actually fix it. These issue writing guidelines are an attempt at
a general tutorial on writing effective issue reports for novice issue writers;
not every sentence may precisely apply to your software project.
+
+<br>
+<br>
+<h4>How to Write a Useful Issue Report</h4>
+
+<blockquote>
+<p>Useful issue reports are ones that get issues fixed. A useful issue report
normally has two qualities:</p></blockquote>
+
+<ol> <li><b>Reproducible.</b> 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.
</li><br><br>
+
+<li> <b>Specific.</b> The quicker the engineer can isolate the issue to a
specific problem, the more likely it'll be expediently fixed. <b></b>(If a
programmer or tester has to decipher an issue, they spend more time cursing the
submitter than fixing or testing the problem.) </li> </ol>
+
+<blockquote> Let's say the application you're testing is a web browser. You
crash at foo.com, and want to write up an issue report: </blockquote>
+
+<blockquote> <b>Bad:</b> "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."
+<br>
+ <br>
+ <b>Good:</b> "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.
+<p>When I removed the chart from the document I was able to load it without
any trouble." </blockquote>
+<br>
+<h4>How to enter a useful Issue Report into IssueZilla</h4>
+<blockquote> 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 <a href="//project_issues.html" target="_blank">"Bugs and Issues"</a> link
on the navbar. The latter is a more comprehensive page which provides a
explanation of IssueZilla and also [...]
+<p> Go to the <a href="//issues/query.cgi" target="_blank">IssueZilla Query
Page</a> 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.)
+
+<p>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.)<br> <br> If you've discovered a new issue using a
current build, report it in IssueZilla: </blockquote>
+
+<ol> <li> <p>From your IssueZilla main page, choose "Enter a new issue".</p>
</li>
+
+<li> <p>Select the product that you've found an issue in.</p> </li>
+
+<li> <p>Enter your E-mail address, Password, and press the "Login" button. (If
you don't yet have a password, leave the password text box empty, and press the
"E-mail me a password" button instead. You'll receive an E-mail message with
your password shortly.)</p> </li> </ol>
+
+<h4>Now, fill out the form. Here's what it all means:</h4>
+
+<blockquote > <i>Where did you find the issue? </i></blockquote>
+
+<blockquote> <b>Product: In which product did you find the issue?</b><br> You
just filled this out on the last page. </blockquote>
+
+<blockquote> <b>Version: In which product version did you first find the
issue?</b><br>
+ If applicable. </blockquote>
+
+<blockquote> <b>Component: In which component does the issue exist?</b><br>
IssueZilla 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.) </blockquote>
+
+<blockquote> <b>Platform: On which hardware platform did you find this
issue? </b>(e.g., Sun, PC)</><br> 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. </blockquote>
+
+<blockquote> <b>OS: On which Operating System (OS) did you find this
issue?</b> (e.g. Linux, Windows NT)</><br> 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. </blockquote>
+
+<blockquote > <br> <i>How important is the issue? </i></blockquote>
+
+<blockquote> <b>Issue Type: Is this a defect, enhancement, feature-request,
task or patch?</b><br> 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.) </blockquote>
+
+<blockquote> <b>Resolution Priority: How urgent is a fix required?<br>
</b>This item defaults to '3'. 1 is the highest, 5 the lowest
priority.</blockquote>
+
+<blockquote > <br><i> Who will be following up on the issue?</i> </blockquote>
+
+<blockquote> <b>Assigned To: Which engineer should be responsible for fixing
this issue?</b><br> IssueZilla 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.) </blockquote>
+
+<blockquote> <b>Cc: Who else should receive e-mail updates on changes to this
issue?</b><br> 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. </blockquote>
+
+<blockquote> <br> <i>What else can you tell the engineer about the issue?
</i></blockquote>
+
+<blockquote> <b>URL: On what URL did you discover this issue?</b><br> If you
encountered the issue on a particular URL, please provide it (or, them) here.
</blockquote>
+
+<blockquote> <b>Summary:</b> <b>How would you describe the issue, in
approximately 60 or fewer characters?</b><br> A good summary should <u>quickly
and uniquely identify an issue report</u>. 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.<br> <br> 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 [...]
+
+<blockquote> <br> <b>Description: What else can you tell the engineer about
this issue?</b><br> 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.<br>For crashing issues it might help to have additional information in case
you're able to provide that:</blockquote>
+
+<blockquote><br><b>Target Milestone.</b> Think of it as a deadline; targets
are "not determined" or "next build"--for most issues, stipulate "not
determined."
+
+
+<ul> <li> <blockquote > <b>Win32:</b> if you receive a Dr. Watson error,
please note the type of the crash, and the module that the application crashed
in. </blockquote> </li>
+
+<li> <blockquote> <b>Unix:</b> please provide a minimized stack trace.
</blockquote> </li> </ul>
+
+<p><strong>Attachments.</strong><em> </em>
+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 there are still some using
+ 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:
+<blockquote> Create a new attachment (proposed patch, testcase,
etc.)</blockquote>
+<p> <strong>Hints</strong>: 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
+ may get corrupted when others try to download it.
+ <p><strong>MIME types</strong>: Select the correct mime type for you
attachment from the MIME type
+ pulldown panel For OpenOffice.org 2.x documents, choose the corresponding
+ "application/vnd.oasis.opendocument."
+ <p>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 IssueZilla database.<br>
+<hr>
+<p>(These Bug Writing Guidelines were originally written for Mozilla by <a
href= "mailto:e...@prometheus-music.com";><b>Eli Goldberg</b></a>. Thanks to
Claudius Gayle, Peter Mock, Chris Pratt, Louis Suarez-Potts, Tom Schutter,
Rainer Bielefeld, and Chris Yeh for contributing to this document. Constructive
<a href="mailto:michael.bem...@germany.sun.com"; >suggestions and feedback</a>
are welcome.)
+</blockquote></body>
+</html>
+
diff --git a/content/bugs/issues.html b/content/bugs/issues.html
new file mode 100644
index 0000000..e0ec5d4
--- /dev/null
+++ b/content/bugs/issues.html
@@ -0,0 +1,306 @@
+<!DOCTYPE html>
+<html><head>
+<title>Got Issues? (Last updated 2002-06-03)</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+
+ <h2>Got Issues?</h2>
+
+
+<p><i>Last updated 2002-06-03</i></p>
+<br>
+
+
+<h4>Why "Issues" And Not "Bugs"?</h4>
+
+ <p>Not all 'issues' are DEFECTS, which are more commonly known as
+ "bugs." Some issues will be <i>FEATURE Requests</i> or
+ <i>ENHANCEMENT Requests</i>, <i>PATCH submissions</i>, or even
+ <i>TASKS</i>. For this reason, we feel the term "issue" is a
+ more appropriate one than "bug". People often say 'bug' when
+ they should really be referring to an issue. Enter the tasks you're
+ planning to work on as enhancement requests and will help you track
+ them and allow others to see what you plan to work on. If people can
+ see your flight plan, they can avoid duplicating your work and can
+ possibly help out or offer feedback
+ </p>
+<br>
+ <h4>What Is IssueZilla?</h4>
+
+ <p>IssueZilla, a proprietary tool, is based on Mozilla's open-source <a
+ href="http://www.mozilla.org/bugs/";>Bugzilla</a>, but has been
+ generalized by <a href="http://www.collab.net";>CollabNet</a> to handle all
kinds of issues, not just code-based
+ issues. On OpenOffice.org, the supported issue-types now include:
+ DEFECT, ENHANCEMENT, FEATURE, TASK and PATCH. We can add issue types in
+ the future as necessary, and these can be reported against specific
+ components of a project, for example 'documentation', 'code', 'ui',
+ 'definition'. OpenOffice.org's projects are 'api', 'chart', 'database
+ access', 'drawing', 'formula editor', 'presentation', 'spreadsheet',
+ 'word processor' and 'xml' to name just a few. Take a look at the
+ projects/products list to see all of them.
+ </p>
+
+ <p>Reported issues will be assigned to an appropriate issue owner.</p>
+<br>
+ <h4>What do you have an issue with?</h4>
+
+ <p>Do you want to report an issue with a milestone build or with a copy
+ of OpenOffice.org that you compiled yourself? IssueZilla is the place
+ to submit issue reports for software distributed by
+ OpenOffice.org. This page gives an overview of how IssueZilla works.
+ Read the <a
+ href="//bugs/bug_writing_guidelines.html">issue
+ writing guidelines</a> as well, for tips on how to write useful issue
+ reports.
+ </p>
+<br>
+ <h4>Anatomy Of An Issue</h4>
+
+ <p>Issues are composed of many fields. Some of them are described here.
+ </p>
+
+ <blockquote>
+ <dl>
+ <dt><b>Project</b></dt>
+
+ <dd>
+ OpenOffice.org is composed of different projects. Carefully
+ read the <a
+ href="/projects/">project
+ descriptions</a> if you're unsure of which project to attribute
+ your issue to (visit the projects themselves for fuller descriptions).
The project you choose determines which person
+ IssueZilla assigns the issue to.
+ </dd>
+
+ <dt><b>Status Whiteboard</b></dt>
+
+ <dd>
+ The Status Whiteboard is used for writing short notes about the
+ issue.
+ </dd>
+
+ <dt><b>Keywords</b></dt>
+
+ <dd>
+ This field is used to store various keywords.
+ </dd>
+
+ <dt>
+ <b>Special 'helpwanted' keyword and TASK issue-type</b>
+ </dt>
+
+ <dd>
+ Developers can post <tt>helpwanted</tt> notices, and IssueZilla can
+ help match-make other developers and apprentices who wish to help
+ out with a TASK. Developers should Write <tt>helpwanted</tt> in the
+ Keywords field of an issues, perhaps changing the issue-type of the
+ defect or enhancement to 'TASK'. Others searching for things to do
+ will find it and even accept the issue or TASK. People interested
+ in getting involved can search IssueZilla for issues and
+ ENHANCEMENTs marked <tt>helpwanted</tt>. Maybe one of them will
+ have the expertise and resources to help you with your problem.
+ </dd>
+
+ <dd>
+ Developers can use the TASK issue-type for project-work they'd like
+ to delegate. For instance, if your code has a issue on some
+ platform which you don't have access to, or with some language you
+ don't know, try adding this keyword. A developer can of course
+ change an uncompleted TASK back to DEFECT, ENHANCEMENT or FEATURE
+ (whatever the issue was before it became a TASK again). This could
+ happen, for instance, when the initial issue owner decides nobody
+ is willing to help out with a task.
+ </dd>
+
+ <dd>
+ Or, as with any developer, you're probably swamped with
+ issues. Some of these issues will be lower priority than
+ others. Try marking issues that you realize you won't be able to
+ any time soon as <tt>helpwanted</tt>. Someone else with different
+ priorities may see this and help you out.
+ </dd>
+
+ <dd>
+ When marking issues <tt>helpwanted</tt>, be sure to add a comment
+ carefully explaining what work needs to be done, and how to do it,
+ if you know. The better you can explain the problem and its
+ solution, the more likely it is that someone can provide a useful
+ solution.
+ </dd>
+
+ <dt><b>Dependency</b></dt>
+
+ <dd>
+ If an issue can't be fixed until another issue is fixed, that's a
+ dependency. For any issue, you can list the issues it depends on and
+ issues that depend on it. IssueZilla can display a dependency graphs
+ which shows which the issues it depends on and are dependent
+ dependent on it.
+ </dd>
+
+ <dt><b>Attachment</b></dt>
+
+ <dd>
+ Adding an attachment to an issue can be very useful. Test cases and
+ screen shots can help pinpoint the issue and help the developer
+ reproduce it.
+ </dd>
+
+ <dt><b>Special patch-file 'Attachment' and PATCH issue-type</b></dt>
+
+ <dd>
+ If you've already fixed a defect or done an enhancement, you should
+ report an issue of type PATCH, and attach the patch-file to the
+ issue. This is the preferred way to keep track of patches since it
+ makes it easier for others to find and test. To make a patch, you
+ need to generate a diff file containing the differences between the
+ file with your changes and the original file in the repository. To
+ generate a patch file enumerating changes for all files in the
+ current directory try:
+ <pre style="margin-left: 0.78in; margin-right: 0.39in; margin-bottom:
0.2in">cvs diff -u > mypatch.diff</pre>
+ To apply a patch, go to the proper directory and do:
+ <pre style="margin-left: 0.78in; margin-right: 0.39in; margin-bottom:
0.2in">patch < issuepatch.diff</pre>
+ </dd>
+ </dl>
+ </blockquote>
+
+ <h4>Life Cycle Of An Issue</h4>
+
+ <p>What happens to an issue when it is first reported depends on who
+ reported it. New IssueZilla accounts by default create issues which are
+ <tt>UNCONFIRMED</tt>.
+ Currently, on IssueZilla, the quality assurance is done by
+ a list of users subscribed to a "virtual user"
+ issues@<project>.openoffice.org.
+ <p>
+ You then use your regular IssueZilla account to
+ login, then view, then further "workflow" the issue.
+ <br>
+ <P><A NAME="emailreply"></A>
+ With default settings for your account you will be notified of
+ any change made to the issue. Please do not reply via email to
+ notification messages. The proper way to comment is to login and use the
+ web based frontend. By sending mail to
+ issues-subscribe@<project>.openoffice.org, you can be notified of
+ all changes in bugs of this project.
+ </p>
+
+ <p>If you are a registered OpenOffice.org user, you
+ can create <tt>UNCONFIRMED</tt> issues.
+ When an issue is confirmed and becomes <tt>NEW</tt>, the
+ developer will probably look at the issue and either accept it or give
+ it to someone else. If the issue remains new and inactive for more than
+ a week, IssueZilla nags the issue's owner with email until action is
+ taken. Whenever an issue is reassigned or has its component changed,
+ its status is set back to <tt>NEW</tt>. The <tt>NEW</tt> status means
+ that the issue is newly added to a particular developer's plate, not
+ that the issue is newly reported. Think of "NEW" as an
+ important e-mail you need to answer, except, you answer in IssueZilla,
+ and you can use the tool to better track its progress than e-mail.
+ </p>
+
+ <p>Those to whom additional permissions have been given have the
+ ability to change all the fields of an issue (by default, you can only
+ change a few). Whenever you change a field in an issue its a good idea
+ to add additional comments to explain what you are doing and why. Make
+ a note whenever you do things like change the component, reassign the
+ issue, create an attachment, add a dependency or add someone to the CC
+ list. Whenever someone makes a change to the issue or adds a comment,
+ they are added to the CC list and the owner, reporter and the CC list
+ are sent an email showing the changes to the issue report.
+ </p>
+
+ <p>When a issue is fixed it's marked <tt>RESOLVED</tt> and given one of
+ the following resolutions.
+ </p>
+
+ <blockquote>
+ <dl>
+ <dt><b>FIXED</b></dt>
+
+ <dd>
+ A fix for this issue has been checked into the tree and tested by
+ the person marking it <tt>FIXED</tt>.
+ </dd>
+
+ <dt><b>INVALID</b></dt>
+
+ <dd>
+ The problem described is not a issue, or not a issue in
+ OpenOffice.org.
+ </dd>
+
+ <dt><b>WONTFIX</b></dt>
+
+ <dd>
+ The problem described is a issue which will never be fixed.
+ </dd>
+
+ <dt><b>LATER</b></dt>
+
+ <dd>
+ The problem described is a issue which will not be fixed in this
+ version of the product.
+ </dd>
+
+ <dt><b>REMIND</b></dt>
+
+ <dd>
+ The problem described is a issue which will probably not be fixed
+ in this version of the product, but might still be.
+ </dd>
+
+ <dt><b>DUPLICATE</b></dt>
+
+ <dd>
+ The problem is a duplicate of an existing issue. Marking a issue
+ duplicate requires the issue number of the duplicating issue and
+ will add a comment with the issue number into the description field
+ of the issue it is a duplicate of.
+ </dd>
+
+ <dt><b>WORKSFORME</b></dt>
+
+ <dd>
+ All attempts at reproducing this issue were futile. If more
+ information appears later, please re-assign the issue, for now,
+ file it.
+ </dd>
+
+ <dt><b>MOVED</b></dt>
+
+ <dd>
+ The issue was specific to a particular OpenOffice.org-based
+ distribution and didn't affect OpenOffice.org code. One such
+ scenario are defects reported against Sun's product version of
+ OpenOffice.org. The issue was moved to the bug database of the
+ distributor of the affected OpenOffice.org derivative.
+ </dd>
+ </dl>
+ </blockquote>
+
+ <p>
+ QA looks at resolved issues and to make sure the appropriate action
+ has been taken. If they agreee, the issue is marked
+ <tt>VERIFIED</tt>. Issues remain in this state until the product
+ ships, at which time the issue is marked <tt>CLOSED</tt>. issues may
+ come back to life by becoming <tt>REOPENED</tt>.
+ </p>
+ <p>Be careful when changing the status of someone else's issues.
+ Instead of making the change yourself, its usually best to make a
+ note of your proposed change as a comment and to let the issue's
+ owner review this and make the change themselves. For instance, if
+ you think one issue is a duplicate of another, make a note of it in
+ the <i>Additional Comments</i> section.
+ </p>
+ <p>If you make a lot of useful comments to someone's issues they may
+ come to trust your judgement and ask you to go ahead and make the
+ changes yourself, but unless they do, its best to be cautious and
+ only make comments.
+ </p>
+
+</body>
+</html>
+
