Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Changes from mcote's review of section 8.

Browse Source 
git-svn-id: svn://10.0.0.236/trunk@265735 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
bzrmirror%bugzilla.org
2014-12-03 22:32:41 +00:00
parent 7a529ad3fe
commit f111f892e1
10 changed files with 145 additions and 145 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
mozilla/webtools/bugzilla/.bzrrev
View File

@@ -1 +1 @@
9261
9262

2
mozilla/webtools/bugzilla/.gitrev
View File

@@ -1 +1 @@
81930b6e591ba122b270372e56ce4143fde8a084
a402acb9a40582f3d6b6cd913a3a6ec640b7442d

2
mozilla/webtools/bugzilla/docs/en/rst/using/creating-an-account.rst
View File

@@ -35,5 +35,5 @@ The process of creating an account is similar to many other websites.
login form, and click the :guilabel:`Log in` button.
You are now logged in. Bugzilla uses cookies to remember you are
logged in so, unless you have cookies disabled or your IP address changes,
logged in, so, unless you have cookies disabled or your IP address changes,
you should not have to log in again during your session.

61
mozilla/webtools/bugzilla/docs/en/rst/using/editing.rst
View File

@@ -8,10 +8,14 @@ Editing a Bug
Attachments
===========
You should use attachments, rather than comments, for large chunks of ASCII
data, such as trace, debugging output files, or log files. That way, it
Attachments are used to attach relevant files to bugs - patches, screenshots,
test cases, debugging aids or logs, or anything else binary or too large to
fit into a comment.
You should use attachments, rather than comments, for large chunks of plain
text data, such as trace, debugging output files, or log files. That way, it
doesn't bloat the bug for everyone who wants to read it, and cause people to
receive fat, useless mails.
receive large, useless mails.
You should make sure to trim screenshots. There's no need to show the
whole screen if you are pointing out a single-pixel problem.
@@ -36,45 +40,22 @@ in a temporary file.
Flags
=====
A flag is a kind of status that can be set on bugs or attachments
to indicate that the bugs/attachments are in a certain state.
Each installation can define its own set of flags that can be set
on bugs or attachments.
If your installation has defined a flag, you can set or unset that flag,
and if your administrator has enabled requesting of flags, you can submit
a request for another user to set the flag.
To set a flag, select either "+" or "-" from the drop-down menu next to
the name of the flag in the "Flags" list. The meaning of these values are
flag-specific and thus cannot be described in this documentation,
but by way of example, setting a flag named "review" to "+" may indicate
that the bug/attachment has passed review, while setting it to "-"
may indicate that the bug/attachment has failed review.
To set a flag, select either :guilabel:`+` or :guilabel:`-` from the drop-down
menu next to the name of the flag in the :guilabel:`Flags` list. The meaning
of these values are flag-specific and thus cannot be described in this
documentation, but by way of example, setting a flag named :guilabel:`review`
:guilabel:`+` may indicate that the bug/attachment has passed review, while
setting it to :guilabel:`-` may indicate that the bug/attachment has failed
review.
To unset a flag, click its drop-down menu and select the blank value.
Note that marking an attachment as obsolete automatically cancels all
pending requests for the attachment.
If your administrator has enabled requests for a flag, request a flag
by selecting "?" from the drop-down menu and then entering the username
of the user you want to set the flag in the text field next to the menu.
A set flag appears in bug reports and on "edit attachment" pages with the
abbreviated username of the user who set the flag prepended to the
flag name. For example, if Jack sets a "review" flag to "+", it appears
as Jack: review [ + ]
A requested flag appears with the user who requested the flag prepended
to the flag name and the user who has been requested to set the flag
appended to the flag name within parentheses. For example, if Jack
asks Jill for review, it appears as Jack: review [ ? ] (Jill).
You can browse through open requests made of you and by you by selecting
'My Requests' from the footer. You can also look at open requests limited
by other requesters, requestees, products, components, and flag names from
this page. Note that you can use '-' for requestee to specify flags with
'no requestee' set.
by selecting :guilabel:`?` from the drop-down menu and then entering the
username of the user you want to set the flag in the text field next to the
menu.
.. _time-tracking:
@@ -84,21 +65,21 @@ Time Tracking
Users who belong to the group specified by the ``timetrackinggroup``
parameter have access to time-related fields. Developers can see
deadlines and estimated times to fix bugs, and can provide time spent
on these bugs. Users who do not belong to this group can only see the deadline,
on these bugs. Users who do not belong to this group can only see the deadline
but not edit it. Other time-related fields remain invisible to them.
At any time, a summary of the time spent by developers on bugs is
accessible either from bug lists when clicking the ``Time Summary``
button or from individual bugs when clicking the ``Summarize time``
link in the time tracking table. The :file:`summarize_time.cgi`
page lets you view this information either per developer or per bug,
page lets you view this information either per developer or per bug
and can be split on a month basis to have greater details on how time
is spent by developers.
As soon as a bug is marked as RESOLVED, the remaining time expected
to fix the bug is set to zero. This lets QA people set it again for
their own usage, and it will be set to zero again when the bug will
be marked as CLOSED.
their own usage, and it will be set to zero again when the bug is
marked as VERIFIED.
.. _lifecycle:

19
mozilla/webtools/bugzilla/docs/en/rst/using/filing.rst
View File

@@ -10,11 +10,10 @@ Years of bug writing experience has been distilled for your
reading pleasure into the
`Bug Writing Guidelines <http://landfill.bugzilla.org/bugzilla-tip/page.cgi?id=bug-writing.html>`_.
While some of the advice is Mozilla-specific, the basic principles of
reporting Reproducible, Specific bugs, isolating the Product you are
using, the Version of the Product, the Component which failed, the
Hardware Platform, and Operating System you were using at the time of
the failure go a long way toward ensuring accurate, responsible fixes
for the bug that bit you.
reporting Reproducible, Specific bugs and isolating the Product you are
using, the Version of the Product, the Component which failed, the Hardware
Platform, and Operating System you were using at the time of the failure go a
long way toward ensuring accurate, responsible fixes for the bug that bit you.
.. note:: If you want to file a test bug to see how Bugzilla works,
you can do it on one of our test installations on
@@ -58,10 +57,10 @@ The procedure for filing a bug is as follows:
which you are filing the bug, you can also request developers to consider
your bug in different ways (such as requesting review for the patch you
just attached, requesting your bug to block the next release of the
product, and many other product specific requests).
product, and many other product-specific requests).
#. Now is a good time to read your bug report again. Remove all mis-spellings,
otherwise your bug may not be found by developers running queries for some
#. Now is a good time to read your bug report again. Remove all misspellings;
otherwise, your bug may not be found by developers running queries for some
specific words, and so your bug would not get any attention.
Also make sure you didn't forget any important information developers
should know in order to reproduce the problem, and make sure your
@@ -74,9 +73,9 @@ The procedure for filing a bug is as follows:
Clone an Existing Bug
=====================
Bugzilla allows you to 'clone' an existing bug. The newly created bug will
Bugzilla allows you to "clone" an existing bug. The newly created bug will
inherit most settings from the old bug. This allows you to track similar
concerns which require different handling in a new bug. To use this, go to
concerns that require different handling in a new bug. To use this, go to
the bug that you want to clone, then click the :guilabel:`Clone This Bug`
link on the bug page. This will take you to the :guilabel:`Enter Bug`
page that is filled with the values that the old bug has.

13
mozilla/webtools/bugzilla/docs/en/rst/using/finding.rst
View File

@@ -5,7 +5,7 @@ Finding Bugs
Bugzilla has a number of different search options.
.. note:: Bugzilla queries are case-insensitive and accent-insensitive, when
.. note:: Bugzilla queries are case-insensitive and accent-insensitive when
used with either MySQL or Oracle databases. When using Bugzilla with
PostgreSQL, however, some queries are case-sensitive. This is due to
the way PostgreSQL handles case and accent sensitivity.
@@ -33,6 +33,9 @@ would search only in that product.
You can also use it to go directly to a bug by entering its number or its
alias.
.. todo:: Need to incorporate the full reference, and link it properly from
the GUI. https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html
Simple Search
=============
@@ -43,7 +46,7 @@ Advanced Search
===============
The Advanced Search page is used to produce a list of all bugs fitting
exactly-defined criteria. `You can play with it on
exact criteria. `You can play with it on
Landfill <http://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced>`_.
Advanced Search has controls for selecting different possible
@@ -55,7 +58,7 @@ values. If none is selected, then the field can take any value.
After a search is run, you can save it as a Saved Search, which
will appear in the page footer. If you are in the group defined
by the "querysharegroup" parameter, you may share your queries
with other users, see :ref:`saved-searches` for more details.
with other users; see :ref:`saved-searches` for more details.
.. _custom-search:
@@ -220,11 +223,11 @@ Change Columns:
Change several bugs at once:
If your account is sufficiently empowered, and more than one bug
appear in the bug list, this link is displayed which lets you make
appears in the bug list, this link is displayed and lets you easily make
the same change to all the bugs in the list - for example, changing
their assignee.
Send mail to bug assignees:
Send mail to bug assignees:
If more than one bug appear in the bug list and there are at least
two distinct bug assignees, this links is displayed which lets you
easily send a mail to the assignees of all bugs on the list.

31
mozilla/webtools/bugzilla/docs/en/rst/using/preferences.rst
View File

@@ -5,7 +5,8 @@ User Preferences
Once logged in, you can customize various aspects of
Bugzilla via the "Preferences" link in the page footer.
The preferences are split into a number of tabs:
The preferences are split into a number of tabs, detailed in the sections
below.
.. _generalpreferences:
@@ -42,7 +43,7 @@ There are two global options -- ``Email me when someone
asks me to set a flag`` and ``Email me when someone
sets a flag I asked for``. These define how you want to
receive bugmail with regards to flags. Their use is quite
straightforward; enable the checkboxes if you want Bugzilla to
straightforward: enable the checkboxes if you want Bugzilla to
send you mail under either of the above conditions.
If you'd like to set your bugmail to something besides
@@ -57,14 +58,14 @@ or CC list member.
To fine-tune your bugmail, decide the events for which you want
to receive bugmail; then decide if you want to receive it all
the time (enable the checkbox for every column), or only when
the time (enable the checkbox for every column) or only when
you have a certain relationship with a bug (enable the checkbox
only for those columns). For example: if you didn't want to
only for those columns). For example, if you didn't want to
receive mail when someone added themselves to the CC list, you
could uncheck all the boxes in the ``CC Field Changes``
line. As another example, if you never wanted to receive email
on bugs you reported unless the bug was resolved, you would
un-check all boxes in the ``Reporter`` column
uncheck all boxes in the ``Reporter`` column
except for the one on the ``The bug is resolved or
verified`` row.
@@ -97,10 +98,10 @@ Saved Searches
==============
On this tab you can view and run any Saved Searches that you have
created, and also any Saved Searches that other members of the group
created, and any Saved Searches that other members of the group
defined in the :param:`querysharegroup` parameter have shared.
Saved Searches can be added to the page footer from this screen.
If somebody is sharing a Search with a group she or he is allowed to
If somebody is sharing a Search with a group they are allowed to
:ref:`assign users to <groups>`, the sharer may opt to have
the Search show up in the footer of the group's direct members by default.
@@ -115,7 +116,7 @@ reasons, in order to change anything on this page you must type your
*current* password into the ``Password``
field at the top of the page.
If you attempt to change your email address, a confirmation
email is sent to both the old and new addresses, with a link to use to
email is sent to both the old and new addresses with a link to use to
confirm the change. This helps to prevent account hijacking.
.. _api-keys:
@@ -123,19 +124,19 @@ confirm the change. This helps to prevent account hijacking.
API Keys
========
API Keys allow you to give a "token" to some external software so it can log
API keys allow you to give a "token" to some external software so it can log
in to the WebService API as you without knowing your password. You can then
revoke that token if you stop using the web service, and you don't need to
change your password everywhere.
You can create more than one API key if required. Each API key has an optional
description which can help you record what each key is used for.
description which can help you record what it is used for.
On this page, you can unrevoke, revoke and change the description of existing
API keys for your login. A revoked key means that it cannot be used. The
description for purely for your information, and is optional.
description is optional and purely for your information.
You can also create a new API key by selecting the check box under the 'New
You can also create a new API key by selecting the checkbox under the 'New
API key' section of the page.
.. _permissions:
@@ -178,14 +179,14 @@ editbugs
Indicates user can edit all bug fields.
editclassifications
Indicates user can create, destroy, and edit classifications.
Indicates user can create, destroy and edit classifications.
editcomponents
Indicates user can create, destroy, and edit products, components,
Indicates user can create, destroy and edit products, components,
versions, milestones and flag types.
editkeywords
Indicates user can create, destroy, and edit keywords.
Indicates user can create, destroy and edit keywords.
editusers
Indicates user can create, disable and edit users.

55
mozilla/webtools/bugzilla/docs/en/rst/using/reports-and-charts.rst
View File

@@ -6,7 +6,7 @@ Reports and Charts
As well as the standard buglist, Bugzilla has two more ways of
viewing sets of bugs. These are the reports (which give different
views of the current state of the database) and charts (which plot
the changes in particular sets of bugs over time.)
the changes in particular sets of bugs over time).
.. _reports:
@@ -17,22 +17,22 @@ A report is a view of the current state of the bug database.
You can run either an HTML-table-based report, or a graphical
line/pie/bar-chart-based one. The two have different pages to
define them, but are close cousins - once you've defined and
define them but are close cousins - once you've defined and
viewed a report, you can switch between any of the different
views of the data at will.
Both report types are based on the idea of defining a set of bugs
using the standard search interface, and then choosing some
using the standard search interface and then choosing some
aspect of that set to plot on the horizontal and/or vertical axes.
You can also get a form of 3-dimensional report by choosing to have
multiple images or tables.
So, for example, you could use the search form to choose "all
bugs in the WorldControl product", and then plot their severity
bugs in the WorldControl product" and then plot their severity
against their component to see which component had had the largest
number of bad bugs reported against it.
Once you've defined your parameters and hit "Generate Report",
Once you've defined your parameters and hit :guilabel:`Generate Report`,
you can switch between HTML, CSV, Bar, Line and Pie. (Note: Pie
is only available if you didn't define a vertical axis, as pie
charts don't have one.) The other controls are fairly self-explanatory;
@@ -61,45 +61,46 @@ can define as a search.
An individual line on a chart is called a data set.
All data sets are organised into categories and subcategories. The
data sets that Bugzilla defines automatically use the Product name
as a Category and Component names as Subcategories, but there is no
need for you to follow that naming scheme with your own charts if
you don't want to.
as a :guilabel:`Category` and Component names as :guilabel:`Subcategories`,
but there is no need for you to follow that naming scheme with your own
charts if you don't want to.
Data sets may be public or private. Everyone sees public data sets in
the list, but only their creator sees private data sets. Only
administrators can make data sets public.
No two data sets, even two private ones, can have the same set of
category, subcategory and name. So if you are creating private data
sets, one idea is to have the Category be your username.
sets, one idea is to have the :guilabel:`Category` be your username.
Creating Charts
---------------
You create a chart by selecting a number of data sets from the
list, and pressing Add To List for each. In the List Of Data Sets
To Plot, you can define the label that data set will have in the
chart's legend, and also ask Bugzilla to Sum a number of data sets
(e.g. you could Sum data sets representing RESOLVED, VERIFIED and
CLOSED in a particular product to get a data set representing all
the resolved bugs in that product.)
list and pressing :guilabel:`Add To List` for each. In the
:guilabel:`List Of Data Sets To Plot`, you can define the label that data
set will have in the chart's legend and also ask Bugzilla to :guilabel:`Sum`
a number of data sets (e.g. you could :guilabel:`Sum` data sets representing
:guilabel:`RESOLVED`, :guilabel:`VERIFIED` and :guilabel:`CLOSED` in a
particular product to get a data set representing all the resolved bugs in
that product.)
If you've erroneously added a data set to the list, select it
using the checkbox and click Remove. Once you add more than one
data set, a "Grand Total" line
using the checkbox and click :guilabel:`Remove`. Once you add more than one
data set, a :guilabel:`Grand Total` line
automatically appears at the bottom of the list. If you don't want
this, simply remove it as you would remove any other line.
You may also choose to plot only over a certain date range, and
to cumulate the results - that is, to plot each one using the
previous one as a baseline, so the top line gives a sum of all
to cumulate the results, that is, to plot each one using the
previous one as a baseline so the top line gives a sum of all
the data sets. It's easier to try than to explain :-)
Once a data set is in the list, one can also perform certain
actions on it. For example, one can edit the
Once a data set is in the list, you can also perform certain
actions on it. For example, you can edit the
data set's parameters (name, frequency etc.) if it's one you
created or if you are an administrator.
Once you are happy, click Chart This List to see the chart.
Once you are happy, click :guilabel:`Chart This List` to see the chart.
.. _charts-new-series:
@@ -107,13 +108,13 @@ Creating New Data Sets
----------------------
You may also create new data sets of your own. To do this,
click the "create a new data set" link on the Create Chart page.
This takes you to a search-like interface where you can define
the search that Bugzilla will plot. At the bottom of the page,
you choose the category, sub-category and name of your new
click the :guilabel:`create a new data set` link on the
:guilabel:`Create Chart` page. This takes you to a search-like interface
where you can define the search that Bugzilla will plot. At the bottom of the
page, you choose the category, sub-category and name of your new
data set.
If you have sufficient permissions, you can make the data set public,
and reduce the frequency of data collection to less than the default
seven days.
of seven days.

10
mozilla/webtools/bugzilla/docs/en/rst/using/tips.rst
View File

@@ -13,7 +13,7 @@ Bugzilla comments are plain text - so typing <U> will
produce less-than, U, greater-than rather than underlined text.
However, Bugzilla will automatically make hyperlinks out of certain
sorts of text in comments. For example, the text
"http://www.bugzilla.org" will be turned into a link:
``http://www.bugzilla.org`` will be turned into a link:
`<http://www.bugzilla.org>`_.
Other strings which get linkified in the obvious manner are:
@@ -47,11 +47,11 @@ Comments
========
If you are changing the fields on a bug, only comment if
either you have something pertinent to say, or Bugzilla requires it.
Otherwise, you may spam people unnecessarily with bug mail.
either you have something pertinent to say or Bugzilla requires it.
Otherwise, you may spam people unnecessarily with bugmail.
To take an example: a user can set up their account to filter out messages
where someone just adds themselves to the CC field of a bug
(which happens a lot.) If you come along, add yourself to the CC field,
(which happens a lot). If you come along, add yourself to the CC field,
and add a comment saying "Adding self to CC", then that person
gets a pointless piece of mail they would otherwise have avoided.
@@ -74,7 +74,7 @@ have more styling than plain text. For example, you may use Markdown for
making a part of your comment look italic or bold in the generated HTML.
Bugzilla supports most of the structures defined by
`standard Markdown <http://daringfireball.net/projects/markdown/basics>`_,
but does NOT support inline images and inline HTML.
but does **not** support inline images and inline HTML.
Additionally, three Github Flavored Markdown features are supported.

95
mozilla/webtools/bugzilla/docs/en/rst/using/understanding.rst
View File

@@ -29,19 +29,19 @@ installation of Bugzilla.
having one or more Components in it.
*Version:*
The "Version" field is usually used for versions of a product which
have been released, and is set to indicate which versions of a
Component have the particular problem the bug report is
about.
The "Version" field usually contains the numbers or names of released
versions of the product. It is used to indicate the version(s) affected by
the bug report.
*Hardware (Platform and OS):*
These indicate the computing environment where the bug was
found.
*Importance (Priority and Severity):*
The bug assignee uses the Priority field to prioritize his or her bugs.
It's a good idea not to change this on other people's bugs. The default
values are P1 to P5.
The Priority field is used to prioritize bugs, either by the assignee,
or someone else with authority to direct their time such as a project
manager. It's a good idea not to change this on other people's bugs. The
default values are P1 to P5.
The Severity field indicates how severe the problem is - from blocker
("application unusable") to trivial ("minor cosmetic issue"). You
@@ -82,10 +82,10 @@ installation of Bugzilla.
on), or this bug stops other bugs being fixed (blocks), their
numbers are recorded here.
Clicking the ``Dependency tree`` link shows
Clicking the :guilabel:`Dependency tree` link shows
the dependency relationships of the bug as a tree structure.
You can change how much depth to show, and you can hide resolved bugs
from this page. You can also collaps/expand dependencies for
from this page. You can also collapse/expand dependencies for
each non-terminal bug on the tree view, using the [-]/[+] buttons that
appear before the summary.
@@ -96,13 +96,15 @@ installation of Bugzilla.
The date and time the bug was last changed.
*CC List:*
A list of people who get mail when the bug changes.
A list of people who get mail when the bug changes, in addition to the
Reporter, Assignee and QA Contact (if enabled).
*Ignore Bug Mail:*
Set this if you want never to get bug mail from this bug again.
Set this if you want never to get bugmail from this bug again. See also
:ref:`emailpreferences`.
*\*See Also:*
Bugs, in this Bugzilla or other Bugzillas or bug trackers, which are
Bugs, in this Bugzilla, other Bugzillas, or other bug trackers, that are
related to this one.
*Flags:*
@@ -113,9 +115,9 @@ installation of Bugzilla.
*\*Time Tracking:*
This form can be used for time tracking.
To use this feature, you have to be blessed group membership
specified by the ``timetrackinggroup`` parameter. See :ref:`time-tracking`
for more information.
To use this feature, you have to be a member of the group
specified by the :param:`timetrackinggroup` parameter. See
:ref:`time-tracking` for more information.
Orig. Est.:
This field shows the original estimated time.
@@ -139,7 +141,7 @@ installation of Bugzilla.
This field shows the deadline for this bug.
*Attachments:*
You can attach files (e.g. testcases or patches) to bugs. If there
You can attach files (e.g. test cases or patches) to bugs. If there
are any attachments, they are listed in this section. See
:ref:`attachments` for more information.
@@ -157,9 +159,25 @@ either ``+`` or ``-``. The meaning of these symbols depends on the name of
the flag itself, but contextually they could mean pass/fail,
accept/reject, approved/denied, or even a simple yes/no. If your site
allows requestable flags, then users may set a flag to ``?`` as a
request to another user that they look at the bug/attachment, and set
request to another user that they look at the bug/attachment and set
the flag to its correct status.
A set flag appears in bug reports and on "edit attachment" pages with the
abbreviated username of the user who set the flag prepended to the
flag name. For example, if Jack sets a "review" flag to ``+``, it appears
as :guilabel:`Jack: review [ + ]`.
A requested flag appears with the user who requested the flag prepended
to the flag name and the user who has been requested to set the flag
appended to the flag name within parentheses. For example, if Jack
asks Jill for review, it appears as :guilabel:`Jack: review [ ? ] (Jill)`.
You can browse through open requests made of you and by you by selecting
:guilabel:`My Requests` from the footer. You can also look at open requests
limited by other requesters, requestees, products, components, and flag names.
Note that you can use '-' for requestee to specify flags with no requestee
set.
.. _flags-simpleexample:
A Simple Example
@@ -170,22 +188,19 @@ A developer might want to ask their manager,
They might want to do this for a *lot* of bugs,
so they decide to streamline the process. So:
#. The Bugzilla administrator creates a flag type called
``blocking2.0`` that shows up on all bugs in
your product.
It shows up on the :guilabel:`Show Bug` screen
as the text ``blocking2.0`` with a drop-down box next
to it. The drop-down box contains four values: an empty space,
``?``, ``-``, and ``+``.
#. The Bugzilla administrator creates a flag type called blocking2.0 for bugs
in your product. It shows up on the :guilabel:`Show Bug` screen as the text
:guilabel:`blocking2.0` with a drop-down box next to it. The drop-down box
contains four values: an empty space, ``?``, ``-``, and ``+``.
#. The developer sets the flag to ``?``.
#. The manager sees the ``blocking2.0``
#. The manager sees the :guilabel:`blocking2.0`
flag with a ``?`` value.
#. If the manager thinks the feature should go into the product
before version 2.0 can be released, he sets the flag to
``+``. Otherwise, he sets it to ``-``.
before version 2.0 can be released, they set the flag to
``+``. Otherwise, they set it to ``-``.
#. Now, every Bugzilla user who looks at the bug knows whether or
not the bug needs to be fixed before release of version 2.0.
@@ -217,22 +232,22 @@ Flags can have four values:
Flag Requests
-------------
If a flag has been defined as 'requestable', and a user has enough privileges
to request it (see below), the user can set the flag's status to ``?``.
This status indicates that someone (a.k.a. "the requester") is asking
If a flag has been defined as :guilabel:`requestable`, and a user has enough
privileges to request it (see below), the user can set the flag's status to
``?``. This status indicates that someone (a.k.a. "the requester") is asking
someone else to set the flag to either ``+`` or ``-``.
If a flag has been defined as 'specifically requestable',
If a flag has been defined as :guilabel:`specifically requestable`,
a text box will appear next to the flag into which the requester may
enter a Bugzilla username. That named person (a.k.a. "the requestee")
will receive an email notifying them of the request, and pointing them
to the bug/attachment in question.
If a flag has *not* been defined as 'specifically requestable',
then no such text-box will appear. A request to set this flag cannot be made
of any specific individual, but must be asked "to the wind".
A requester may "ask the wind" on any flag simply by leaving the text-box
blank.
If a flag has *not* been defined as :guilabel:`specifically requestable`,
then no such text box will appear. A request to set this flag cannot be made
of any specific individual; these requests are open for anyone to answer. In
Bugzilla this is known as "asking the wind". A requester may ask the wind on
any flag simply by leaving the text box blank.
.. _flag-types:
@@ -247,13 +262,13 @@ Attachment flags are used to ask a question about a specific
attachment on a bug.
Many Bugzilla installations use this to
request that one developer ``review`` another
request that one developer review another
developer's code before they check it in. They attach the code to
a bug report, and then set a flag on that attachment called
``review`` to
``review? reviewer@example.com``.
:guilabel:`review` to
:guilabel:`review? reviewer@example.com`.
reviewer\@example.com is then notified by email that
he has to check out that attachment and approve it or deny it.
they have to check out that attachment and approve it or deny it.
For a Bugzilla user, attachment flags show up in three places: