Code of conduct #1111
Comments
|
I think a code of conduct should be brief and focused on the book project. The book project is not a community project, but it does take input from the community. It should make people who want to give their input feel welcome, that their input will be valued, remind everyone on the importance of kindness and respect, it should state what can be expected of us book authors. It should also address specifically the topic of inclusive language, and state that we will use inclusive language including gender neutral pronouns. The book is for many people their entrance to the homotopy type theory community and our field of research. So I think it is important for our community to have a welcoming statement, and that we commit to behaving accordingly. In reaction to the discussion that followed upon the simple request to use inclusive language in the book, I also felt it is important to write a statement of inclusion for the https://github.com/UniMath/agda-unimath/blob/master/README.md#statement-of-inclusion |
|
I agree with Egbert. The inclusivity statement I use on course syllabi is:
and is pretty parallel to what Egbert suggested. If we want to list any ombudspeople to receive any anonymous/private feedback, I would be happy to be one of them. |
|
It's easier to discuss a code of conduct if we already have a concrete proposal, so I went ahead and wrote an initial draft. |
|
IMO, the most important part of an effective CoC is an explicit commitment to actually uphold the standards and inclusivity set out therein, including some indication of how violations of the CoC (by both community members and authors/maintainers) will be dealt with. That is what I'm currently missing here, and it (+ actual enforcement when needed) is a crucial component of demonstrating that it's not just empty words or promises. (Posting this here rather than on #1112 since it's more general to the concept of a CoC, and less so to any one specific proposal) |
Even though @andrejbauer stated that the vote would be open until Sunday, April 17th, we have decided unanimously that we need not wait until then, as there is a clear preference for the 'they' option, which we shall implement promptly. Adoption of a suitable Code of Conduct and related topics may still be discussed in Issue HoTT#1111.
|
It is confusing to have an issue and a pull request for the same thing. Which one should we use, this issue or #1112 ? |
|
I saw @EgbertRijke's question about language guidelines. Personally, I use the APA's guidelines, but there are many others. I also agree with @joepie91 that a CoC itself has no power. I believe |
|
To clarify; I do feel that a CoC is a helpful addition. But indeed its purpose is not to function legalistically (and exhaustive CoCs tend to work poorly), but rather to communicate to (potential) community members what they can expect from the community and its moderation policies, in the form of a concrete commitment. That is also where I'm coming from with my earlier comment. |
I think this is potentially valuable in larger communities that require communication between multiple moderators, or in-person events. I don't think it's necessary for a project as small at the HoTT book, and in fact, probably not the right move, as explicit commitments invites rules-lawyering, adding friction to doing what is best for the community in the case where it does not align with this commitment. In larger communities, making this commitment is worth that cost (and the cost to craft a concrete commitment that holds up over time), mostly because multiple moderators need to communicate with each other in order to be consistent. But in this case, I think it is better to simply insist that Dan (or whoever the CoC PoC will be, if we have one) do what is best for the community and the book project (obviously, with input from the community). So, unless you have a concrete commitment in mind that is positively anti-legalistic, I think it would be best to not include one. |
|
It would be nice to know that the code of conduct is not just pretty words, but I see @atondwal 's point that formalizing how to enforce it can lead to problems down the line (whether that's requiring a punishment when discussion and education would work better, or giving people an excuse to do nothing because a situation wasn't anticipated). If it's not enough to simply give people notice of what they have a right to expect, then maybe have something concrete to deal with violations: directions along the lines of ‘If you know of violations of this code, please contact […] / express your concerns at […]’. (Then it's up to the community to make sure that there's someone at […] to listen.) |
This is why I remarked that exhaustive CoCs rarely work. I don't think that an effective CoC should try to exhaustively list 'forbidden behaviours' or 'moderation consequences' or anything like that - the commitment wouldn't be to do a specific thing, but rather to uphold particular values. Certainly mediation or education is always preferred over eg. a ban, and that can be left up to moderator discretion - as long as it's clear that that moderators/maintainers/authors/etc. explicitly commit to resolving the situation in some way, the exact details of which will be contextually dependent. Likewise, a CoC might mention that the goal is an inclusive and welcoming community that does not tolerate hateful rhetoric, harassment, etc. - but without trying to precisely specify what specific language is not allowed, or what specific forms of harassment are forbidden. Even literal nation states have trouble defining things like this, so I wouldn't expect any project CoC to get this right either. Taking a more general approach - specifying values and a commitment to resolving issues somehow - also prevents rule lawyering, since there is nothing to rule-lawyer over. The moderator has the last word in deciding when something is harming the community or its members, whether or not it is listed in the CoC. It's useful to explicitly state this in the CoC, to pre-empt rule-lawyering. Or to phrase it differently: a CoC isn't written for the perpetrators, but for their potential victims. You don't need the blessing of a CoC to eject a harmful actor from your community or mediate in a conflict; but it's hugely helpful to communicate to marginalized groups in particular what kind of shit they won't have to deal with in the community. Think of it as a "you are safe here" banner of sorts. |
I agree that it is an important goal of a CoC to communicate "you are safe here"
Right, I think that sounds good, but I'm not sure what you have in mind here. Something like section 6 of the Debian CoC?
I want to strongly object to a framing that divides the world into perpetrators and victims (or worse, potential perpetrators and potential victims), both in our thinking, and in the language that cements itself into any code of conduct. It may handle easy cases, but slightly more sophisticated attackers will DARVO to take advantage of this dynamic. Indeed, not only does this framing aid such attacks on the community, in my experience it also attracts folks who know they can use this sort of dynamic to silence their victims (to use the same language as above). |
I'm happy to update my stance as the maintainers have officially expressed the intention to consider the CoC generated from this discussion. I still consider the "welcoming" CoC a form of legalism, but with such an endorsement, my concern is moot. As mentioned by others, I also think that the primary purpose is to convey the messages "we care about you" and "you are safe here." I am happy to help revise the text. I want to echo @atondwal's point---the DARVO strategy is real. And personally, I want the CoC to focus on learning and helping instead of blaming and accusing. More concretely, I prefer a condensed version of Django or Debian's CoC, which is more like an expanded version of "you are welcome here, and we will respect you." The reason is that I think we actually do not need a CoC, as we are already repeating the message "you are welcome here" to all newcomers. However, recent events made many people feel the promise has been broken, and thus, as far as I can see, we are considering a more formal CoC as a renewed promise to regain trust. Despite its formal nature, I believe the most suitable CoC would be the one that stays close to the original message we have been broadcasting: "you are welcome here." I prefer not to add too much detail to this simple and powerful message beyond what's necessary. A highly condensed version of Django or Debian's seems appropriate. |
|
In addition to a statement of welcoming and inclusivity, it might be a good idea to state that the issue and the pull requests are dedicated to improvements, questions, and other issues pertaining to the HoTT book itself. General discussions about homotopy type theory and topics related to the wider HoTT community are welcome at the homotopytypetheory Google group. Do you think this would be a good idea? |
|
I'm not sure how much of a say I have in this since I did not contribute much nor for a long time, but I'll say it anyway, since it is important to me: I strongly support the use of inclusive language, along the lines of what @ThePuzzlemaker, @favonia, @tlringer, @jonsterling, @andrejbauer and many others have defended in #1101. I would have taken a stance there if the topic had not been locked before I saw it. I also think a CoC should not (and IMO cannot) be interpreted legally, but as a promise made to contributors and potential contributors, that moderators vouch to uphold, so that future PRs like #1101 get merged without hurtful comments and so that people know who to report incidents to. In particular I suggest to create a team to tag in such matters and to mention its name and contact details in the CoC. I also suggest that the team discusses how to deal with various situations beforehand. In the absence of this, you might create a false feeling of safety. In short: without a designated and trained support team, a CoC is void or harmful IMO. |
|
yes to Andrej's proposed statement about separating discussion of the Book from general discussion. |
|
The thing of adopting Django or Debian's code of conduct that I'm worried about is that they are written for very large projects with worldwide networks of developers. For our code of conduct, I would propose that we focus it rather sharply to the book project, and that we don't try to make it a code of conduct for the entire HoTT community. I really like Favonia's pointer to APA's guidelines for inclusive language. Those are very clear, used in practice by psychologists, and backed up by many research articles cited in that guideline. That takes the topic of inclusive language immediately out of the realm of politics. I suggest that we state in our code of conduct that we will follow these guidelines. |
I updated the PR with these sentences. |
|
I am in favour of:
If one feels the code of conduct is broken and the uneasiness that follows it is good to have someone to report the issue to, someone who will deal with mediating/resolving the issues. |
|
It could be a good idea to include a list of people to contact in case an issue arises about conduct. The most straightforward list of people would be the list of administrators Steve Awodey But there are several obvious problems with this list. One of the administrators is at the center of the current controversy, but perhaps more importantly there are only men on the list of administrators. When it comes to reporting an issue, it is super important that someone with a complaint can file their complaint to someone they think will hear their problem and take it seriously, so it must be a more representative group of people than the current group of administrators. There are already two non-authors among the administrators, so my suggestion is that the administrators find more people to help with the administrative tasks of maintaining the HoTT book, and then we can include it in the code of conduct. This is something beyond the scope of the code of conduct, and it should be up to them to decide. But my conclusion and fear is that it comes across as noninclusive and potentially unwelcoming to suggest in the code of conduct that in case of a problem, one of the administrators could be contacted to resolve an issue. |
|
Being an administrator is predominantly a technical role, not a leadership role. The administrators are the people who currently maintain the book, or have done so actively in the past. It would not be appropriate, in my opinion, to burden the administrators with a role they never asked for (and I am not talking off the top of my head). A better solution is to have a single person as a point of contact, a confidant so to speak. This should be someone who many people will find easy to talk to (so not too senior) but also not an inexperienced person (so not a student). @EgbertRijke comes to mind, if he would be willing to take on such a role. Having a second confidant might be good, but three are already a committee and we know how committees are. You could simply state "Please contact Egbert Rijke or XY regarding any questions or issues involving this code of conduct." |
|
It's very sad that this discussion has become necessary! Formulating a CoC is reasonable, but I'm not convinced that it's as helpful as one might hope, for reasons that @favonia, @CohenCyril, and others have pointed out. We all agree with the statement that everyone should treat everyone with respect, but it's up to interpretation whether this principle is violated in a specific situation. (To be clear, I personally think that the principle was violated in the discussion of the infamous PR #1101, but that's beside the point.) I think what we would actually need is a list of concrete rules such as "the book uses inclusive language," which would have made PR #1101 a straightforward merge. Such rules can certainly be presented as a CoC. However, we probably only discover the need for a specific rule as we go along, so each issue will still be discussed when it arises the first time. Thus, rather than trying to avoid these situations, I'd say that we should decide what to do when a situation such as the one in PR #1101 occurs, or when an individual member of the community thinks that such a discussion is about to occur. I agree that it makes sense to have confidants. @EgbertRijke would be a terrific choice, possibly together with @andrejbauer, to cover different levels of seniority. But we should first decide on what exactly confidants are supposed to do before we nominate them. edit: I also support @dlicata335's bid below. |
|
I would be happy to be listed as one of the contacts/confidants (along with anyone else who wants the job). Qualifications: book author, not current administrator (so independent of current structure), tenured (so can freely anger people). Con (?): generally nice and assumes the best of people. Bigger con: I agree with @EgbertRijke that ideally we would have a diverse set of people in this role. But, given the make-up of the community as it stands, this may be a good job for allies to do. |
|
Do we want to have a CoC for HoTT 2023. The ASL is currently discussing one for all of their meetings, and we will be sponsored by them, but theirs will probably not be published in time for us to simply endorse it. The AMS has a CoC for its meetings here: |
Following the events of #1101, I am opening an issue to discuss the adoption of a code of conduct.
Please note that we already are bound by the GitHub Community Forum Code of Conduct. The question is whether we should and want to have an additional Code, and if so, what? @atondwal made pertinent obsercations in this comment.
I have very little exeperience with formulating Codes of conduct. As far as I am concerned the GitHub one that we already abide by is good enough, even though it may not be perfect in every respect.
Let me also say that I do not have the spare capacity to actively contrubite to formulation and adoption of the Code. If there are other book authors who are interested in heading the issue, I will be grateful to you.
The text was updated successfully, but these errors were encountered: