Code of Conduct drafting process/Wikimania 2015

From mediawiki.org

Andre - Been helping to maintain Bugzilla and Phabricator for a long time. Phabricator etiquette is working pretty well. Non-staff partcipated in developing the document. When people object, can point to a clear set of etiquette. When it comes to this, we don't define any actions/consequences. Just recommendations. Have blocked people for not following guidelines, but it's not as clear as it could be. Before this existence, did point out code of conduct policy. Covers some Phabricator-specific parts, but other parts (e.g. criticize ideas not people) are generally applicable. Need a process on how to agree.

Frances - What are the specific things we're trying to solve, and in which spaces? Knowing the problems will help us find the best way to solve.

Matt: start with tech spaces: MW.org, phabricator, irc, etherpad

Andre: Friendly space policy refers to physical spaces; WMF code of conduct at https://wikimediafoundation.org/wiki/Code_of_conduct_policy only applies to staff and board members. We could take those useful, "generic" parts of the Phab Etiquette and discuss applying it to other technical spaces.

Frances: Another Wikimedia Friendly Space is for the Grants IdeaLab: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Friendly_space

   More resources: http://contributor-covenant.org/
   https://github.com/CoralineAda/contributor_covenant


   https://modelviewculture.com/pieces/a-code-of-conduct-is-not-enough


Matt: Issues with the Phabricator Etiquette:

   it only refers to Phab
   Nothing refers to consequences


Desired outcome:

   Have a doc covering all tech spaces
   Cover consequences



I'm Peter, new to Phabricator and hoping to be a good citizen. I have just reported my first task/issue in Phabricator. I was expert in a bugbase at a software company long ago and very interested in it. Two issues that recur in such systems are:

   * issue/bug/task submitted is not clear and explicit
   * it uses insider language that makes it hard for outsiders to understand the issue, rank its priority, see if it's a duplicate of what they were going to report, etc.

To me these are matters of etiquette and are relevant to the policy but I don't know more than the others present. It sounds like you are focused on genuinely bad behavior, something worse than bad etiquette.

Spamming was OBSERVED in Bugzilla/Phabricator and AKlapper blocked the accounts (this is nothing controversive). Users were observed criticizing / attacking (?) other users on the system and pointed to the Phabricator Etiquette (or in rare cases even got their Phabricator accounts blocked after being warned).

Peter is advised that it would be okay to request a feature that compressed issues be displayed without some of the detail such as the adding of subscribers ; the goal would be for readers to see more th of the core content of the task/issue on first glance without clicking around. It is agreed that it is not relevant to discuss this topic further for the code of conduct.

--- Draft (based on https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette )

We, as contributors to and users of Wikimedia technologies, seek to make our technical spaces a respectful and positive place to improve Wikimedia technologies.

To achieve this goal, follow this policy in all of Wikimedia's technical spaces, physical (including but not limited to hackathons) and virtual (including but not limited to MW.org, Phabricator, Gerrit, technical IRC channels, Etherpad), related to MediaWiki- and Wikimedia-related technologies.

   Comments should be made with the intention of constructively contributing to our technologies.  Thoughts unrelated to this should generally be brought to other areas of discussion.
   Criticize ideas, not people. A healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged.
   Communicate about technology in public where possible. Private means of communication do exist, but prefer to use public places unless an exception is appropriate.


Consequences:

  • If you see someone not following this policy or not being productive:
   The first step is to contact them, as long as you feel comfortable doing so. This can be done through private email in minor cases, or in public in major cases to avoid any later assumptions of tolerated behavior.  Alternatively, contact ? directly about the issue.
   Be informative – Tell what they are doing what they should not do. If pertinent, make them aware of this document.
   Be catalytic – Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".

2. In the case of persistent disregard of these guidelines or if you are uncomfortable contacting the person directly, contact ? on Wikimedia IRC or send an email to ? and ask them to look into it. They have the authority to take the following actions:

   2a. Issue a warning.
   2b. Temporarily or permanently ban someone from participating on a particular bug, project, page, IRC channel, etc.
   2c. Temporarily or permanently ban someone from participating on a given venue, or from all Wikimedia technical spaces.

3. The Community Advocacy team also has the authority to ban someone from all Wikimedia spaces, including technical ones.

Andre: Next / followup steps:

   * Finalize draft (?)
   ** Moved to MediaWiki.org
   * Discuss / Moderate in broader audience (?)

--- Phabricator specific items

  • Make tasks actionable by a new contributor, especially ones new contributors are likely to consider working on.
  • Link to the "how to report a bug" in the etiquette (done already by AKlapper)