Experimental
The XMPP Standards Foundation provides a number of venues, both physical and virtual, for discussionand community activity. These include mailing lists, chatrooms, Summits, and so on. It alsoproduces 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 FoundationActivities.
The Members of the Foundation, and the wider community of participants in the XSF Activities, arediverse in viewpoints and goals. We see this as a benefit - we wish the maximize theapplicability and quality of our protocols, and therefore we wish to maximize the pool ofpotential 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 ofourselves and any other community members when participating in discussions or producing thatpublic output.
You are welcome. Ensure that you are also welcoming. We wanteveryone 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 allcultures, and religions, and of all sizes and shapes. We want people to be welcome nomatter their sexual identity or orientation. We want you to feel welcome no matter yourlevel of experience or ability. And we want you to help us make everyone else feelwelcomed, too.
We are a diverse community, working often to multiple goals. Weassume the best intent from each other, and do not ascribe malice. Assume that ifsomeone is complaining about your conduct, it is because they either genuinely feel itis exclusionary to them, or they genuinely believe it is exclusionary to others - in thefirst instance, take it as a learning experience, correct your conduct and move on. Ifpossible, assume, too, that bad conduct from others may derive from a misunderstandingor a lack of that learning experience rather than a deliberate attempt to exclude - inthe first instance, correct them and move on. Do not, however, use this as an excuse forbad conduct or a reason to ignore it.
A small amount of effort in ensuring your words areprofessional and polite, and avoiding subjects and expressions that may offend, goes along 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 wehave in our shared endeavour, and it is important that we are able to explainwhy. 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 withthe 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 toshare technology with each other. We should be friendly toward eachother, 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 definitionis 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 issolely by permission of the XMPP Standards Foundation. No person has anyautomatic right to joina 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 encouragesparticipation in XSF Activities. Nevertheless, the XSF does reserve the right to partially orcompletely 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 WorkTeam, 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 theFoundation 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 meansthat members are trusted by the other members to a higher degree than otherparticipants; 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 whichmight be associated with the XSF and its community reflects well on us, the opposite isalso true. By explicitly stating that this Code of Conduct applies when someone acts on behalf of the XSF, the XSF maysanction 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 bescrutinised constantly - using, for example, racist language in a talk about your XMPPproject would be problematic here, but using sexualised language in your erotic fictionhobby 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 notlive up to this Code of Conduct - please do express your concern (calmly and gently) to thatperson at the time, but only if you feel able. This allows the person to recognise their behaviourmay be problematic an correct it at the time without undue escalation. If you feel uncomfortableto 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 - youmay feel that members of the Conduct Team or the Board were involved or present and wishto report to others.
It may also be in some cases people may prefer to report informally; whilereporting "properly" is preferred, if possible the Conduct Team should strive to handleinformal 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, reportit anyway. This ensures the Conduct Team have a clear understanding of what happened and whosaw 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 aspossible.
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 aswelcoming and inclusive as possible. Sanctions are by their nature exclusionary,and many Actions are unlikely be to welcoming to those involved. Therefore theConduct Team must consider how to ensure the Actions they take and theSanctions they impose resolve the concerns proportionally, balancing theneeds of the community with the individuals that form it, with the goal ofmaximizing inclusion and promoting positive behaviours.
The Conduct team will normally have its authority to make decisions delegated to itby the Board. In some cases the Conduct Team may choose to hand its recommendation onSanctions or other Actions to the Board even if authority has not been delegated. The Boardwill 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 maybe explained to the complainant.
Any announcement of Actions or Sanctions is an Action in and of itself, and should be consideredcarefully. In general terms, any announcement should be proportionate to the bad conduct and the size ofthe audience which witnessed it. In high profile cases, therefore, the Conduct Team may decidethe result will be announced publicly in order to restore trust.
Sanctions may consist of having the ability to participate reduced or removed from some orall XSF Activities. Actions may include discussion with the Conduct Team. These arenon-exhaustive.
Many minor incidents will, therefore, not be reported publicly at all, and - even if there isan 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 badconduct or subject to the actions or sanctions, you may appeal in writing by sending anemail to the Board. The Board will consider your argument as written and will normallyrespond. 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 Conductto be weaponised for exclusionary purposes, by using the complaints mechanism to stall orsilence valid debate. Both of these are cases where the very existence of a Code of Conduct isused 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 withthat assumption, and where the burden lies - the phrasing is intended to minimize the wiggleroom there.
There are no simple answers to these concerns. Future Boards and Conduct teams are advised to bewary 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 theXMPP 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 theYAML CSS Framework, which is licensed under the terms of theCC-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 inRFC 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 athttps://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