Code of conduct changes #37501
Code of conduct changes #37501
Conversation
- Add a section describing more unacceptable behavior - Add a diversity section - Add reporting guidelines - Add information on how reports are resolved Also add a new document with audience the Sage Code of Conduct Committee (new name for the sage-abuse committee)
|
Thank you for all of the suggestions, plus the one on #36844 about adding more examples. I have to work on some other things for a day or two, but I'll get back to these soon. |
Co-authored-by: Matthias Köppe <[email protected]>
Co-authored-by: Matthias Köppe <[email protected]>
Co-authored-by: Matthias Köppe <[email protected]>
Add links to Google groups conduct documents.
|
IMHO it should cover GitHub blocking of team membes as (normally speaking) unacceptable - among with other possible means to influence reviewing process. |
|
I think that the current version is ready, and other changes should be done in followups. Collecting some suggestions from various places: diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 7bb46dea13..83be123895 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -71,6 +71,35 @@ goals. Please try to follow this code in spirit as much as in letter,
to create a friendly and productive environment that enriches the
surrounding community.
+## Commentary ##
+
+Sage is a community effort, and not the project of a single or even a
+few persons. Try to not identify yourself with your contributions to
+Sage.
+
+It is not acceptable to judge somebody else's attempts to improve Sage
+other than criticizing it technically or casting a negative vote. By
+contrast, emphasizing the positive aspects and appreciating the effort
+are welcome.
+
+Sometimes even conduct that is intended to be helpful can be offensive to others.
+
+- Do not attempt to manage other developers' time and focus. Always remember
+ that different people contribute to the project with a variety of motivations
+ and constraints. For you, time that you can set aside for Sage development
+ may be very scarce; but for others, for example hobbyists, it might simply not
+ be a relevant constraint. Moreover, keep in mind that in real life, it
+ is supervisors who manage time and assignments of their subordinates.
+
+- Do not dismiss other people's efforts on an aspect of the project because you
+ feel that other aspects are more important or more urgent for the project.
+ Always remember that different people contribute to the project on the basis
+ of a variety of expertise, motivations, and priorities.
+
+Blocking GitHub users is discouraged because it can obstruct effective
+collaboration. If a user blocks someone, they should also alert the
+Sage Code of Conduct Committee, which may follow up with questions.
+
## Diversity statement ##
Sage welcomes and encourages participation in our community by peopleThese could be kept together or broken up into multiple PRs since they come from different places: the first two paragraphs from Martin R on sage-devel, the middle part with indented paragraphs from #36844, the last part an attempt at Dima's request. But I would like to stick with the current proposal as it stands. This is partly because some of these new parts might be controversial — I'm not sure — and partly because I don't see a good place to put them in the current document. As I said on sage-devel, the goal of this ticket is to update our current Code of Conduct, trying to keep the same content but adding details (like the role of the committee, how to amend the document, codes of conduct for related organizations like GitHub), not to add new content. An exception to this is the new item 5, taken from the SciPy code of conduct, which I hope is non-controversial. |
CODE_OF_CONDUCT.md
Outdated
|
|
||
| Potential consequences for violating the Sage Code of Conduct include: | ||
|
|
||
| - Nothing (if the committee determines that no violation occurred) |
There was a problem hiding this comment.
This seems logically contradictory to the line above. Does the line above need to be "Potential consequences of alleged violations of the Sage Code of Conduct"?
Probably not, but then the "nothing" line, which is valuable, needs to be listed separately.
There was a problem hiding this comment.
I can add "alleged"; that's simpler than listing it separately.
There was a problem hiding this comment.
Actually, I'm going to replace "if the committee determines that no violation occurred" with "for example if the matter has been resolved publicly while the committee was considering responses" — this is in the second document already.
|
The name |
|
The docs tell too much about discrimination. Have we ever had a case about discrimination in our community? Yes, we must prevent discrimination, but the docs seem to be disproportionate in dealing with problematic conducts. We may cut some of the passages dealing with discrimination. The doc |
I recall a relatively recent story with a new contributor being (mildly) harassed by a team member due to their pronouns etc, on sage-devel (? - or sage-support). It was quite ugly, probably these messages were deleted (I can't find them any more). It's also telling that we don't have (m)any active female contributors - it's not unique for open-source projects, but it means that our conduct is too unwelcoming. |
|
@VivianePons - could you please comment on this? |
|
I cannot give any opinion considering the request here as I have had no time to look it up and am completely over busy right now. I can say though, to answer Dima's question, that the code of conduct itself was created because there were issues about some attitudes / comments on the sage-devel list. I wouldn't say those were discriminatory per say, they were just not acceptable. And yes I have heard of women not wanting to participate in discussions because they did not want to deal with the aggressiveness of some members |
It could also be converted to be a single document. Maybe that would make more sense? |
Yes, I would be in favor of this. |
Yup, I think about these things more than from time to time (in fact, I sent @roed314 links to several survey articles, which naturally cite your better half quite a bit, in response to a separate conversation). And in general, I agree very strongly that the method and the ballot matter significantly in how an election works. However, the issue is just as much a sociological one as a technical one. What sort of electorate do you have? For polarized, non-consensus, indeed an approval (or plurality, for that matter) is going to potentially make a lot of people unhappy. But then the question arises of whether there should be "spots" for different "constituencies" (such as representation from different departments on a school promotion and tenure committee), which there is some (but not enough) literature on. In our case there is the further (possibly very significant) issue of lack of turnout. And so forth. Anyway, which axioms you think are most important is just as likely to determine your system as anything else. It would be unfortunate if we truly felt that a Sage conduct committee is as polarized of a topic as several others I won't bother to mention which are troubling the world right now. What we really need is a good old in-person Sage days to hash out a compromise that is acceptable enough to everyone, even if no one is truly happy with it. (Not that I can fund that 😝 .) Perhaps only in my view, the overall well-being of the community means we all have to submerge, or at least hold more loosely, our strongly held technical points of view from time to time (emphasis on all, I'm not just pointing at one or two people) in order to keep the project moving - especially now, as the rancor has started making some people more reluctant to stay involved. As a voting theorist (of sorts?), I find that when you have to have a vote, everyone may have already lost the election in some ways. For what it's worth, I think we can rise above it. |
|
well, we no longer have an electorate which holds largerly uniform views on how Sage should evolve - thus these things get more important. Deciding on each disputed ticket by simple majority is effectively the same sort of multiwinner approval voting bug as in multiwinner elections - it totally ignores the opinions of the minority. (Apart from being time-consuming, chaotic, etc) That's why there is a need of technical committee which decides on important matter. |
Yes, there is a pretty large literature on "log-rolling"/"referendum paradox"/etc. Interested lurkers should check out the chapter "Trouble in direct democracy" in this elementary textbook. I agree about that in principle.
But what if the technical committee can't decide (which seems likely)? Is there any way to resolve these matters in a different way - perhaps by some give and take on the big issues? My guess (though only a guess) is that most Sage developers just want a solution acceptable to those who have the interest and expertise to tackle things like packaging, as opposed to having to choose one or another or several competing proposals. (Maybe the proposals aren't quite as competing as they seem?) |
|
@kcrisman - the book you cite is actually older than some of the voting methods I mentioned - e.g. the method of equal shares was specifically designed for direct democracy IRL, and it started after 2018 if I am not mistaken |
|
The committee will discuss whether to release more detailed anonymized voting results, but I just did a quick analysis using this site. With 5 people on the committee different systems had different results, but after extending to 6 based on the approval-voting tie there was broad agreement: Approval Voting, Proportional Approval Voting, Phragmén's sequential rule, Maximin Support and Equal Shares all selected the current committee; only Minimax approval voting had a different result. |
Oh for sure, that book is both very elementary (as I said) and a bit older, it's not supposed to be a research-level text. |
And for completeness for lurkers (if any) the topic of that chapter is NOT multiwinner voting, but rather the issue of deciding each ticket by majority. Sort of like the town meeting here in New England ... |
@kcrisman The story that the "disputes" are about "strongly held technical opinions" has been a false narrative from the beginning. It is all a matter of abusive conduct, which creates a climate in which technical discussions are not even possible. |
The Code of Conduct Committee disagrees that there are no underlying technical disagreements underlying the many recent disputes, though we do agree that there has been a pattern of inappropriate comments and labeling. It is not within our mandate to make technical decisions, but we are discussing whether there are measures that we might suggest to the community as a whole that would help developers interested in packaging reach consensus on paths forward. In the meantime, please restrict comments on this ticket to discussing the proposed changes to the Code of Conduct. |
|
I'm giving this PR positive review, since the discussion has moved on from the specific changes suggested. @jhpalmieri, feel free to bring this to sage-devel for a vote. |
|
I'm marking this as "pending" until there is a vote on sage-devel. @vbraun, please do not merge until that vote happens. |
Are you saying that our concrete technical proposals are just abuse directed at you? |
|
there are a number of these "strongly held technical opinions" which are giving users unneeded headaches, and developers scrambling to help them with workarounds, instead of doing something useful. The most harmful of these is "minimal requirements" for OSs - the lists of pre-reqs for concrete OSs which are not including many packages which don't need to be built on that OSs. Instead of telling the users the best way to get Sage built on their OS, we "recommend" things, in a confusing clumsy way. And if these "recommendations" are not followed the hell breaks loose. Just today I spent time on sage-release looking at a failed build of GNU info on Ubuntu 22. Normal Python projects such as scipy doesn't gaslight its users (and developers) this way - it just tells them what it needs, upfront. Thus I consider this "strongly held technical opinion" as a nuisance, and its defenders as people who have no respect for me and Sage users alike, people who steal my and their time and effort. |
I second David's request to "restrict comments on this ticket to discussing the proposed changes to the Code of Conduct". Complaints to the CoCC can be submitted to [email protected] (and in addition, committee members may also internally flag possible conduct violations). |
Change the list of committee members based on the recent sage-devel vote
|
Documentation preview for this PR (built with commit 78d6ef4; changes) is ready! 🎉 |
Revise the code of conduct: add a diversity component and sections on reporting guidelines and how reports are handled. Also add a new document about the role of the Sage Code of Conduct Committee. The changes to the first document are based on similar documents from SciPy and NumFOCUS, plus inspiration and some language from the changes proposed at #36844. The second document is heavily based on the corresponding document from SciPy.
Based on top of #37054.
📝 Checklist
⌛ Dependencies
#37054