Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[William Stein]

Dear Sage Developers,

1. There are over 20 pull requests labeled as "disputed" [1]. To
resolve these pull requests, we will be appointing an editor with no
direct involvement in the pull request to make a judgement call on
that particular pull request. We will then fully support the
decision of this editor. If you have the time to be the (possibly
anonymous) editor for a disputed pull request, please email us
(wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
our list.

2. There are numerous recent reports of violations of the code of
conduct to the sage-abuse mailing list. The code of conduct should
not be used as a tool in case you don't agree with somebody else. For
now, the main act of censure that the sage-abuse committee will be
taking going forward will be to delete comments (on github and mailing
lists) that violate the code of conduct.

We do not have much time to devote to Sage development. However, we
both very much want things to move forward in a friendly and
encouraging way, and we would greatly appreciate it if the community
of Sage developers will support the above plan to move things forward
and ensure a positive experience for everyone participating in Sage
development.

Best regards,

Volker Braun and William Stein

[1] https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed

--
William (http://wstein.org)

[Michael Orlitzky]

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
>
> 1. There are over 20 pull requests labeled as "disputed" [1]. To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that particular pull request. We will then fully support the
> decision of this editor. If you have the time to be the (possibly
> anonymous) editor for a disputed pull request, please email us
> (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
> our list.
>

Many of these are disputed for the same underlying reasons. Appointing
a different editor for each PR is not likely to help. If you pick an
editor from Camp A, he or she will always rule in favor of Camp A; pick
an editor from Camp B...

I foresee several problems resulting:

1. We'll wind up with disputes about how the editor was chosen in
place of disputed PRs.

2. The editor is essentially ruling in favor of a development
philosophy, and it would make little sense to rule against
the opinion of the majority of sage developers (if there is
such a thing).

3. It often doesn't make sense to rule in favor of Camp A for
one PR and Camp B for another.

4. It enables editor shopping and PR ping pong. Rule against me
the first time? I can try again in two weeks and hope for a
different editor.

Different journal editors can accept competing publications without
much harm, but here that's not the case.

[Martin R]

Maybe it would make sense to appoint a group of editors, rather than a single editor, and this group decides per vote?  I'd feel much better if the responsibility is at least a little bit distributed between several people, and, most importantly, people who have been around for some time.

(Please note that I have no idea what these disputed PRs are really about.  I looked at some of them, but was unable to see how they might affect me.)

Martin

[Volker Braun]

Appointing an editor is not supposed to be part of normal review. This is for the (hopefully rare) cases where we, the community, horribly failed in the code review process and for whatever reason no consensus can be found among the issue participants. The code review should have been a cooperative group decisions of the issue participants.

If anyone thinks they can game the system by being a general nuisance and starting review wars in every issue to force editor decisions, then I'd encourage them to rethink their approach.

[Dima Pasechnik]

On Wednesday, January 10, 2024 at 3:21:54 PM UTC Michael Orlitzky wrote:

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
>
> 1. There are over 20 pull requests labeled as "disputed" [1]. To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that particular pull request. We will then fully support the
> decision of this editor. If you have the time to be the (possibly
> anonymous) editor for a disputed pull request, please email us
> (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
> our list.
>

Many of these are disputed for the same underlying reasons. Appointing
a different editor for each PR is not likely to help. If you pick an
editor from Camp A, he or she will always rule in favor of Camp A; pick
an editor from Camp B...

The camps are roughly split across the question whether

Sage the distro should be deemphasized, and the development

process should be centered around sagelib, or not.

As well, and it's not a coincidence, roughly the same partition

is on the basis of the developer platform used by the camp member.

It appears that the Linux users are primarily for deemphasizing

Sage the distro, and macOS user are primarily against.

I suspect it's due to the latter used to Sage the distro as a "missing macOS

package manager". 

So they are happy adding more and more spkgs to Sage.

And Linux users rightly see adding to Sage spkgs, which

package software available on their systems in a regular way,

as a bloat, which moreover needs constant attention - 

while sagelib suffers.

I don't think that without solving this conflict the disputed PRs

dispute can be solved.

I may go on discussing how the Sage macOS problems may be

mitigated, but not here and now.

Dima

[Matthias Koeppe]

As I have explained to the current, semi-anonymous sage-abuse committee in private communication:

The framing of the dysfunction in the affected PRs https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed as mere "disputes" or "controversies" is misguided and harmful.

We do not have a problem of project governance. 

We have a problem of persistent, aggressive, escalating Code of Conduct violations from a very small number of developers. (Key example with pointers to other examples: https://github.com/sagemath/sage/pull/36726; Trigger Warning: abusive language).

And we have the problem of a lack of enforcement of the Code of Conduct.

Easy to read overview on best practices: https://opensource.guide/code-of-conduct/

One key quote:

- "A code of conduct that isn’t (or can’t be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren’t actually important or respected in your community."

So I think we should start with electing a new sage-abuse committee that is willing to publicly affirm and enforce the Code of Conduct. I would suggest that nominations (including self-nominations) be sent to this list by Jan 24.

The new committee should work with the community to clarify the Code of Conduct and spell out its procedures and the range of sanctions that it will conisder (see https://github.com/sagemath/sage/pull/36844).

Matthias

[Dima Pasechnik]

We have a problem of one developer, who decided, based on his, certainly, prolific contributions, that he can appoint himself a CTO of the project, and tell everyone who disagrees with him that it's a violation of CoC.

[Edgar Costa]

I suspect it's due to the latter used to Sage the distro as a "missing macOS
package manager".
So they are happy adding more and more spkgs to Sage.
And Linux users rightly see adding to Sage spkgs, which
package software available on their systems in a regular way,
as a bloat, which moreover needs constant attention -
while sagelib suffers.

macOS has several unofficial package managers.

In particular, homebrew makes it very easy for anyone to add a formula, which is very similar to the way that spkg works.

[Volker Braun]

On Wednesday, January 10, 2024 at 2:37:59 PM UTC-5 Matthias Koeppe wrote:

[...] clarify the Code of Conduct and spell out its procedures and the range of sanctions

In case anyone missed this point, it is literally spelled out in William's original message:

[Dima Pasechnik]

indeed, and I even experimented with writing such formulae, e.g. for flint.
https://github.com/sagemath/homebrew-science

When it was discussed whether we wanted to use it, the main objection was that it needs root (once, explicitly, to set up, then implicitly), thus unsafe.
Conda was mentioned as a better option. But Conda is much bigger.

We do have a setup to use Homebrew.

[Kwankyu Lee]

Hi, 

Appointing an editor (or editors) seems not a realistic solution, as it would be harder than resolving a disputed PR.

Forcing the code of conduct is not realistic either, as we have no means to force it.

I advocate for adopting a policy such as David Roe suggested for disputed PRs, as we all can agree to accept it, and then disputed PRs are resolved by  the common judgement of community members. The policy is nothing but a simple form of sage-devel votings that we are already used to.

[kcrisman]

We do not have much time to devote to Sage development. 

And this is a great time to thank Volker for continuing to serve as release manager for the vast majority of Sage tickets which are not about the design philosophy, despite his (and William's) lack of time.  Thank you!

[kcrisman]

Many of these are disputed for the same underlying reasons. Appointing
a different editor for each PR is not likely to help. If you pick an
editor from Camp A, he or she will always rule in favor of Camp A; pick
an editor from Camp B...

The camps are roughly split across the question whether

Sage the distro should be deemphasized, and the development

process should be centered around sagelib, or not.

As well, and it's not a coincidence, roughly the same partition

is on the basis of the developer platform used by the camp member.

It appears that the Linux users are primarily for deemphasizing

Sage the distro, and macOS user are primarily against.

As a general observation, this seems somewhat accurate.  That said, as Martin R points out, many (most?) people don't seem to be in a "Camp". 

 

I suspect it's due to the latter used to Sage the distro as a "missing macOS

package manager". 

So they are happy adding more and more spkgs to Sage.

And Linux users rightly see adding to Sage spkgs, which

package software available on their systems in a regular way,

as a bloat, which moreover needs constant attention - 

while sagelib suffers.

I don't think that without solving this conflict the disputed PRs

dispute can be solved.

I may go on discussing how the Sage macOS problems may be

mitigated, but not here and now.

I don't think it's off-topic to once again point out that this way of phrasing it is very developer-centric.  That's not a wrong way to look at it, but an end-user-centric way of looking at it is also valid.  And these are largely using Sage on Mac (without knowing about things like brew or conda, nor really wanting to) or even Windows (where not even these options exist, but people seem content to download whatever older version still is available - and they do).  Let's ignore the cloud solutions available for now, since I still suspect that for "ordinary" solo uses this is not as significant a factor (as opposed to collaborative ones).

So somewhere on sage-devel (probably not this thread) it would be really helpful for people *other* than the two or four primary "representatives" of Camps A and B to explain the vision of Camps A and B regarding both developers and end users.  Because the developer time/bloat issue is real, and the end user not being able to use Sage issue is real (on Windows, at the very least, and it was nearly the case on Mac).

[Martin R]

I just followed a few of the links Matthias posted today, and I must admit that I do not understand a word.

Karl pointed out that:

> I don't think it's off-topic to once again point out that this way of phrasing it is very developer-centric.  That's not a wrong way to look at it, but an end-user-centric way of looking at it is also valid. 

It seems to me that "developer" here refers to a very different kind of developer than me, which is probably because I mostly care about getting my mathematics done and (probably because of that) use only linux.  I never had any severe build problems, although recently I have had some problems with TMPDIR.

I therefore wonder whether the outcome of the dispute might affect me, and if so, how - other than socially, which would be probably the most important thing anyway.  I am unable to answer the former question (i.e., would it affect me technically) by looking at the collection of links.

As an example: the introduction of the `# needs something` comments did affect me, and I don't see the benefit yet, but it is only a very minor annoyance, so I certainly won't argue, assuming that at least somebody is convinced that it's a good thing.

Best wishes,

Martin

[Matthias Koeppe]

Here's a friendly overview on 9 of the "disputed" PRs, to help potential volunteer editors find PRs that match their interests -- in case the community decides that this model of appointing editors is the way to go.

None of them has anything to do with "development philosophy", or with macOS; that's a false narrative. 

A. Positively reviewed, but held back by demands by 1 participant:

https://github.com/sagemath/sage/pull/36561

"pkgs/sage-conf: Move metadata from setup.cfg to pyproject.toml"

- Background reading: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/

- "Needs review" set on Oct 28, 2023.

- Positively reviewed by 1 reviewer on Nov 2, 2023.

- Another participant demands that it must be changed so that when merged into his open PR, that PR will work without change.

https://github.com/sagemath/sage/pull/36676

"Restructure sage.*.all for modularization, replace relative by absolute imports"

- Background reading: https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#testing-distribution-packages

- "Needs review" set on Nov 9, 2023.

- Positively reviewed by 1 reviewer on Nov 15, 2023.

- Another participant demands that it cannot be merged until the already documented design decision is reopened for a discussion.

https://github.com/sagemath/sage/pull/36726

"CI Linux: Replace use of pkill"

- Background reading: https://doc.sagemath.org/html/en/developer/portability_testing.html

- "Needs review" set on Nov 15, 2023.

- Positively reviewed by 3 reviewers, Nov 16 / Nov 23 / Dec 23, 2023

- TW: A senior developer uses frequent public displays of disrespect, makes false accusations, and makes insinuations about the intents of the PR author.

B. Stalled in "needs review" as author declines to address or respond to reviewer's comments

https://github.com/sagemath/sage/pull/36503

"Add config for ruff"

https://github.com/sagemath/sage/pull/36489

"Use meson instead of configure for conda install"

- PR author ends discussion with public display of disrespect.

https://github.com/sagemath/sage/pull/36524

"Compile everything with meson"

C. PR declares original author's work as unimportant/illegitimate and removes/obstructs it

https://github.com/sagemath/sage/pull/36941

"Reduce number of systems test with minimal config"

https://github.com/sagemath/sage/pull/36725

"Run ci-macos jobs in series"

https://github.com/sagemath/sage/pull/36923

Revert "gh-36678: CI conda: Ignore baseline test failures "

D. There are also Issues (not just PRs) marked as "disputed"; the search https://github.com/sagemath/sage/issues?q=sort%3Aupdated-desc+label%3Adisputed+ gives a broader picture of the problem of toxicity in our community. 

On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:

[Kwankyu Lee]

On Friday, January 12, 2024 at 6:38:31 PM UTC+9 Martin R wrote:

I just followed a few of the links Matthias posted today, and I must admit that I do not understand a word.

That is normal. Just imagine that you are a passenger on a cruise and happened to enter to the engine room of the ship by accident. 

I guess that there are few developers who have adequate understanding of all disputed PRs (perhaps none except the authors) . That is why I think appointing one editor to resolve all disputed PRs is not a realistic idea. A group of editors would be better. But then why not give the right to all developers?

For each of disputed PRs, there would be a few interested developers. I think majority voting by them is the way to go.

[Nils Bruin]

On Wednesday 10 January 2024 at 16:59:22 UTC-5 Dima Pasechnik wrote:

When it was discussed whether we wanted to use it, the main objection was that it needs root (once, explicitly, to set up, then implicitly), thus unsafe.
Conda was mentioned as a better option. But Conda is much bigger.

Conda is also multi-platform. A packaging of sagemath through conda is (or at least should be) usable on both linux and OSX. Doesn't that make it a more attractive target than homebrew?

Also, why not package sage in multiple ways if there's a taste for it? Like the packaging in linux distributions¸ it doesn't all need to be done by the core sage team, but probably at least one or a few should be, to guarantee that there's actually a way to get sage working for many people. As long as someone volunteers to maintain a packaging method, what's the downside of having it?

If there are people to maintain both homebrew and conda, can't we just do both?

[Dima Pasechnik]

One way or another, no faithful packaging of Sage the distro exists, besides Sage the distro itself.
The reason is that it's too big, too verbose with it's 400 packages, most of which are just unpatched PyPI packages, pinned to relatively random versions, providing Python, Jupyter and Sphinx, and common libraries and tools like zip and patch.

Successful packing of Sage (by Gentoo, by Void, by Arch, by Conda) is packaging sagelib, and relying on the rest of the environment to provide what can be provided with a reasonable effort.

Today I received a message from a Sage contributor urging to consider forking sagelib, even mentioning possible funding for such an effort, with the primary goal to make it easy to package by Linux et al. distros.
I think a similar goal can be accomplished with less effort, e.g. by splitting the main Sage repo into sagelib and sage the distro.
I hope there is still a room for consensus, before a "hostile" fork happens.

And to pre-empt the question "but who will work on sage the distro", I can answer now: these who want to work on it. Don't force people who don't need it into working on it, just cause we have a monorepo, and only release it as a whole, and there won't be conflicts.

E.g. you want to package in Sage the distro Python packages which use Rust (it's getting more and more popular) - fine, you can have fun doing it, but I wouldn't participate in it.

E.g. you want to figure out the minimum numbers of packages you need from an old OS in order to build all of Sage - fine, but it should not slow down sagelib development, and should not be a consideration on how sagelib is developed (so e.g. dropping old Python versions should happen faster,  it should not be dictated by the fact that a CI for this old OS and old python is already there).

[kcrisman]

> I don't think it's off-topic to once again point out that this way of phrasing it is very developer-centric.  That's not a wrong way to look at it, but an end-user-centric way of looking at it is also valid. 

It seems to me that "developer" here refers to a very different kind of developer than me, which is probably because I mostly care about getting my mathematics done and (probably because of that) use only linux.  I never had any severe build problems, although recently I have had some problems with TMPDIR.

When I say "developer-centric", you probably are already in this category, since you have quite a bit of expertise and also do development work with FriCAS (if I recall correctly?).  Anyone building from scratch more than once would probably count in this category :-) but you are right that especially those dealing with the non-mathematical part of the build are most impacted by this disagreement.

When I think of "user-centric",  I'm thinking more about the mathematicians John Cremona has helped install Sage, often laboriously, or the people that the 3_manifolds project create the Mac binary for, or (especially) people wanting to use Sage to help them with their undergraduate teaching and their research at the same time.   People who are not particularly likely to use Github, even if they happen to have an account, people who might not mind a command line to do math, but don't want to mess with things like homebrew or conda or whatever on a work-owned system.  (And yes, also people wanting to apt-get Sage, maybe with the AIMS desktop?)

My thinking is (as ever) in terms of potential users, not just the already committed.  Sage as such has distinct benefits over "just a Python library" in similar ways that M* does.  That doesn't mean we should stick with any particular model, but making sure it's not a big roadblock to people creating end-user output is key. 

[Matthias Koeppe]

Hi Volker, William,

On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:

1. There are over 20 pull requests labeled as "disputed" [1]. To
resolve these pull requests, we will be appointing an editor with no
direct involvement in the pull request to make a judgement call on
that particular pull request. We will then fully support the
decision of this editor. If you have the time to be the (possibly
anonymous) editor for a disputed pull request, please email us
(wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to
our list.

I think we need to know at least some rough indication on the intended timeline of this proposed process.

By when should volunteer editors sign up?

How and when will it be determined whether the community supports this proposed process?

And by when is it intended to resolve the "disputed PRs"?

Also the previous iteration, "Policy for disputed PRs" (David Roe's sage-devel post of Nov 24, 2023, https://groups.google.com/g/sage-devel/c/rDM3WDHnJkM/m/THAxmGDXAQAJ) did not have any indication of a timeline; and I have not received any response to my question regarding the timeline in my post of Dec 30, 2023, https://groups.google.com/g/sage-devel/c/rDM3WDHnJkM/m/x_r7Ly5dAQAJ

As I noted in my post https://groups.google.com/g/sage-devel/c/XON6NTJa33o/m/6AOs-NDSBAAJ (overview on 9 "disputed PRs"), one of the affected PRs has been waiting to be merged since Nov 2, 2023.

[Volker Braun]

On Saturday, January 13, 2024 at 1:19:52 PM UTC-5 Matthias Koeppe wrote:

I think we need to know at least some rough indication on the intended timeline of this proposed process.

My offer would be that I get it started (i.e. serve as the editor on the first batch of disputed tickets). Others will take over in the future if need be (though ideally its not needed, of course)

The timeline is then 1) editor makes decision to approve or decline and 2) done! 

Note: I'm on holiday this week

[Matthias Koeppe]

On Wednesday, January 10, 2024 at 11:37:59 AM UTC-8 Matthias Koeppe wrote:

I think we should start with electing a new sage-abuse committee that is willing to publicly affirm and enforce the Code of Conduct. I would suggest that nominations (including self-nominations) be sent to this list by Jan 24.

The new committee should work with the community to clarify the Code of Conduct and spell out its procedures and the range of sanctions that it will consider (see https://github.com/sagemath/sage/pull/36844).

I went back to the record of the discussions and have collected some background on the history of our CoC and of the sage-abuse committee, which goes back to a crisis in 2014.

Here are some quotes from the 2014 discussion that led to the adoption of the CoC that I found particularly valuable. (It is my personal selection, without attempting to be representative for the whole discussion.) 

====== 2014

"What will be the background of the 'group administrators', and the people who receive posts from sage-...@googlegroups.com? Are these people going to have a background in human resources and/or be trained in this area?" (Kirkby 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/3h9NqOv7f-oJ

"We were asked to vote whether this code of conduct should be introduced, yet it seems illogical to vote when the makeup of the administrators and those reading sage-abuse are not stated. Things that come to mind are: 1) Are the administrators and readers of sage-abuse going to be professionally trained to handle such situations? 2) Is it going to be a sub-set of sage developers, and if so who chooses them?" (Kirkby 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/V3OMJ-5IjzcJ

"Maybe there should be an intervention team of "senior" community people to sort this out: [....] But who are those and how do they gain authority?" (Schilly 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/YViwtFFw3AcJ

"I agree deciding who the intervention team is is an important question." (Schilling 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/B29tL_ynho8J

"Given the potentially political nature of such a choice, one possibility is to do something apolitical, and select based on ownership. In particular, based on lines of code contributed to Sage ... 1. Create a private mailing list called sage-abuse with these people as members. ... For now, the sage-abuse group would have exactly one duty, which is to ensure that discussions get moved to sage-flame when requested. That's it. We would give this a try for 6 months, and only then revisit whether the group should expand its duties or be dissolved." (Stein 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/ZU3iZiZVx44J

"we could do this list of by self nomination and see if this leads to anything. We could call this the "community management team" and initially it consists of at least 5 self-nominated individuals, who didn't face some strong objections. Of course, it is a problem to communicate objections against someone in such a role directly. Maybe there should be some kind of voting, where each of those 5 need at least 5 who aren't nominated but "vouch" for them to get support in the community." (Schilly 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/UKDqdGd436QJ

"In situations where it looks like real abuse has occurred, a committee of arbiters should exist to rule on it. Otherwise, we're left with mob rule and the onlooker effect (where nobody speaks up to stop abuse, assuming somebody else will take care of it)." (Boothby 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/B6uQyDiI0g4J

"[...] mentioned many times that "don't feed the troll" was the right thing to do. In my opinion, it is not quite enough. Let's say you receive a personal attack on a thread if you leave it just there, it's not helping you:
* the thread was probably started on a real question that you still want to discuss. You can start another thread but you might be afraid that the attack just occurs again.
* you leave a public attack to you unanswered on a public forum, I find it difficult to do.
* if you say nothing to the other person, you might give him/her the idea that he/she was right to do so. (And also maybe future readers, speaking of "giving the good example")" (Pons 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/ydJCmWyo3KYJ

"laws that can't/won't be enforced only encourage scofflaws." (Perry 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/R_6M2JikNGMJ

"pointing to the code makes it clear that I am not making a request on behalf of myself,
rather on behalf of the entire community." (Bradshaw 2014) https://groups.google.com/g/sage-devel/c/iGxa2F01rFc/m/6K1mgi0H2_sJ

"the whole conundrum is not about one person having a bad day, but repeated behaviors that many different people perceive as offensive and are turned away by. That, to a community of volunteers, is dangerous! It is counterproductive and takes a lot of positive energy away. [...] the situation where someone opens a thread to discuss something, but then gets attacked and/or the discussion disintegrates. Then what do you do if you still want to discuss these issues?" (Schilling 2014) https://groups.google.com/g/sage-devel/c/voyJJG2qNTE/m/npla6isgTu8J

"There were questions [...] about who exactly would deal with sage-abuse complaints and how. If you do not trust that we Sage developers can responsibly select people to be on that list, and that those members can find ways to sort out issues on a case-by-case basis, then you may vote "no" to this proposal. We are mostly not lawyers or politicians and are not going to make things more precise in this code regarding composition of the group or specific sanctions." (Stein, VOTE: code of conduct, 2014) https://groups.google.com/g/sage-devel/c/dR3_eyIUyac/m/LyALpiLcHuQJ

"I created [sage-abuse list].  The members are me, David Joyner (sage Dev #2), and Harald Schilly. [...] Anybody can post to the list.  It can be used for other things besides just the code of conduct, e.g., copyright issues, etc.  Frequently people just email me directly when they feel abused as a result of the sage project, so this will be better." (William Stein 2014) https://groups.google.com/g/sage-devel/c/Zeyin-3-gjg/m/L9fHX0EeOvwJ

"[Responding to message by S. King] If you - as a long time sage dev - would like to be an admin on the list to help make our perspective more diverse, let me know and we will add you." (Stein 2014) https://groups.google.com/g/sage-devel/c/Zeyin-3-gjg/m/uzBNUdLbG2IJ

====== 2014

What I found striking in re-reading the discussion from 10 years ago is how it predates today's common knowledge and awareness about the damage that toxicity in the online realm is inflicting, on a daily basis, on our personal lives and the public and political sphere. 

After the adoption of the CoC in 2014 (and the attempts to refine the text of the CoC in the weeks after, traces of which can be seen at https://wiki.sagemath.org/Community?action=show&redirect=CodeOfConduct), there appears to have been very little discussion of the topic. I have only found the following, from 2016.

====== 2016

"[Responding to 'Should we start a process of nominating/electing moderators?'] Before that, we should decide what the process is. That's something that might be complicated to do via email (remember what happened with the code of conduct). In my opinion, a Sage Days completely dedicated to this kind of issues would be a better venue to have this kind of discussion, provided we manage to get enough people to come. (Luca De Feo 2016) https://groups.google.com/g/sage-devel/c/EAngC-bmZWY/m/gVW7GD2bBQAJ

====== 2016

I made the Code of Conduct more visible by adding it to the repository in https://github.com/sagemath/sage/issues/33565 (March/April 2022). This prompted an update of the sage-abuse admin list, https://github.com/sagemath/sage/issues/33565#issuecomment-1418167864

[Matthias Koeppe]

On Sunday, January 14, 2024 at 6:10:53 AM UTC-8 Volker Braun wrote:

On Saturday, January 13, 2024 at 1:19:52 PM UTC-5 Matthias Koeppe wrote:

I think we need to know at least some rough indication on the intended timeline of this proposed process.

My offer would be that I get it started (i.e. serve as the editor on the first batch of disputed tickets).

Thanks, and I'd think that in your role as the project's Release Manager you can already just do this. 

I don't think that this requires creating a new role.

[Matthias Koeppe]

On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:

the main act of censure that the sage-abuse committee will be
taking going forward will be to delete comments (on github and mailing
lists) that violate the code of conduct.

William, Volker, I've already shared privately in great detail why this is insufficient.

But even this decidedly narrow scope -- is anyone taking care of it at all?

Is https://groups.google.com/g/sage-abuse attended?

And if so, may we know who's on the committee?

Asking on behalf of the community.

Matthias

[David Roe]

On Thu, Feb 22, 2024 at 9:11 PM Matthias Koeppe <matthia...@gmail.com> wrote:

On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote:

the main act of censure that the sage-abuse committee will be
taking going forward will be to delete comments (on github and mailing
lists) that violate the code of conduct.

William, Volker, I've already shared privately in great detail why this is insufficient.

But even this decidedly narrow scope -- is anyone taking care of it at all?

Is https://groups.google.com/g/sage-abuse attended?

I can confirm that the google group list does receive messages.

 

And if so, may we know who's on the committee?

Asking on behalf of the community.

The members of the committee are:

* William Stein

* Vincent Delecroix

* David Joyner

* Harald Schilly

* John Palmieri

* David Roe

The membership of the committee has been unchanged for years, and some of us are no longer very involved in Sage development.  We are meeting early next week in order to discuss some of the recent issues, and I welcome comments or suggestions, which you can send publicly or to me in private.

David

 

Matthias

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/89d80d9a-e991-4a0f-91d7-cfe5bc2b914en%40googlegroups.com.