summaryrefslogtreecommitdiffstats
path: root/extensions/BMO/template/en/default/pages/etiquette.html.tmpl
blob: 78cc0bad7396d54243903949970c0f20ae3add06 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
<!-- 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): Stefan Seifert <nine@detonation.org>
  #                 Gervase Markham <gerv@gerv.net>
  #%]

[% PROCESS global/header.html.tmpl 
   title = "Bugzilla Etiquette" 
   style = "li { margin: 5px } .heading { font-weight: bold }" %]

<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>
  That said, Mozilla developers are generally a friendly bunch, and will be
  friendly towards you as long as you follow these guidelines.
</p>

<h3>1. Commenting</h3>

<p>
  This is the most important section.
</p>

<ol>
  <li>
  <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 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 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>.
  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>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.
  </li>

  <li>
  <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>
  This entire document can be summed up in one sentence: 
  do unto others as you would have them do unto you.
</p>

<p>
  Other useful documents:
  <a href="page.cgi?id=bug-writing.html">The [% terms.Bug %] Writing Guidelines</a>.
</p>

[% INCLUDE global/footer.html.tmpl %]