From 317a88ea11f43acc511d386c65f57bbc57a93c05 Mon Sep 17 00:00:00 2001 From: "gerv%gerv.net" <> Date: Mon, 8 Mar 2004 07:27:30 +0000 Subject: Bug 170213 - make static HTML files into page.cgi pages. This does votehelp.html (-> id=voting.html), bug_status.html (-> id=fields.html) and bugwritinghelp.html (-> id=bug-writing.html). Patch by gerv; r=kiko, a=justdave. --- template/en/default/bug/create/create.html.tmpl | 5 +- .../en/default/bug/create/user-message.html.tmpl | 3 +- template/en/default/bug/edit.html.tmpl | 12 +- template/en/default/bug/knob.html.tmpl | 6 +- .../en/default/bug/votes/list-for-user.html.tmpl | 2 +- template/en/default/list/edit-multiple.html.tmpl | 10 +- template/en/default/pages/bug-writing.html.tmpl | 390 +++++++++++++++++++++ template/en/default/pages/fields.html.tmpl | 265 ++++++++++++++ template/en/default/pages/voting.html.tmpl | 65 ++++ 9 files changed, 741 insertions(+), 17 deletions(-) create mode 100644 template/en/default/pages/bug-writing.html.tmpl create mode 100644 template/en/default/pages/fields.html.tmpl create mode 100644 template/en/default/pages/voting.html.tmpl (limited to 'template/en/default') diff --git a/template/en/default/bug/create/create.html.tmpl b/template/en/default/bug/create/create.html.tmpl index 700994130..7156d052a 100644 --- a/template/en/default/bug/create/create.html.tmpl +++ b/template/en/default/bug/create/create.html.tmpl @@ -176,7 +176,7 @@ function set_assign_to() { - Assign To: + Assign To: @@ -333,7 +333,8 @@ function set_assign_to() { [% IF sel.description %] - [% sel.description %]: + + [% sel.description %]: [% END %] diff --git a/template/en/default/bug/create/user-message.html.tmpl b/template/en/default/bug/create/user-message.html.tmpl index 7a3678853..dbbd114e4 100644 --- a/template/en/default/bug/create/user-message.html.tmpl +++ b/template/en/default/bug/create/user-message.html.tmpl @@ -30,7 +30,8 @@ [% PROCESS global/variables.none.tmpl %] -Before reporting [% terms.abug %], please read the +Before reporting [% terms.abug %], please read the + [% terms.bug %] writing guidelines, please look at the list of most frequently reported [% terms.bugs %], and please search for the [% terms.bug %]. diff --git a/template/en/default/bug/edit.html.tmpl b/template/en/default/bug/edit.html.tmpl index f24dce62f..ef6b551fa 100644 --- a/template/en/default/bug/edit.html.tmpl +++ b/template/en/default/bug/edit.html.tmpl @@ -205,14 +205,14 @@ - Status: + Status: [% bug.bug_status FILTER html %]   - Priority: + Priority: [% PROCESS select selname => "priority" accesskey => "i" %] @@ -220,7 +220,7 @@ - Resolution: + Resolution: @@ -232,7 +232,7 @@   - Severity: + Severity: [% PROCESS select selname = "bug_severity" accesskey => "e" %] @@ -241,7 +241,7 @@ - Assigned To: + Assigned To: [% bug.assigned_to.identity FILTER html %] @@ -428,7 +428,7 @@
- Votes: + Votes: [% bug.votes %]    diff --git a/template/en/default/bug/knob.html.tmpl b/template/en/default/bug/knob.html.tmpl index 1e922c112..f8f60c354 100644 --- a/template/en/default/bug/knob.html.tmpl +++ b/template/en/default/bug/knob.html.tmpl @@ -59,7 +59,8 @@ [% END %] - Resolve [% terms.bug %], changing resolution to + Resolve [% terms.bug %], changing + resolution to - Reassign [% terms.bug %] to + Reassign + [% terms.bug %] to Help with voting. + Help with voting.

[% PROCESS global/footer.html.tmpl %] diff --git a/template/en/default/list/edit-multiple.html.tmpl b/template/en/default/list/edit-multiple.html.tmpl index e35f66584..1ea9b6dd9 100644 --- a/template/en/default/list/edit-multiple.html.tmpl +++ b/template/en/default/list/edit-multiple.html.tmpl @@ -70,7 +70,7 @@
@@ -80,7 +80,7 @@ @@ -99,7 +99,7 @@ @@ -266,7 +266,7 @@ [% knum = knum + 1 %] - + # Gervase Markham + # Claudius Gayle + # Peter Mock + # Chris Pratt + # Tom Schutter + # Chris Yeh + #%] + +[% PROCESS global/variables.none.tmpl %] +[% INCLUDE global/header.html.tmpl title = "$terms.Bug Writing Guidelines" %] + +

Why You Should Read This

+ +
+

Simply put, the more effectively you report a [% terms.bug %], the more + likely an + engineer will actually fix it.

+ +

These guidelines are a general tutorial to teach novice and + intermediate [% terms.bug %] reporters how to compose effective + [% terms.bug %] reports. Not + every sentence may precisely apply to your software project.

+
+ +

How to Write a Useful [% terms.Bug %] Report

+ +
+

Useful [% terms.bug %] reports are ones that get [% terms.bugs %] fixed. + A useful [% terms.bug %] report normally has two qualities:

+ +
    +
  1. Reproducible. If an engineer can't see the [% terms.bug %] + herself to prove that it exists, she'll probably stamp your [% terms.bug %] + report "WORKSFORME" or "INVALID" and move on to the next [% terms.bug %]. + Every detail you can provide helps.
    +
    +
  2. + +
  3. Specific. The quicker the engineer can isolate the + [% terms.bug %] to a specific area, the more likely she'll expediently + fix it. (If a programmer or tester has to decypher a [% terms.bug %], + they may spend more time cursing the submitter than solving the + problem.)
    +
    + [ Tell Me More ]
  4. +
+ +

Let's say the application you're testing is a web browser. You crash + at foo.com, and want to write up a [% terms.bug %] report:

+ +
+

BAD: "My browser crashed. I think I was on www.foo.com. I + play golf with Bill Gates, so you better fix this problem, or I'll + report you to him. By the way, your Back icon looks like a squashed + rodent. UGGGLY. And my grandmother's home page is all messed up in your + browser. Thx 4 UR help."

+ +

GOOD: "I crashed each time I went to www.foo.com, using the + 2002-02-25 build on a Windows 2000 system. I also rebooted into Linux, + and reproduced this problem using the 2002-02-24 Linux build.

+ +

It again crashed each time upon drawing the Foo banner at the top of + the page. I broke apart the page, and discovered that the following + image link will crash the application reproducibly, unless you remove + the "border=0" attribute:

+ +

<IMG SRC="http://www.foo.com/images/topics/topicfoos.gif" + width="34" height="44" border="0" alt="News">

+
+
+ +

How to Enter your Useful [% terms.Bug %] Report + into [% terms.Bugzilla %]:

+ +
+

Before you enter your [% terms.bug %], use [% terms.Bugzilla %]'s + search page to determine whether the defect + you've discovered is a known, already-reported [% terms.bug %]. If + your [% terms.bug %] is the 37th duplicate of a known issue, + you're more likely to annoy the engineer. (Annoyed engineers fix fewer + [% terms.bugs %].)

+ +

Next, be sure to reproduce your [% terms.bug %] using a recent build. + Engineers tend to be most interested in problems affecting the code base + that they're actively working on. After all, the [% terms.bug %] you're + reporting may already be fixed.

+ +

If you've discovered a new [% terms.bug %] using a current build, report + it in [% terms.Bugzilla %]:

+ +
    +
  1. From your [% terms.Bugzilla %] main page, choose + "Enter a new [% terms.bug %]".
  2. + +
  3. Select the product that you've found a [% terms.bug %] in.
  4. + +
  5. Enter your e-mail address, password, and press the "Login" button. + (If you don't yet have a password, leave the password field empty, and + press the "E-mail me a password" button instead. You'll quickly receive + an e-mail message with your password.)
  6. +
+ +

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

+ +

Where did you find the [% terms.bug %]?

+ +
+

Product: In which product did you find the [% terms.bug %]?
+ You just specified this on the last page, so you can't edit it + here.

+ +

Version: In which product version did you find + the [% terms.bug %]?
+ (If applicable)

+ +

Component: In which component does the [% terms.bug %] + exist?
+ [% terms.Bugzilla %] requires that you select a component to enter + a [% terms.bug %]. (Not sure which to choose? Click on the Component link. + You'll see a description of each component, to help you make the best + choice.)

+ +

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

+
+ +

How important is the [% terms.bug %]?

+ +
+

Severity: How damaging is the [% terms.bug %]?
+ This item defaults to 'normal'. If you're not sure what severity your + [% terms.bug %] deserves, click on the Severity link. You'll see a + description of each severity rating.
+

+
+ +

Who will be following up on the [% terms.bug %]?

+ +
+

Assigned To: Which engineer should be responsible for fixing + this [% terms.bug %]?
+ [% terms.Bugzilla %] will automatically assign the [% terms.bug %] to a + default engineer upon submitting a [% terms.bug %] report. If you'd prefer + to directly assign the [% terms.bug %] to someone else, enter their e-mail + address into this field. (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 + [% terms.bug %]?
+ List the full e-mail addresses of other individuals who should receive + an e-mail update upon every change to the [% terms.bug %] report. You can + enter as many e-mail addresses as you'd like, separated by spaces or + commas, as long as those people have [% terms.Bugzilla %] accounts.

+
+ +

What else can you tell the engineer about the [% terms.bug %]?

+ +
+

Summary: How would you describe the [% terms.bug %], in + approximately 60 or fewer characters?
+ A good summary should quickly and uniquely identify a [% terms.bug %] + report. Otherwise, an engineer cannot meaningfully identify your + [% terms.bug %] by its summary, and will often fail to pay attention to + your [% terms.bug %] report when skimming through a 10 + page [% terms.bug %] list.
+
+ A useful summary might be "PCMCIA install fails on Tosh Tecra + 780DVD w/ 3c589C". "Software fails" or "install + problem" would be examples of a bad summary.
+
+ [ Tell Me More ]
+
+ Description:
+ Please provide a detailed problem report in this field. Your + [% terms.bug %]'s recipients will most likely expect the following + information:

+ +
+

Overview Description: More detailed expansion of + summary.

+ +
+
+Drag-selecting any page crashes Mac builds in NSGetFactory
+
+
+ +

Steps to Reproduce: Minimized, easy-to-follow steps that + will trigger the [% terms.bug %]. Include any special setup steps.

+ +
+
+1) View any web page. (I used the default sample page,
+resource:/res/samples/test0.html)
+
+2) Drag-select the page. (Specifically, while holding down 
+the mouse button, drag the mouse pointer downwards from any 
+point in the browser's content region to the bottom of the 
+browser's content region.)                   
+
+
+ +

Actual Results: What the application did after performing + the above steps.

+ +
+
+The application crashed. Stack crawl appended below from MacsBug.
+
+
+ +

Expected Results: What the application should have done, + were the [% terms.bug %] not present.

+ +
+
+The window should scroll downwards. Scrolled content should be selected. 
+(Or, at least, the application should not crash.)
+
+
+ +

Build Date & Platform: Date and platform of the build + that you first encountered the [% terms.bug %] in.

+ +
+
+Build 2002-03-15 on Mac OS 9.0
+
+
+ +

Additional Builds and Platforms: Whether or not + the [% terms.bug %] takes place on other platforms (or browsers, + if applicable).

+ +
+
+- Also Occurs On        
+Mozilla (2002-03-15 build on Windows NT 4.0) 
+
+- Doesn't Occur On        
+Mozilla (2002-03-15 build on Red Hat Linux; feature not supported)        
+Internet Explorer 5.0 (shipping build on Windows NT 4.0)        
+Netscape Communicator 4.5 (shipping build on Mac OS 9.0)
+
+
+ +

Additional Information: Any other debugging information. + For crashing [% terms.bugs %]:

+ +
    +
  • Win32: if you receive a Dr. Watson error, please note + the type of the crash, and the module that the application crashed + in. (e.g. access violation in apprunner.exe)
  • + +
  • Mac OS: if you're running MacsBug, please provide the + results of a how and an sc:
  • +
+ +
+
+*** MACSBUG STACK CRAWL OF CRASH (Mac OS)
+Calling chain using A6/R1 links 
+Back chain  ISA  Caller 
+00000000    PPC  0BA85E74   
+03AEFD80    PPC  0B742248   
+03AEFD30    PPC  0B50FDDC  NSGetFactory+027FC
+PowerPC unmapped memory exception at 0B512BD0 NSGetFactory+055F0
+
+
+
+
+ +

You're done!
+
+ After double-checking your entries for any possible errors, press the + "Commit" button, and your [% terms.bug %] report will now be in + the [% terms.Bugzilla %] database.
+

+
+
+ +

More Information on Writing Good [% terms.Bugs %]

+ +
+

1. General Tips for a Useful [% terms.Bug %] + Report

+ +
+

Use an explicit structure, so your [% terms.bug %] reports are easy + to skim. [% terms.Bug %] report users often need immediate access to + specific sections of your [% terms.bug %]. If your [% terms.Bugzilla %] + installation supports the [% terms.Bugzilla %] Helper, use it.

+ +

Avoid cuteness if it costs clarity. Nobody will be laughing + at your funny [% terms.bug %] title at 3:00 AM when they can't remember how + to find your [% terms.bug %].

+ +

One [% terms.bug %] per report. Completely different people + typically fix, verify, and prioritize different [% terms.bugs %]. If you + mix a handful of [% terms.bugs %] into a single report, the right people + probably won't discover your [% terms.bugs %] in a timely fashion, or at + all. Certain [% terms.bugs %] are also more important than others. It's + impossible to prioritize a [% terms.bug %] report when + it contains four different issues, all of differing importance.

+ +

No [% terms.bug %] is too trivial to report. Unless you're + reading the source code, you can't see actual software [% terms.bugs %], + like a dangling pointer -- you'll see their visible manifestations, such + as the segfault when the application finally crashes. Severe software + problems can manifest themselves in superficially trivial ways. File them + anyway.
+

+
+ +

2. How and Why to Write Good [% terms.Bug %] + Summaries

+ +
+

You want to make a good first impression on the [% terms.bug %] + recipient. Just like a New York Times headline guides readers + towards a relevant article from dozens of choices, will + your [% terms.bug %] summary suggest that your [% terms.bug %] report is + worth reading from dozens or hundreds of choices?

+ +

Conversely, a vague [% terms.bug %] summary like install + problem forces anyone reviewing installation [% terms.bugs %] to waste + time opening up your [% terms.bug %] to determine whether it matters.

+ +

Your [% terms.bug %] will often be searched by its summary. Just + as you'd find web pages with Google by searching by keywords through + intuition, so will other people locate your [% terms.bugs %]. + Descriptive [% terms.bug %] summaries are + naturally keyword-rich, and easier to find.

+ +

For example, you'll find a [% terms.bug %] titled "Dragging icons + from List View to gnome-terminal doesn't paste path" if you search on + "List", "terminal", or "path". Those search keywords wouldn't have + found a [% terms.bug %] titled "Dragging icons doesn't paste".

+ +

Ask yourself, "Would someone understand my [% terms.bug %] from just + this summary?" If so, you've written a fine summary.

+ +

Don't write titles like these:

+ +
    +
  1. "Can't install" - Why can't you install? What happens when you + try to install?
  2. + +
  3. "Severe Performance Problems" - ...and they occur when you do + what?
  4. + +
  5. "back button does not work" - Ever? At all?
  6. +
+ +

Good [% terms.bug %] titles:

+ +
    +
  1. "1.0 upgrade installation fails if Mozilla M18 package present" - + Explains problem and the context.
  2. + +
  3. "RPM 4 installer crashes if launched on Red Hat 6.2 (RPM 3) + system" - Explains what happens, and the context.
  4. +
+
+
+ +[% INCLUDE global/footer.html.tmpl %] diff --git a/template/en/default/pages/fields.html.tmpl b/template/en/default/pages/fields.html.tmpl new file mode 100644 index 000000000..caec210b8 --- /dev/null +++ b/template/en/default/pages/fields.html.tmpl @@ -0,0 +1,265 @@ +[%# 1.0@bugzilla.org %] +[%# The contents of this file are subject to the Mozilla Public + # License Version 1.1 (the "License"); you may not use this file + # except in compliance with the License. You may obtain a copy of + # the License at http://www.mozilla.org/MPL/ + # + # Software distributed under the License is distributed on an "AS + # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or + # implied. See the License for the specific language governing + # rights and limitations under the License. + # + # The Original Code is the Bugzilla Bug Tracking System. + # + # The Initial Developer of the Original Code is Netscape Communications + # Corporation. Portions created by Netscape are + # Copyright (C) 1998 Netscape Communications Corporation. All + # Rights Reserved. + # + # Contributor(s): Terry Weissman + # Gervase Markham + #%] + +[% PROCESS global/variables.none.tmpl %] +[% INCLUDE global/header.html.tmpl title = "A $terms.Bug's Life Cycle" %] + +

+The status and resolution fields define and track the life +cycle of a [% terms.bug %]. +

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

STATUS

+
+

RESOLUTION

+
The status field indicates the general health of a + [% terms.bug %]. Only certain status transitions are allowed.The resolution field indicates what happened to this + [% terms.bug %].
+
+
UNCONFIRMED
+ +
This [% terms.bug %] has recently been added to the database. + Nobody has validated that this [% terms.bug %] is true. Users who have + the "canconfirm" permission set may confirm this [% terms.bug %], + changing its state to NEW. Or, it may be directly resolved and marked + RESOLVED.
+ +
NEW
+ +
This [% terms.bug %] has recently been added to the assignee's list + of [% terms.bugs %] and must be processed. [% terms.Bugs %] in this + state may be accepted, and become ASSIGNED, passed on to someone + else, and remain NEW, or resolved and marked RESOLVED. +
+ +
ASSIGNED
+ +
This [% terms.bug %] is not yet resolved, but is assigned to the + proper person. From here [% terms.bugs %] can be given to another + person and become NEW, or resolved and become RESOLVED. +
+ +
REOPENED
+ +
This [% terms.bug %] was once resolved, but the resolution was + deemed incorrect. For example, a WORKSFORME [% terms.bug %] is + REOPENED when more information shows up and the [% terms.bug %] + is now reproducible. From here [% terms.bugs %] are either marked + ASSIGNED or RESOLVED.
+
+
+
+
No resolution yet. All [% terms.bugs %] which are in one of + these "open" states have the resolution set to blank. All + other [% terms.bugs %] will be marked with one of the following + resolutions.
+
+
+
+
RESOLVED
+ +
A resolution has been taken, and it is awaiting verification by + QA. From here [% terms.bugs %] are either re-opened and become + REOPENED, are marked VERIFIED, or are closed for good + and marked CLOSED.
+ +
VERIFIED
+ +
QA has looked at the [% terms.bug %] and the resolution and + agrees that the appropriate resolution has been taken. [% terms.Bugs %] + remain in this state until the product they were reported against + actually ships, at which point they become CLOSED.
+ +
CLOSED
+ +
The [% terms.bug %] is considered dead, the resolution is correct. + Any zombie [% terms.bugs %] who choose to walk the earth again must + do so by becoming REOPENED.
+
+
+
+
FIXED
+ +
A fix for this [% terms.bug %] is checked into the tree and + tested.
+ +
INVALID
+ +
The problem described is not a [% terms.bug %]
+ +
WONTFIX
+ +
The problem described is a [% terms.bug %] which will never be + fixed.
+ +
DUPLICATE
+ +
The problem is a duplicate of an existing [% terms.bug %]. Marking + a [% terms.bug %] duplicate requires the [% terms.bug %]# of the + duplicating [% terms.bug %] and will at least put that [% terms.bug %] + number in the description field.
+ +
WORKSFORME
+ +
All attempts at reproducing this [% terms.bug %] were futile, + reading the code produces no clues as to why this behavior would occur. + If more information appears later, please re-assign + the [% terms.bug %], for now, file it.
+ +
MOVED
+ +
The problem was specific to a related product + whose [% terms.bugs %] are tracked in another [% terms.bug %] database. + The [% terms.bug %] has been moved to that database.
+
+
+ +

Severity

+This field describes the impact of a [% terms.bug %]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BlockerBlocks development and/or testing work
Criticalcrashes, loss of data, severe memory leak
Majormajor loss of function
Minorminor loss of function, or other problem where easy + workaround is present
Trivialcosmetic problem like misspelled words or misaligned + text
EnhancementRequest for enhancement
+ +

Priority

+This field describes the importance and order in which a [% terms.bug %] +should be fixed. This field is utilized by the +programmers/engineers to prioritize their work to be done. The +available priorities range from P1 (most important) to +P5 (least important.) + + +

Platform

+This is the hardware platform against which the [% terms.bug %] was +reported. Legal platforms include: + +
    +
  • All (happens on all platforms; cross-platform [% terms.bug %])
  • + +
  • Macintosh
  • + +
  • PC
  • + +
  • Sun
  • + +
  • HP
  • +
+Note: When searching, selecting the option "All" does not +select [% terms.bugs %] +assigned against any platform. It merely selects [% terms.bugs %] that are +marked as occurring on all platforms, i.e. are designated "All". + +

Operating System

+This is the operating system against which the [% terms.bug %] was +reported. Legal operating systems include: + +
    +
  • All (happens on all operating systems; cross-platform + [% terms.bug %])
  • + +
  • Windows 95
  • + +
  • Mac System 8.0
  • + +
  • Linux
  • +
+Sometimes the operating system implies the platform, but not +always. For example, Linux can run on PC and Macintosh and +others. + +

Assigned To

+ +

+This is the person in charge of resolving the [% terms.bug %]. Every time +this field changes, the status changes to NEW to make it +easy to see which new [% terms.bugs %] have appeared on a person's list.

+ +

+The default status for queries is set to NEW, ASSIGNED and +REOPENED. When searching for [% terms.bugs %] that have been resolved or +verified, remember to set the status field appropriately. +

+ +[% INCLUDE global/footer.html.tmpl %] diff --git a/template/en/default/pages/voting.html.tmpl b/template/en/default/pages/voting.html.tmpl new file mode 100644 index 000000000..2e555b1ce --- /dev/null +++ b/template/en/default/pages/voting.html.tmpl @@ -0,0 +1,65 @@ +[%# 1.0@bugzilla.org %] +[%# The contents of this file are subject to the Mozilla Public + # License Version 1.1 (the "License"); you may not use this file + # except in compliance with the License. You may obtain a copy of + # the License at http://www.mozilla.org/MPL/ + # + # Software distributed under the License is distributed on an "AS + # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or + # implied. See the License for the specific language governing + # rights and limitations under the License. + # + # The Original Code is the Bugzilla Bug Tracking System. + # + # The Initial Developer of the Original Code is Netscape Communications + # Corporation. Portions created by Netscape are + # Copyright (C) 1998 Netscape Communications Corporation. All + # Rights Reserved. + # + # Contributor(s): Terry Weissman + # Gervase Markham + #%] + +[% PROCESS global/variables.none.tmpl %] +[% INCLUDE global/header.html.tmpl title = "Voting" %] + +

[% terms.Bugzilla %] has a "voting" feature. Each product allows users to +have a certain number of votes. (Some products may not allow any, which means +you can't vote on things in that product at all.) With your vote, you indicate +which [% terms.bugs %] you think are the most important to be fixed.

+ +

Depending on how the administrator has configured the relevant product, +you may be able to vote for the same [% terms.bug %] more than one time. But +remember, you only have so many votes to use in total! So, you can either vote +a little for many [% terms.bugs %], or vote a lot for a few [% terms.bugs %]. +

+ +

To look at votes:

+ +
    +
  • Go to the query page. Do a normal query, but enter 1 in the "At least + ___ votes" field. This will show you items that match your query that + have at least one vote.
  • +
+ +

To vote for a [% terms.bug %]:

+ +
    +
  • Bring up the [% terms.bug %] in question.
  • + +
  • Click on the "Vote for this [% terms.bug %]" link that appears just + above the "Additional Comments" field. (If no such link appears, then voting + may not be allowed in this [% terms.bug %]'s product.)
  • + +
  • Indicate how many votes you want to give this [% terms.bug %]. This page + also displays how many votes you've given to other [% terms.bugs %], so you + may rebalance your votes as necessary.
  • +
+ +

You will automatically get email notifying you of any changes that occur +on [% terms.bugs %] you vote for.

+ +

You may review your votes at any time by clicking on the "My Votes" link in the page footer.

+ +[% INCLUDE global/footer.html.tmpl %] -- cgit v1.2.3-24-g4f1b