diff options
Diffstat (limited to 'extensions/BMO/template/en/default/pages/etiquette.html.tmpl')
| -rw-r--r-- | extensions/BMO/template/en/default/pages/etiquette.html.tmpl | 143 |
1 files changed, 87 insertions, 56 deletions
diff --git a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl index 282c0c2ed..ad913bd9e 100644 --- a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl +++ b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl @@ -18,98 +18,129 @@ # # Contributor(s): Stefan Seifert <nine@detonation.org> # Gervase Markham <gerv@gerv.net> - # Emma Humphries <ech@emmah.net> #%] [% PROCESS global/header.html.tmpl title = "Bugzilla Etiquette" style = "li { margin: 5px } .heading { font-weight: bold }" %] -<h2>Bugzilla Etiquette</h2> +<p> + There's a number of <i lang="fr">faux pas</i> you can commit when using + [%+ terms.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. +</p> <p> - It is our intention that [% terms.Bugzilla %] remains a useful tool for reporting - and commenting on [% terms.bugs %], feature-requests, and tasks for the Mozilla community. - In order to keep [%+ terms.Bugzilla %] a useful, inclusive place for this work, we have - guidelines for using this site which, by using this site, you agree to follow. - In addition, your participation on this site is also subject to - <a href="https://www.mozilla.org/about/governance/policies/participation">Mozilla's participation guidelines</a>. - Violations of [% terms.Bugzilla %] etiquette or Mozilla's participation guidelines will be considered - as grounds for suspending your privileges on this site, or suspend your account altogether. + <a href="https://www.mozilla.org/en-US/about/governance/policies/participation"> + Please also read the Mozilla Community Participation Guidelines</a> </p> -<h3>Commenting</h3> +<p> + That said, Mozilla developers are generally a friendly bunch, and will be + friendly towards you as long as you follow these guidelines. +</p> -<ol> - <li> - <span class="heading">No abusing people</span>. - Constant and intense critique is one of the reasons we build great products. - It's harder to fall into group-think if there is always a healthy amount of - dissent. We want to encourage vibrant debate inside of the Mozilla - community, we want you to disagree with us, and we want you to effectively - argue your case. However, we require that in the process, you criticize - <i>things</i>, not <i>people</i>. Examples of things include: interfaces, - algorithms, and schedules. Examples of people include: developers, - designers and users. <b>Attacking or encouraging attacks on a person - may result in you being banned from [% terms.Bugzilla %]</b>. - </li> +<h3>1. Commenting</h3> + +<p> + This is the most important section. +</p> +<ol> <li> - <span class="heading">No obligation</span>. - "Open Source" is not the same as "the developers must do my bidding." - Everyone here wants to help, but no one else has any <i>obligation</i> to fix - the [% terms.bugs %] you want fixed. Therefore, you should not act as if you - expect someone to fix a [% terms.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. + <span class="heading">No pointless comments</span>. + 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 + 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. + 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 %] + should go in the appropriate + <a href="http://www.mozilla.org/about/forums/">newsgroup</a>. </li> <li> - <span class="heading">No spam</span>. - Posting comment spam will lead to the supsension of your account. + <span class="heading">No obligation</span>. + "Open Source" is not the same as "the developers must do my bidding." + Everyone here wants to help, but no one else has any <i>obligation</i> to fix + the [% terms.bugs %] you want fixed. Therefore, you should not act as if you + expect someone to fix a [% terms.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. </li> <li> - <span class="heading">No pointless comments</span>. - Limit comments on a [% terms.bug %] to information which will help with - resolving it. Unless requested, 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. + <span class="heading">No abusing people</span>. + Constant and intense critique is one of the reasons we build great products. + It's harder to fall into group-think if there is always a healthy amount of + dissent. We want to encourage vibrant debate inside of the Mozilla + community, we want you to disagree with us, and we want you to effectively + argue your case. However, we require that in the process, you attack + <i>things</i>, not <i>people</i>. Examples of things include: interfaces, + algorithms, and schedules. Examples of people include: developers, + designers and users. <b>Attacking a person may result in you being banned + from [% terms.Bugzilla %].</b> </li> <li> - <span class="heading">No private email</span>. - Do not send comments to [% terms.bugs %] by private email; no-one else can read - them if you do that, and they'll be missed and/or ignored. If an attachment - is too big for [% terms.Bugzilla %], add a comment giving the file size and contents - and ask what to do. + <span class="heading">No private email</span>. + Unless the [% terms.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 + 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 + and ask what to do. </li> </ol> -<h3>Changing Fields</h3> +<h3>2. Changing Fields</h3> <ol> <li> - <span class="heading">No messing with other people's [% terms.bugs %]</span>. - Unless you are the [% terms.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 - instead, suggesting the change. + <span class="heading">No messing with other people's [% terms.bugs %]</span>. + Unless you are the [% terms.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 + instead, suggesting the change. </li> <li> - <span class="heading">No whining about decisions</span>. - If another project contributor has marked a [% terms.bug %] as INVALID, then it is - invalid. Filing another duplicate of it does not change this. Unless - you have further evidence to support this, do not post a comment arguing that an - INVALID or WONTFIX [% terms.bug %] should be reopened. + <span class="heading">No whining about decisions</span>. + If a respected project contributor has marked a [% terms.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. </li> </ol> +<h3>3. Applicability</h3> + +<ol> + <li> + Some of these rules may not apply to you. If they do not, you will know + exactly which ones do not, and why they do not apply. If you are not + sure, then they definitely all apply to you. + </li> +</ol> + +<p> + 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 <em>private</em> mail. + Flaming people publically in [% terms.bugs %] violates guidelines 1.1 and 1.3. In the case of + persistent offending you should ping an administrator on Mozilla IRC in channel #bmo and ask them + to look into it. +</p> + <p> - If you observe, or are the subject of behavior in violation of these guidelines, please tag - the [% terms.bug %] or comment following our <a href="page.cgi?id=anti-abuse.html">anti-abuse policy</a>. + This entire document can be summed up in one sentence: + do unto others as you would have them do unto you. </p> <p> |