The XMPP Standards Foundation provides a number of venues, both physical and virtual, for discussion and community activity. These include mailing lists, chatrooms, Summits, and so on. It also produces much output designed for the general public, such as the XEPs themselves, the website, and kiosks or stands at actual events. Collectively, these are the XMPP Standards Foundation Activities.
The Members of the Foundation, and the wider community of participants in the XSF Activities, are diverse in viewpoints and goals. We see this as a benefit - we wish the maximize the applicability and quality of our protocols, and therefore we wish to maximize the pool of potential participants who might offer their unique viewpoints and help us reach new goals.
It makes sense that there is a Code of Conduct that applies to the behaviour we expect both of ourselves and any other community members when participating in discussions or producing that public output.
You are welcome. Ensure that you are also welcoming. We want everyone to feel welcome no matter what the colour of their skin, where they live, or where their ancestors came from. We want to welcome people from all cultures, and religions, and of all sizes and shapes. We want people to be welcome no matter their sexual identity or orientation. We want you to feel welcome no matter your level of experience or ability. And we want you to help us make everyone else feel welcomed, too.
We are a diverse community, working often to multiple goals. We assume the best intent from each other, and do not ascribe malice. Assume that if someone is complaining about your conduct, it is because they either genuinely feel it is exclusionary to them, or they genuinely believe it is exclusionary to others - in the first instance, take it as a learning experience, correct your conduct and move on. If possible, assume, too, that bad conduct from others may derive from a misunderstanding or a lack of that learning experience rather than a deliberate attempt to exclude - in the first instance, correct them and move on. Do not, however, use this as an excuse for bad conduct or a reason to ignore it.
A small amount of effort in ensuring your words are professional and polite, and avoiding subjects and expressions that may offend, goes a long way. Humour is not a mitigating factor here.
It's often useful to limit your comments to the point you wish to make if you're unsure.
Examples of what to avoid:
Disagreements are normal and common. Sometimes, there are conflicts or tensions among the different goals we have in our shared endeavour, and it is important that we are able to explain why. Criticism is essential to find the best solutions to the problems that face us. However, it is vital that while we are open and honest in our criticism, we do so with the calm respect we expect of others and with tolerance for other points of view.
Examples of what to avoid:
We are, fundamentally, a community of people working to share technology with each other. We should be friendly toward each other, and act to support each other's efforts.
Examples of what to avoid
As a rule of thumb, if you find yourself dividing the community into an "us" and a "them", you are risking breaking this Code of Conduct.
The examples in this document of "what not to do" are intended to be just that - examples. They are not intended to be exhaustive.
Many of the terms used in these examples have formal definitions, either in law or elsewhere. In general, the strict interpretation of such a formal definition is not a strong basis for the acceptability of a certain behaviour. Instead, please try to follow the spirit of this document, perhaps more so than its letter.
The governing principle of this Code of Conduct is that all participation in XSF Activities is solely by permission of the XMPP Standards Foundation. No person has any automatic right to join a XSF chatroom or mailing list, or contribute to XSF documents such as the XEP series.
Naturally, under normal circumstances, the XMPP Standards Foundation welcomes and encourages participation in XSF Activities. Nevertheless, the XSF does reserve the right to partially or completely exclude anyone from any activity, for any reason.
The final decision on such exclusions is made by the Board, who may from time to time appoint a Work Team, called the Conduct Team, to act on their behalf. If the Work Team has not been appointed, the Conduct Team is the Board.
There are exceptions to this - in particular, any right of elected members of the Foundation under the Bylaws cannot be curtailed by the Board, though the Board (or any other any member) could start the process to eject a member. This means that members are trusted by the other members to a higher degree than other participants; something that should be considered during elections.
This Code of Conduct applies to anyone who:
Although on the face of it the first case may seem to be extremely broad, in fact the proviso of "reasonable expectation" ensures that this Code of Conduct will not be applied more often than necessary. The intent here is that while good behaviour which might be associated with the XSF and its community reflects well on us, the opposite is also true. By explicitly stating that this Code of Conduct applies when someone acts on behalf of the XSF, the XSF may sanction bad behaviour outside of XSF Activities should the need arise.
Note also that this is not intended to mean that any XMPP developer's behaviour will be scrutinised constantly - using, for example, racist language in a talk about your XMPP project would be problematic here, but using sexualised language in your erotic fiction hobby is unlikely to be relevant to this Code of Conduct.
However, higher standards may be applied to those seen as representative of the community, such as XSF Members and, in particular, members of the Board or Council.
If you witness bad conduct by somebody - that is, if you feel someone's behaviour does not live up to this Code of Conduct - please do express your concern (calmly and gently) to that person at the time, but only if you feel able. This allows the person to recognise their behaviour may be problematic an correct it at the time without undue escalation. If you feel uncomfortable to do so that is perfectly fine and will not affect further handling of the incident.
Whether or not you called it out, do one of the following:
Who you report it might depend on who was involved in the incident - you may feel that members of the Conduct Team or the Board were involved or present and wish to report to others.
It may also be in some cases people may prefer to report informally; while reporting "properly" is preferred, if possible the Conduct Team should strive to handle informal reports in the same way as formal reports, while at the same time not encouraging unverifiable reports such as gossip or hearsay.
Importantly, even if someone else called it out or said to you they would report it, report it anyway. This ensures the Conduct Team have a clear understanding of what happened and who saw the conduct, and allows the Conduct Team to identify any longer term patterns.
When you report it, include the place, date and time, and report it as calmly as possible.
The Conduct Team will then discuss the incident. This should be done quickly, and in private.
The Conduct Team may ask for further information from the person reporting the incident, the person or persons directly affected, the person accused of bad conduct, or others who were present.
Finally, the Conduct Team will make a decision on whether sanctions or other actions should be taken, and determine the exact form of such sanctions or actions.
The purpose of a Code of Conduct is to ensure our community is as welcoming and inclusive as possible. Sanctions are by their nature exclusionary, and many Actions are unlikely be to welcoming to those involved. Therefore the Conduct Team must consider how to ensure the Actions they take and the Sanctions they impose resolve the concerns proportionally, balancing the needs of the community with the individuals that form it, with the goal of maximizing inclusion and promoting positive behaviours.
The Conduct team will normally have its authority to make decisions delegated to it by the Board. In some cases the Conduct Team may choose to hand its recommendation on Sanctions or other Actions to the Board even if authority has not been delegated. The Board will discuss and vote on these "in camera" (i.e., not in public and not minuted).
Finally, the result will normally be explained to the person accused of bad conduct, and may be explained to the complainant.
Any announcement of Actions or Sanctions is an Action in and of itself, and should be considered carefully. In general terms, any announcement should be proportionate to the bad conduct and the size of the audience which witnessed it. In high profile cases, therefore, the Conduct Team may decide the result will be announced publicly in order to restore trust.
Sanctions may consist of having the ability to participate reduced or removed from some or all XSF Activities. Actions may include discussion with the Conduct Team. These are non-exhaustive.
Many minor incidents will, therefore, not be reported publicly at all, and - even if there is an agreement that bad conduct occurred - may not result in any visible actions at all.
If you disagree with the decision made by the Board and you were either the subject of bad conduct or subject to the actions or sanctions, you may appeal in writing by sending an email to the Board. The Board will consider your argument as written and will normally respond. The Board's decision after appeal is, however, final.
It is possible for almost any behaviour to have some argument why it is not, in fact, exclusionary, and why it's just someone taking offence too easily. It also is possible for the Code of Conduct to be weaponised for exclusionary purposes, by using the complaints mechanism to stall or silence valid debate. Both of these are cases where the very existence of a Code of Conduct is used for exclusionary purposes, perverting its very intent. Obviously, don't do either.
"Assume Good Faith", in particular, holds the risk of an endless argument over how far to go with that assumption, and where the burden lies - the phrasing is intended to minimize the wiggle room there.
There are no simple answers to these concerns. Future Boards and Conduct teams are advised to be wary of both cases.
This document has no considerations for IANA.
This document has no considerations for the XMPP Registrar.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion by the membership of the XSF might also be appropriate (see <https://mail.jabber.org/mailman/listinfo/members> for details).
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
Address substantive feedback from JC Brand; add Peter Saint-Andre as co-author to help address future feedback.
Add anchors to every section, for easier linking. Also fix a typo.
@report{cridland2021n/a,
title = {Community Code of Conduct},
author = {Cridland, Dave and Saint-Andre, Peter},
type = {XEP},
number = {0458},
version = {0.3},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0458.html},
date = {2021-06-01/2023-09-14},
}END