6 Oct 00:09
SF.net SVN: mantisbt:[5631] trunk/mantisbt/docbook/adminguide/en
From: <vboctor@...>
Subject: SF.net SVN: mantisbt:[5631] trunk/mantisbt/docbook/adminguide/en
Newsgroups: gmane.comp.bug-tracking.mantis.cvs
Date: 2008-10-05 22:11:51 GMT
Subject: SF.net SVN: mantisbt:[5631] trunk/mantisbt/docbook/adminguide/en
Newsgroups: gmane.comp.bug-tracking.mantis.cvs
Date: 2008-10-05 22:11:51 GMT
Revision: 5631
http://mantisbt.svn.sourceforge.net/mantisbt/?rev=5631&view=rev
Author: vboctor
Date: 2008-10-05 22:11:51 +0000 (Sun, 05 Oct 2008)
Log Message:
-----------
- Changing "Bug" to "Issue".
- Removing configuration relating to freemind since it is now a plugin.
Modified Paths:
--------------
trunk/mantisbt/docbook/adminguide/en/configuration.sgml
trunk/mantisbt/docbook/adminguide/en/customizing_mantis.sgml
trunk/mantisbt/docbook/adminguide/en/installation.sgml
trunk/mantisbt/docbook/adminguide/en/page_descriptions.sgml
trunk/mantisbt/docbook/adminguide/en/project_management.sgml
trunk/mantisbt/docbook/adminguide/en/user_management.sgml
trunk/mantisbt/docbook/adminguide/en/workflow.sgml
Modified: trunk/mantisbt/docbook/adminguide/en/configuration.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/configuration.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/configuration.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -2423,20 +2423,4 @@
</varlistentry>
</variablelist>
</section>
-
- <section>
- <title>Mind Mapping</title>
-
- <para>This feature is about generating a mindmap based on issues matching the current active filter.</para>
-
- <variablelist>
- <varlistentry>
- <term>$g_mindmap_enabled</term>
- <listitem>
- <para>Enables or disables the mind mapping features including ability to export Freemind files and
in browser view of generated mindmaps. Default is ON.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </section>
</chapter>
Modified: trunk/mantisbt/docbook/adminguide/en/customizing_mantis.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/customizing_mantis.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/customizing_mantis.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -259,10 +259,10 @@
<para>To unlink a custom field, click on "Remove" link next to
the field.
Unlinking a custom field will not delete the values that are
- associated with the bugs for this field. These values are only
+ associated with the issues for this field. These values are only
deleted if the custom field definition is removed (not unlinked!)
from the database. This is useful if you decide to re-link the
- custom field. These values may also re-appear if bugs are moved to
+ custom field. These values may also re-appear if issues are moved to
another project which has this field linked.
</para>
</listitem>
@@ -270,11 +270,11 @@
</para>
<formalpara>
- <title>Moving Bugs</title>
+ <title>Moving Issues</title>
<para>
- When a bug is moved from one project to another, custom
+ When an issue is moved from one project to another, custom
fields that are not defined for the new project are not deleted.
- These fields will re-appear with their correct values if the bug is
+ These fields will re-appear with their correct values if the issue is
moved back to the original project, or if these custom fields are
linked to the new project.
</para>
@@ -599,19 +599,19 @@
</para>
</listitem>
<listitem>
- <para>Exclude those who contributed bug notes from getting
- messages about other changes in the bug.
+ <para>Exclude those who contributed issue notes from getting
+ messages about other changes in the issue.
<programlisting>$g_default_notify_flags['bugnotes'] = OFF;</programlisting>
</para>
</listitem>
<listitem>
- <para>Exclude those monitoring bugs from seeing the 'closed'
+ <para>Exclude those monitoring issues from seeing the 'closed'
message
<programlisting>$g_notify_flags['closed']['monitor'] = OFF;</programlisting>
</para>
</listitem>
<listitem>
- <para>Only notify developers when bugnotes are added.
+ <para>Only notify developers when issue notes are added.
<programlisting>$g_notify_flags['bugnote']['threshold_min'] = DEVELOPER;
$g_notify_flags['bugnote']['threshold_max'] = DEVELOPER;
</programlisting>
@@ -636,7 +636,7 @@
<listitem>
<para>I'm paranoid about mail. Only send information on issues
to those involved in them. Don't send mail people already know
- about. Also send new bug notifications to managers so they can
+ about. Also send new issue notifications to managers so they can
screen them.
<programlisting>$g_mail_receive_own = OFF;
$g_default_notify_flags =
@@ -780,20 +780,20 @@
Changelogcustom_function_default_checkin( $p_issue_id, $p_comment,
$p_file, $p_new_version ) registers a checkin in source control in
MantisBT custom_function_default_issue_update_validate( $p_issue_id,
- $p_new_bug, $p_bug_note_text ) validate bug field settings before
+ $p_new_bug, $p_bug_note_text ) validate issue field settings before
an update occurs. It returns true or fails with an
error.custom_function_default_issue_update_notify( $p_issue_id )
- notify after a bug has been
+ notify after an issue has been
updatedcustom_function_default_issue_create_validate( $p_new_bug )
- validate bug field settings before an issue is created. It returns
+ validate issue field settings before an issue is created. It returns
true or fails with an
error.custom_function_default_issue_create_notify( $p_issue_id )
- notify after a bug has been
+ notify after an issue has been
openedcustom_function_default_issue_delete_validate( $p_issue_id )
- validate bug field settings before an issue can be deleted. It
+ validate issue field settings before an issue can be deleted. It
returns true or fails with an
error.custom_function_default_issue_delete_notify( $p_issue_id )
- notify after a bug has been deleted
+ notify after an issue has been deleted
</para>
</section>
Modified: trunk/mantisbt/docbook/adminguide/en/installation.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/installation.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/installation.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -163,9 +163,9 @@
<listitem>
<para>Login to your bugtracker and go to the manage section.
- Click on theprojects link. You will need to ADD a new project. Then
- EDIT the new projectand remember to ADD at least one category.
- Otherwise you won't be able to addany bug reports.That should be
+ Click on the projects link. You will need to ADD a new project. Then
+ EDIT the new project and remember to ADD at least one category.
+ Otherwise you won't be able to add any issues. That should be
it. You're off and running.
</para>
</listitem>
@@ -252,7 +252,7 @@
make cataloguing easier.
!!! Backups should always be performed before an upgrade !!!
Make sure to backup Mantis code (which includes your configs +
- possibly customization), bug attachments / project documents, and
+ possibly customization), issue attachments / project documents, and
database contents.
</para>
@@ -264,7 +264,7 @@
<para>CVS integration allows Mantis to register commits to the CVS
- source control system into corresponding bug notes in the issue
+ source control system into corresponding issue notes in the issue
tracker.The setup requires that the mantis installation be
accessible on the computer running the CVS server. A copy of the
Mantis config_inc.php file must be present.Note that the mysql
@@ -276,8 +276,8 @@
ALL /usr/bin/php /path_to_mantis/core/checkin.php
This will pass the commit message to checkin.php for all commits.
If the stringissue #nnnn is found in the commit message, the Mantis
- corresponding to "nnnn" will have the CVS commit message added as a
- bug note to the issue. Multiple issues can be listed.This feature
+ corresponding to "nnnn" will have the CVS commit message added as an
+ issue note to the issue. Multiple issues can be listed.This feature
is configured through config_inc.php and through custom
functions.
</para>
Modified: trunk/mantisbt/docbook/adminguide/en/page_descriptions.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/page_descriptions.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/page_descriptions.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -50,48 +50,58 @@
<section>
- <title>View Bugs page</title>
+ <title>View Issues page</title>
- <para>Here we can view the bug listings. The page has a set of
- viewing filters at the top and the bugs are listed below.FiltersThe
- filters control the behavior of the bug list. The filters are saved
+ <para>Here we can view the issue listings. The page has a set of
+ viewing filters at the top and the issues are listed below.FiltersThe
+ filters control the behavior of the issues list. The filters are saved
between browsing sessions but do not currently save sort order or
- direction.If the number of bugs exceeds the "Show" count in the
+ direction.If the number of issues exceeds the "Show" count in the
filter a set of navigation to go to "First", "Last", "Previous",
"Next" and specific page numbers are added.The Search field will
look for simple keyword matches in the summary, description, steps
- to reproduce, additional information, bug id, or bug text id
- fields. It does not search through bugnotes.Bug ListThe bugs are
+ to reproduce, additional information, issue id, or issue text id
+ fields. It does not search through issue notes.
+
+ Issue List - The issues are
listed in a table and the attributes are listed in the following
- order: priority, id, number of bugnotes, category, severity,
+ order: priority, id, number of issue notes, category, severity,
status, last updated, and summary. Each (except for number of
- bugnotes) can be clicked on to sort by that column. Clicking again
+ issue notes) can be clicked on to sort by that column. Clicking again
will reverse the direction of the sort. The default is to sort by
- last modification time, where the last modified bug appears at the
- top.The bug id is a link that leads to a more detailed report about
- the bug. Depending on what you have set in your Account Preferences
+ last modification time, where the last modified issue appears at the
+ top. The issue id is a link that leads to a more detailed report about
+ the issue. Depending on what you have set in your Account Preferences
you will be sent to the simple or advanced view. You can also add
- bugnotes here.The number in the bugnote count column will be bold
- if a bugnote has been added in the specified time frame. The
- addition of a bugnote will make the bugnote link of the bug appear
+ issue notes here.The number in the issue note count column will be bold
+ if an issue note has been added in the specified time frame. The
+ addition of an issue note will make the issue note link of the issue appear
in the unvisited state.The text in the "Severity" column will be
- bold if the severity is major, crash, or block and the bug not
- resolved.The text in the "Updated" column will be bold if the bug
+ bold if the severity is major, crash, or block and the issue not
+ resolved.The text in the "Updated" column will be bold if the issue
has changed in the last "Changed(hrs)" field which is specified in
the viewing filters.Each table row is color coded according to the
- bug status. The colors can be customised through Mantis
+ issue status. The colors can be customised through Mantis
<ulink url="manual.configuration.html">Configuration</ulink>
.Severitiesblock
- - prevents further work/progress from being madecrash - crashes the
- application or OSmajor - major bugminor - minor bugtweak - needs
- tweakingtext - error in the texttrivial - being nitpickyfeature -
- requesting new featureStatusnew - new bugsfeedback - bug requires
- more information, the original posters should pay
- attentionacknowledged - bug has been looked at but not confirmed or
- assignedconfirmed - confirmed and reproducible (typically set by an
- Updater or other Developer)assigned - assigned to a
- Developerresolved - bug should be fixed, waiting on confirmation of
- fixclosed - bug is closedMoving the mouse over the status text will
+ - prevents further work/progress from being made
+ crash - crashes the application or blocking,
+ major - major issue,
+ minor - minor issue,
+ tweak - needs tweaking,
+ text - error in the text,
+ trivial - being nit picky,
+ feature - requesting new feature
+ - Status
+ new - new issue,
+ feedback - issue requires more information from reporter,
+ acknowledged - issue has been looked at but not confirmed or assigned,
+ confirmed - confirmed and reproducible (typically set by an
+ Updater or other Developer),
+ assigned - assigned to a Developer,
+ resolved - issue should be fixed, waiting on confirmation of fix,
+ closed - issue is closed,
+ Moving the mouse over the status text will
show the resolution as a title. This is rendered by some browsers
as a bubble and in others as a status line text.
</para>
@@ -100,16 +110,16 @@
<section>
- <title>Bug View Simple page</title>
+ <title>Issue View Simple page</title>
- <para>Here is the simple listing of the bug report. Most of the
+ <para>Here is the simple listing of the issue report. Most of the
fields are self-explanatory. "Assigned To" will contain the
- developer assigned to handle the bug. Priority is fully functional
+ developer assigned to handle the issue. Priority is fully functional
but currently does nothing of importance. Duplicate ID is used when
- a bug is a duplicate of another. It links to the duplicate bug
- which allows users to read up on the original bug report.Below the
- bug report is a set of buttons that a user can select to work on
+ an issue is a duplicate of another. It links to the duplicate issue
+ which allows users to read up on the original issue report. Below the
+ issue report is a set of buttons that a user can select to work on
the issue.
</para>
<itemizedlist>
@@ -155,8 +165,8 @@
</listitem>
<listitem>
<para>Delete Issue - Allows the user to delete the issue
- permanently. It is recommended against deleting bugs unless the
- entry is frivolous. Instead bugs should be set to resolved and an
+ permanently. It is recommended against deleting issues unless the
+ entry is frivolous. Instead issues should be set to resolved and an
appropriate resolution category chosen.
</para>
</listitem>
@@ -170,36 +180,28 @@
is also possible.Below this, there may be a form for uploading file
attachments. The Administrator needs to configure the bugtracker to
handle file uploads. If uploading to disk is selected, each project
- needs to set its own upload path.Bugnotes are shown at the bottom
- of the bug report. A panel to add bugnotes is also shown.
- </para>
-
+ needs to set its own upload path. Issue notes are shown at the bottom
+ of the issue report. A panel to add issue notes is also shown.
+ </para>
</section>
-
-
+
<section>
- <title>Bug View Advanced page</title>
+ <title>Issue View Advanced page</title>
<para>The advanced view is much the same as the simple view with a
few additional fields. Here you can see Projection, ETA, Platform,
OS, OSBuild, Product Version, Product Build, and Steps to
Reproduce.
</para>
- <para>See also:
- <ulink url="manual.page.descriptions.bug.view.simple.page.html">Bug
- View Simple page
- </ulink>
- </para>
+ <para>See also: Issue View Simple page.</para>
</section>
-
<section>
- <title>Bug Change Status page</title>
+ <title>Issue Change Status page</title>
-
<para>This page is used to change the status of an issue. A user
- can add a bugnote to describe the reason for change.In addition,
+ can add an issue note to describe the reason for change.In addition,
the following fields may be displayed for update:
<itemizedlist>
<listitem>
@@ -231,24 +233,24 @@
<section>
- <title>Bug Update Simple page</title>
+ <title>Issue Update Simple page</title>
<para>The layout of this page resemples the Simple Issue View
- page, but here you can update various bug fields. The Reporter,
+ page, but here you can update various issue fields. The Reporter,
Category, Severity, and Reproducibility fields are editable but
shouldn't be unless there is a gross mis-categorization.Also
modifiable are the Assigned To, Priority, Projection, ETA,
Resolution, and Duplicate ID fields.As per version 0.18.0, the user
- can also add a bugnote as part of a bug update.
+ can also add an issue note as part of an issue update.
</para>
</section>
<section>
- <title>Bug Update Advanced page</title>
+ <title>Issue Update Advanced page</title>
- <para>Similar to Bug Update Simple page but has the extra advanced
+ <para>Similar to Issue Update Simple page but has the extra advanced
fields. The difference between the simple/advanced update pages
should be consistent with the difference between the
simple/advanced view pages.
@@ -282,7 +284,7 @@
</listitem>
<listitem>
<para>the delay in minutes between refreshes of the view all
- bugs page
+ issues page
</para>
</listitem>
<listitem>
@@ -546,7 +548,7 @@
</row>
<row>
<entry>Display Only On Advanced Page</entry>
- <entry>If checked, the field will NOT be shown on the simple bug
+ <entry>If checked, the field will NOT be shown on the simple issue
displays
</entry>
</row>
@@ -774,8 +776,8 @@
<row>
<entry>Update View Status</entry>
<entry>$g_change_view_status_threshold</entry>
- <entry>threshold needed to update the view status while updating a
- bug or a bug note
+ <entry>threshold needed to update the view status while updating an
+ issue or an issue note
</entry>
</row>
<row>
@@ -817,27 +819,27 @@
<row>
<entry>Add Notes</entry>
<entry>$g_add_bugnote_threshold</entry>
- <entry>threshold to add a bugnote</entry>
+ <entry>threshold to add an issue note</entry>
</row>
<row>
<entry>Update Notes</entry>
<entry>$g_update_bugnote_threshold</entry>
- <entry>threshold to edit a bugnote</entry>
+ <entry>threshold to edit an issue note</entry>
</row>
<row>
<entry>Allow users to edit their own bugnotes</entry>
<entry>$g_bugnote_allow_user_edit_delete</entry>
- <entry>can a user edit/delete their own bugnotes</entry>
+ <entry>can a user edit/delete their own issue notes</entry>
</row>
<row>
<entry>Delete Note</entry>
<entry>$g_delete_bugnote_threshold</entry>
- <entry>threshold to delete a bugnote</entry>
+ <entry>threshold to delete an issue note</entry>
</row>
<row>
<entry>View private notes</entry>
<entry>$g_private_bugnote_threshold</entry>
- <entry>threshold to view a private bugnote</entry>
+ <entry>threshold to view a private issue note</entry>
</row>
</tbody>
</tgroup>
@@ -902,7 +904,7 @@
<row>
<entry>Status where an issue is considered resolved</entry>
<entry>$g_bug_resolved_status_threshold</entry>
- <entry>status where bug is resolved</entry>
+ <entry>status where issue is resolved</entry>
</row>
<row>
<entry>Status to which a reopened Issue is set</entry>
@@ -940,10 +942,10 @@
<para>the handler (or Assigned to)</para>
</listitem>
<listitem>
- <para>anyone monitoring the bug</para>
+ <para>anyone monitoring the issue</para>
</listitem>
<listitem>
- <para>anyone who has ever added a bugnote the bug</para>
+ <para>anyone who has ever added a issue note the issue</para>
</listitem>
<listitem>
<para>anyone assigned to the project whose access level matches
@@ -985,13 +987,13 @@
</section>
<section>
- <title>Monitor Bug</title>
+ <title>Monitor Issue</title>
<para>The monitor issues feature allows users to subscribe to
certain issues and hence get copied on all notification emails that
are sent for these issues.Depending on the configuration, sending a
reminder to a user about an issue can add this issue to the user's
- list of monitored bugs.Users who reported the issue or are assigned
+ list of monitored issues. Users who reported the issue or are assigned
the issue typically don't need to monitor the issue to get the
notifications. This is because by default they get notified on
changes related to the issue anyway. However, administrators can
@@ -1001,41 +1003,41 @@
</section>
<section>
- <title>Reopen Bug</title>
+ <title>Reopen Issue</title>
- <para>Re-open bug button is visible in the bug view pages if the
- user has the appropriate access level and the bug is
- resolved/closed. Re-opening a bug will allow users to enter a
- bugnotes for the re-opening reason. The bug will automatically be
+ <para>Re-open issue button is visible in the issue view pages if the
+ user has the appropriate access level and the issue is
+ resolved/closed. Re-opening a issue will allow users to enter
+ issue notes for the re-opening reason. The issue will automatically be
put into the Feedback status.
</para>
</section>
<section>
- <title>Delete Bug</title>
+ <title>Delete Issue</title>
- <para>The delete bugs button appears on the bug view pages for the
+ <para>The delete issues button appears on the issue view pages for the
users who have the appropriate access level. This allows you to
- delete an existing bug. This should only be used on frivolous or
- test bugs. A confirmation screen will prompt you if you really want
- to delete the bug. Updaters, Developers, Managers, and
- Administrators can remove bugs (you can also configure
+ delete an existing issue. This should only be used on frivolous or
+ test issues. A confirmation screen will prompt you if you really want
+ to delete the issue. Updaters, Developers, Managers, and
+ Administrators can remove issues (you can also configure
this).
</para>
</section>
<section>
- <title>Close Bug</title>
+ <title>Close Issue</title>
- <para>This is a button that appears on the bug view pages for
- users that are authorized to close bugs. Depending on the
- configuration, users may be able to close bugs without having to
- resolve them first, or may be able to only close resolved bugs.
+ <para>This is a button that appears on the issue view pages for
+ users that are authorized to close issues. Depending on the
+ configuration, users may be able to close issues without having to
+ resolve them first, or may be able to only close resolved issues.
After the button is clicked, the user is redirected to a page where
- a bugnote maybe added.
+ an issue note maybe added.
</para>
</section>
@@ -1043,27 +1045,23 @@
<section>
<title>Assign to Me</title>
- <para>This button appears in the bug view pages in case of users
+ <para>This button appears in the issue view pages in case of users
with access level that is equal to handle_bug_threshold or higher.
- When this button is clicked the bug is assigned to the
+ When this button is clicked the issue is assigned to the
user.
</para>
</section>
<section>
- <title>Resolve Bug</title>
+ <title>Resolve Issue</title>
- <para>This option on the View Bugs page allows you to resolve the
- bug. It will lead you to a page where you can set the resolution
+ <para>This option on the View Issues page allows you to resolve the
+ issue. It will lead you to a page where you can set the resolution
state and a duplicate id (if applicable). After choosing that the
- user can choose to enter a bugnote detailing the reason for the
- closure. The bug is then set to the Resolved state. The reporter
- should check off on the bug by using the
- <ulink url="manual.page.descriptions.close.bug.html">Close
- Bug
- </ulink>
- button.
+ user can choose to enter an issue note detailing the reason for the
+ closure. The issue is then set to the Resolved state. The reporter
+ should check off on the issue by using the Close Issue button.
</para>
</section>
Modified: trunk/mantisbt/docbook/adminguide/en/project_management.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/project_management.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/project_management.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -130,7 +130,7 @@
</para>
<para>
- Some teams manage different branches for each of their projects (e.g. development and maintenance
branches). As part of triaging the bugs, they may decide that a bug should be targetted to multiple
branches. Hence, frequently the request comes up to be able to target a single issue to multiple releases.
The current MantisBT approach is that an issues represents an implementation or a fix for an issue on a
specific branch. Since sometimes applying and verifying a fix to the two branches does not happen at the
same time and in some cases the approach for fixing an issue is different based on the branch. Hence, the way
to manage such scenario is to have the main issue for the initial fix and have related issues which capture
the work relating to applying the fix to other bra
nches. The issues for porting the fix can contain any discussions relating to progress, reflect the
appropriate status and can go through the standard workflow process independent of the original issues.
+ Some teams manage different branches for each of their projects (e.g. development and maintenance
branches). As part of triaging the issue, they may decide that an issue should be targetted to multiple
branches. Hence, frequently the request comes up to be able to target a single issue to multiple releases.
The current MantisBT approach is that an issues represents an implementation or a fix for an issue on a
specific branch. Since sometimes applying and verifying a fix to the two branches does not happen at the
same time and in some cases the approach for fixing an issue is different based on the branch. Hence, the way
to manage such scenario is to have the main issue for the initial fix and have related issues which capture
the work relating to applying the fix to other
branches. The issues for porting the fix can contain any discussions relating to progress, reflect the
appropriate status and can go through the standard workflow process independent of the original issues.
</para>
<para>Another common requirement is to be able to link to the roadmap of a specific project from the
project's main website. This can be done by a link that looks like the one below. The project id can be
figured out by going to the management page for the project and getting the value of project_id field form
the URL.
Modified: trunk/mantisbt/docbook/adminguide/en/user_management.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/user_management.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/user_management.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -210,7 +210,7 @@
example, viewing an issue, reporting an issue, updating an issue, adding
a note, etc.</para>
- <para>For example, in the case of reporting bugs, the required access
+ <para>For example, in the case of reporting issues, the required access
level is configurable using the $g_report_bug_threshold configuration
option (which is defaulted to REPORTER). So for a user to be able to
report an issue against a public project, the user must have a
Modified: trunk/mantisbt/docbook/adminguide/en/workflow.sgml
===================================================================
--- trunk/mantisbt/docbook/adminguide/en/workflow.sgml 2008-10-05 07:37:58 UTC (rev 5630)
+++ trunk/mantisbt/docbook/adminguide/en/workflow.sgml 2008-10-05 22:11:51 UTC (rev 5631)
@@ -51,7 +51,7 @@
"assigned" or "resolved".</para></listitem>
<listitem><para>Acknowledged - This status is used by the development team
to reflect their agreement to the suggested feature request. Or to
- agree with what the reporter is suggesting in a bug report, although
+ agree with what the reporter is suggesting in an issue report, although
they didn't yet attempt to reproduce what the reporter is referring
to. The next status is typically "assigned" or "confirmed".</para></listitem>
<listitem><para>Confirmed - This status is typically used by the
@@ -206,7 +206,7 @@
to be able to add notes.</para></listitem>
<listitem><para>Update notes - The access levels required for
users to be able to update issue notes.</para></listitem>
- <listitem><para>Allow user to edit their own bugnotes - A flag
+ <listitem><para>Allow user to edit their own issue notes - A flag
that indicates the ability for users to edit issue notes report by them.</para></listitem>
<listitem><para>Delete note - The access levels required for a
user to delete a note that they may or may not have reported
This was sent by the SourceForge.net collaborative development platform, the world's largest Open
Source development site.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
RSS Feed