From 57584dc4744fea59833ef355f7513690d246c70f Mon Sep 17 00:00:00 2001 From: David Lawrence Date: Tue, 4 Oct 2011 18:25:23 -0400 Subject: more porting work --- .../template/en/default/pages/etiquette.html.tmpl | 42 +++++++++++----------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'extensions/BMO/template/en/default/pages/etiquette.html.tmpl') diff --git a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl index 8bccaea9d..281057eeb 100644 --- a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl +++ b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl @@ -21,15 +21,15 @@ #%] [% INCLUDE global/header.html.tmpl - title = "$terms.Bugzilla Etiquette" + title = "Bugzilla Etiquette" style = "li { margin: 5px } .heading { font-weight: bold }" %]

There's a number of faux pas you can commit when using - [% terms.Bugzilla %]. At the very + Bugzilla. At the very least, these will make Mozilla contributors upset at you; if committed enough times they will cause those contributors to demand the disabling of your - [% terms.Bugzilla %] account. So, ignore this advice at your peril. + Bugzilla account. So, ignore this advice at your peril.

@@ -47,14 +47,14 @@

  • No pointless comments. Unless you have something constructive and helpful to say, do not add a - comment to a [% terms.bug %]. In [% terms.bugs %] where there is a heated debate going on, you + comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, - then the [% terms.bug %] owner is aware of all the issues, and will make a judgement - as to what to do. If you agree the [% terms.bug %] should be fixed, vote for it. + then the bug owner is aware of all the issues, and will make a judgement + as to what to do. If you agree the bug should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build. - Constructive and helpful thoughts unrelated to the topic of the [% terms.bug %] + Constructive and helpful thoughts unrelated to the topic of the bug should go in the appropriate newsgroup.
    • @@ -63,8 +63,8 @@ No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but the only person who has any - obligation to fix the [% terms.bugs %] you want fixed is you. Therefore, you - should not act as if you expect someone to fix a [% terms.bug %] by a particular date + obligation to fix the bugs you want fixed is you. Therefore, you + should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact and interest in your suggestions. @@ -80,17 +80,17 @@ things, not people. Examples of things include: interfaces, algorithms, and schedules. Examples of people include: developers, designers and users. Attacking a person may result in you being banned - from [% terms.Bugzilla %]. + from Bugzilla.
  • No private email. - Unless the [% terms.bug %] owner or another respected project contributor has asked you + Unless the bug owner or another respected project contributor has asked you to email them with specific information, please place all information - relating to [% terms.bugs %] - in the [% terms.bug %] itself. Do not send them by private email; no-one else can read + relating to bugs + in the bug itself. Do not send them by private email; no-one else can read them if you do that, and they'll probably just get ignored. If a file - is too big for [% terms.Bugzilla %], add a comment giving the file size and contents + is too big for Bugzilla, add a comment giving the file size and contents and ask what to do.
    • @@ -99,19 +99,19 @@
    1. - No messing with other people's [% terms.bugs %]. - Unless you are the [% terms.bug %] assignee, or have some say over the use of their + No messing with other people's bugs. + Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, - do not change the fields of [% terms.bugs %] you do not own - add a comment + do not change the fields of bugs you do not own - add a comment instead, suggesting the change.
    2. No whining about decisions. - If a respected project contributor has marked a [% terms.bug %] as INVALID, then it is + If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an - INVALID or WONTFIX [% terms.bug %] should be reopened. + INVALID or WONTFIX bug should be reopened.
    @@ -129,7 +129,7 @@

    If you see someone not following these rules, the first step is, as an exception to guideline 1.4, to make them aware of this document by private mail. - Flaming people publically in [% terms.bugs %] violates guidelines 1.1 and 1.3. In the case of + Flaming people publically in bugs violates guidelines 1.1 and 1.3. In the case of persistent offending you should report the matter to Gerv.

    @@ -141,7 +141,7 @@

    Other useful documents: - The [% terms.Bug %] Writing Guidelines. + The Bug Writing Guidelines.

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