From 1cb4e01a265c94284a08b8df6555b6932fc37b73 Mon Sep 17 00:00:00 2001 From: Emma Humphries ☕️ +needinfo me Date: Wed, 1 Feb 2017 20:57:59 +0000 Subject: Bug 1321592 - Update Bugzilla Etiquette and add Abuse Policy --- .../template/en/default/account/create.html.tmpl | 102 +++++++----- .../template/en/default/pages/etiquette.html.tmpl | 183 ++++++++++++--------- 2 files changed, 169 insertions(+), 116 deletions(-) diff --git a/extensions/BMO/template/en/default/account/create.html.tmpl b/extensions/BMO/template/en/default/account/create.html.tmpl index 3a4dd8a70..0c742c7f1 100644 --- a/extensions/BMO/template/en/default/account/create.html.tmpl +++ b/extensions/BMO/template/en/default/account/create.html.tmpl @@ -17,11 +17,12 @@ # # Contributor(s): Gervase Markham # Byron Jones + # Emma Humphries #%] [%# INTERFACE # none - # + # # Param("maintainer") is used to display the maintainer's email. # Param("emailsuffix") is used to pre-fill the email field. #%] @@ -40,11 +41,12 @@ @@ -110,52 +119,68 @@ function onSubmit() {

I want to help

-

- Great! There are three things to know and do: -

-
    -
  1. - Please consider reading our - [% terms.bug %]-writing guidelines. -
  2. -
  3. - [% terms.Bugzilla %] is a public place. Your comments and other activities - on [% terms.bugs %] will generally be publicly visible, and your email address will be - accessible through public APIs and will be visible to all logged-in users - of [% terms.Bugzilla %]. Some people use an - alternative email address for this reason. - See Mozilla's Websites, Communications & Cookies Privacy Notice for - more information on our privacy policies. -
  4. -
  5. - When using [% terms.Bugzilla %] to submit patches, comments, code, and any other content, - you agree to our policies on open source licensing and content submission. See Mozilla’s - Websites - and Communications Terms of Use for more information. -
  6. -
  7. - Please give us an email address you want to use. Once we confirm that it works, - you'll be asked to set a password and then you can start filing [% terms.bugs %] and helping fix them. -
  8. -
+

+ Great! There are a few things to know and do: +

+
    +
  1. + Please read our + [% terms.Bug %] Writing Guidelines. +
  2. +
  3. + [% terms.Bugzilla %] is a public place. Your comments and other activities + on [% terms.bugs %] will generally be publicly visible, and your email address will be + accessible through public APIs and will be visible to all logged-in users + of [% terms.Bugzilla %]. Some people use an + alternative email address for this reason. + See Mozilla's Websites, Communications & Cookies Privacy Notice for + more information on our privacy policies. +
  4. +
  5. + When using [% terms.Bugzilla %] to submit patches, comments, code, and any other content, + you agree to our policies on open source licensing and content submission. See Mozilla’s + Websites + and Communications Terms of Use for more information. +
  6. +
  7. + You understand that your conduct on this site is subject to both [% terms.Bugzilla %] Etiquette, + and the Mozilla Community Participation Guidelines. + By creating an account, you agree to abide by them. +
  8. +
  9. + Please give us an email address you want to use. Once we confirm that it works, + you'll be asked to set a password and then you can start filing [% terms.bugs %] and helping fix them. +
  10. +

Create an account

- - +
+ + [% Param('emailsuffix') FILTER html %] + + + + + + - -
Email Address: - [% Param('emailsuffix') FILTER html %]
+ I have read [% terms.Bugzilla %] Etiquette + and the Mozilla Community Participation Guidelines + and agree to abide by them. + +
-
+ + +
[% Hook.process('additional_methods') %] @@ -186,4 +211,3 @@ function onSubmit() { [% END %] - diff --git a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl index ad913bd9e..87dc6981c 100644 --- a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl +++ b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl @@ -18,133 +18,162 @@ # # Contributor(s): Stefan Seifert # Gervase Markham + # Emma Humphries #%] [% PROCESS global/header.html.tmpl title = "Bugzilla Etiquette" style = "li { margin: 5px } .heading { font-weight: bold }" %] +

Bugzilla Etiquette

+

- There's a number of faux pas 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. + It is our intention that [% terms.Bugzilla %] remain a useful tool for reporting + and commenting on [% terms.bugs %], feature requests, and tasks for the Mozilla community. + No single contributor's work outweighs the importance of civility and professionalism + in the Mozilla community.

- - Please also read the Mozilla Community Participation Guidelines + In order to keep [%+ terms.Bugzilla %] a useful, inclusive place we have + guidelines which, by using this site, you agree to follow. + In addition, your participation on this site is also subject to the + Mozilla Community Participation Guidelines.

- That said, Mozilla developers are generally a friendly bunch, and will be - friendly towards you as long as you follow these guidelines. + Violations of [% terms.Bugzilla %] Etiquette or the Mozilla Community Participation + Guidelines are grounds for curtailing your privileges on this site, or suspending + your account altogether.

-

1. Commenting

+

Guidelines

-

- This is the most important section. -

+

Commenting

  1. - 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 - 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 - newsgroup. + No abusing people. + 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 + things, not people. Examples of things include: interfaces, + algorithms, and schedules. Examples of people include: developers, + designers, and users. Attacking or encouraging attacks on a person + may result in you being banned from [% terms.Bugzilla %].
  2. - No obligation. - "Open Source" is not the same as "the developers must do my bidding." - Everyone here wants to help, but no one else has any obligation 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. + No obligation. + "Open Source" is not the same as "the developers must do my bidding." + Everyone here wants to help, but no one else has any obligation 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 of and interest in your suggestions.
  3. - No abusing people. - 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 - 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 %]. + No spam. + Posting comment spam will lead to the suspension of your account.
  4. - No private email. - 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. + No pointless comments. + 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. Constructive conversations unrelated to the topic of + the [% terms.bug %] should go in the appropriate + discussion forum. +
  5. + +
  6. + No private email. + Do not send comments on [% terms.bugs %] by private email to users; + 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.
-

2. Changing Fields

+

Changing Fields

  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 - 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. + No messing with other people's [% terms.bugs %]. + 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.
  2. - No whining about decisions. - 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. + No whining about decisions. + 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 reopening a [% terms.bug %], do not post a comment + arguing that a [% terms.bug %] resolved as INVALID or WONTFIX should be reopened.
-

3. Applicability

+

Responding to Violations

-
    -
  1. - 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. -
  2. -
+

+ If you find a [% terms.Bugzilla %] user violating the [% terms.Bugzilla %] Etiquette + or the Mozilla Community Participation Guidelines + in comments on [% terms.bugs %], please tag the comments + in question so that an administrator can review them. +

+ +

+ If a comment is abusive or threatening use the tag abuse. An admin will + receive a notification shortly and be able to follow up. [% terms.Bugs %] with + comments marked, 'offtopic', 'spam', and 'advocacy' will also be reviewed. +

+ +

+ If you think a comment may violate our policies, but your are not sure how to mark it, + tag the comment admin and a moderator will review it. +

+ +

+ If a [% terms.bug %]'s short-description, whiteboard tags, attachments, + or user-created content other than comments that violate the + Mozilla Community Participation Guidelines + or [% terms.Bugzilla %] Etiquette, please describe the issue + in a comment and tag that comment admin. +

- 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 - persistent offending you should ping an administrator on Mozilla IRC in channel #bmo and ask them - to look into it. + If you cannot tag comments (which requires + editbugs privileges,) + or if you need to contact a [% terms.Bugzilla %] community administrator urgently:

+
    +
  • + Send email to bmo-mods@mozilla.com with + the [% terms.bug %] number and a short description of the situation. +
  • + +
  • + If you have IRC you may also contact the on-duty staff member in the #bmo channel on irc.mozilla.org. + The on-duty staff member's IRC handle is in the channel's topic. +
  • +
+

- This entire document can be summed up in one sentence: - do unto others as you would have them do unto you. + If the content of a user's name field contains abusive or offensive content, + contact a moderator at + bmo-mods@mozilla.com.

+

See Also

+

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

-- cgit v1.2.3-24-g4f1b