Sage's Code of Conduct: proposed changes

[John H Palmieri]

Dear colleagues,

I am working on some changes to Sage's Code of Conduct, and I am asking for comments. Once the draft has stabilized, then we will hold a vote on sage-devel to approve (or not) the changes. Please visit https://github.com/sagemath/sage/pull/37501 to see the proposal.

The current Code of Conduct was approved by a vote in sage-devel almost 10 years ago. My intention is not to alter the core principles in the Code of Conduct, but instead to add more details: for example, how should you report a possible violation, what are possible consequences if the Sage Code of Conduct Committee (what has until now been called the Sage Abuse Committee) finds that a violation occurred, how to amend the document, etc. The changes are based in large part on similar documents from SciPy and NumFOCUS: we are not reinventing the wheel.

As such, I hope that the proposed changes are (a) not controversial, and (b) a clear improvement. I could certainly be wrong about either of these, but I will make this suggestion: if you agree with me about (a) and (b) and you also want to propose changes that are potentially more controversial, then I would ask that you make that proposal separately so that the Sage community can vote on it separately, and the changes can be merged independently of each other.

Please take a look and leave comments on the PR.

--

John

[Martin R]

I would like to ask whether we might want to add some of the following to the code of conduct, I could not find it covered there.

I admit that it is unclear to me whether the discussion should be on pull requests only.  I don't want to add the following to John's pull request, because it definitely doesn't belong there.  Opening another one makes things even harder to follow, so I'm trying to be brave.

I imagine that the issues below may be cultural things, so I would perfectly understand that all or some of it is perfectly OK in some communities, and therefore should not be part of the sage code of conduct.

I also admit that some of the issues below are attitudes that make it hard for me to work on sage.  There were some situations in which I would possibly have stopped contributing to sage, if sage wasn't a professional necessity for me.

0. sage is a community effort, and not the project of a single or even a few persons.  Try to not identify yourself with the code in sage.

1. It is not OK to judge somebody else's attempts to improve sage other than critisising it technically or casting a negative vote.  By contrast, emphasising the positive aspects and appreciating the effort is welcome.

2. It is not OK to emphasise oneselves contributions or stressing that one has been right.  By contrast, it is fine to express that one is happy or perhaps even proud to have solved a particular technical problem.

3. It is not OK to modify the description of a pull request or issue of somebody else without explicit permission, ideally on the ticket so that the permission is visible to all readers.

4. It is not OK to change a pull request to "positive review" if someone has already expressed explicitly that it shouldn't be merged, and there hasn't been a vote.

Comments and variations, but also saying that this should not be discussed for a particular reason: welcome!

Best wishes,

Martin

[David Roe]

Thank you for starting the conversation Martin.  I certainly think that all of these suggestions are appropriate to discuss, and that sage-devel is probably a better venue for discussion like this than the PR.

On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <sage-...@googlegroups.com> wrote:

I would like to ask whether we might want to add some of the following to the code of conduct, I could not find it covered there.

I admit that it is unclear to me whether the discussion should be on pull requests only.  I don't want to add the following to John's pull request, because it definitely doesn't belong there.  Opening another one makes things even harder to follow, so I'm trying to be brave.

I imagine that the issues below may be cultural things, so I would perfectly understand that all or some of it is perfectly OK in some communities, and therefore should not be part of the sage code of conduct.

I also admit that some of the issues below are attitudes that make it hard for me to work on sage.  There were some situations in which I would possibly have stopped contributing to sage, if sage wasn't a professional necessity for me.

I'm sorry to hear that there were situations like this.  If you think it would be helpful to describe them in more detail privately (even if you're not seeking any kind of action), feel free to write to the Code of Conduct committee.

 

Here are my thoughts on your suggestions.  I think that some of them should definitely be included, though it's not completely clear to me where (it feels awkward to add yet another enumerated list).

 

0. sage is a community effort, and not the project of a single or even a few persons.  Try to not identify yourself with the code in sage.

 

The community aspect of Sage is currently discussed in the introduction, and perhaps we can tweak that to incorporate this suggestion.  As for the second half, I don't understand how it fits into a code of conduct, since it seems aimed at internal processes (like how to cope if your code is removed from Sage), rather than behavior.

Currently our introduction is "The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code."  What do you feel is missing from this that you're trying to include?

 

1. It is not OK to judge somebody else's attempts to improve sage other than critisising it technically or casting a negative vote.  By contrast, emphasising the positive aspects and appreciating the effort is welcome.

I like the idea of including more about positivity, and this fits in with Guideline 2: "Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities."  Maybe we can append a sentence here like "When discussing contributions, endeavor to encourage positive aspects and avoid overly harsh criticism."

I do think there are cultural differences here, and personally I think restricting negative feedback to just voting and "technical" criticism goes too far, partly because I don't think technical is very clearly defined.  There are judgement calls to be made about what should be included into Sage, which are not always a matter of what method is technically superior.  I don't think we want to restrict developer's ability to offer negative feedback, but instead to encourage people to be positive and welcoming.  I'd like to hear other perspectives on this.

 

2. It is not OK to emphasise oneselves contributions or stressing that one has been right.  By contrast, it is fine to express that one is happy or perhaps even proud to have solved a particular technical problem.

I'm struggling to translate this idea into something concrete that I feel comfortable adding to the code of conduct.  I think it's important to allow people to get credit for the contributions that they've made to Sage, so I don't know what part of emphasizing your own contributions is problematic.  Similarly, I think it's too much to ask people to not claim that they are on the correct side of an argument if a discussion gets contentious.  Is there some other aspect of this kind of behavior that we might focus on?

 

3. It is not OK to modify the description of a pull request or issue of somebody else without explicit permission, ideally on the ticket so that the permission is visible to all readers.

I actually think that modifying someone else's pull request to clarify it, fix typos, or adjust it once the scope has changed is fine.  I'm curious what other people think, and what our community standard should be.  Martin, what aspects of this bother you?  Are there any kinds of modifications that you think are alright?

 

4. It is not OK to change a pull request to "positive review" if someone has already expressed explicitly that it shouldn't be merged, and there hasn't been a vote.

Once we settle on a process for managing disagreement about PRs (as we're discussing in this thread), I think adding something like this would be appropriate.

David

[Martin R]

Thank you for the thoughtful reply!  You gave me a lot to think about, and I'll do so over the weekend, rather than rushing.

Best,

Martin

[John H Palmieri]

There are suggestions along maybe similar lines at https://github.com/sagemath/sage/pull/36844, and I am trying to think of how we might incorporate your suggestions and the other ones. I've had the thought before about other documents (like our department's by-laws) that there should be two separate documents: the main one and then, separately, commentary (like the Talmud). These suggestions currently feel more like commentary to me, but one option would be to add a "commentary" section to the code of conduct.

--

John

[Tobia...@gmx.de]

I think Martin raises important points and agree that 0-4 should be added to the code of conduct (more in spirit than in this particular formulation; for example, I like the proposed reformulations of David). Point 5 is important as well, but I would say it's enough to spell out the rules governing labels in more detail in the developer documentation.

As a response to David's questions above (if I may share my perspective):

• "As for the second half, I don't understand how it fits into a code of conduct, since it seems aimed at internal processes (like how to cope if your code is removed from Sage), rather than behavior." - Problems arise if the identification with code is no longer only an internal view but does lead to observable behavior (eg blocking the removal of certain parts of the codebase).
  
• Since only admins/maintainers can actually edit PRs/issues (or push to PRs), this creates an imbalance of power and thus it should be clearly defined what actions are okay or which are not. Perhaps it's a good idea to even add a new section about the special rules applying to maintainer actions (in addition to edits, closing of issues and PRs would be a topic).
  

[Volker Braun]

Thanks for working on this, John!

I like that they are aspirational goals, being nice to each other shouldn't be that hard.

There are always going to be questions "what exactly is now allowed", but its impossible to enumerate everything. Is it OK to push to somebody else's branch, or change the issue description? Maybe. Surely fixing a typo is OK. But hijacking somebody else's issue to do something that wasn't intended by the author is not OK. Unless you talked about it first, and agreed on it. Then its OK again. Maybe you though the change was welcome, but it turns out it wasn't. Just be nice and reset the branch to the previous state, no harm done.

[Matthias Koeppe]

I think it's important to point out that a "Code of Conduct" is merely one document, of limited scope and purpose.

In particular it does not touch matters of governance of a project. 

Open source projects with very different governance structures can share the same Code of Conduct.

Questions such as "who can / should set status labels", "who can / should edit others' Issue/PR descriptions", etc. are primarily questions of governance, namely of roles in a project (and the associated duties and privileges of people in the role).

This is a discussion that the project also needs to have quite urgently, but I suggest to get to this after the vote on the Code of Conduct and the appointment of the new CoC committee.

Matthias

[David Roe]

I agree with both Tobias and Matthias that we should have a discussion about the roles of maintainers (since they have defined privileges on github) and changes to Sage's governance model more generally.  Martin and Tobias have commented on trying to include some additional principles into the code of conduct, and I've asked John to include my revised suggestion into the PR.  This doesn't currently address all of Martin's points, so if anyone has other concrete changes to suggest feel free to do it here or on the PR.

In the interest of moving forward, I'm planning on giving the PR positive review on Thursday.  Of course, additional changes are always possible through a discussion here if we find that there are more that we want to add.

David

--
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/432caff6-9fc6-4e0c-927f-e64c083bacacn%40googlegroups.com.

[seb....@gmail.com]

Personally I don't mind if a maintainer would correct my typos in the PR description (or something else according to Volker's white list). However, since this is a privileged action and we cannot be sure that everyone feels this way, I think this point should be addressed generally. Perhaps the Code of Conduct could specify that permissions for cloud services that are technically necessary to maintain the project should generally not be used for other purposes unless there is agreement from all affected persons.

[David Roe]

On Sun, Mar 10, 2024 at 1:44 PM seb....@gmail.com <seb....@gmail.com> wrote:

Personally I don't mind if a maintainer would correct my typos in the PR description (or something else according to Volker's white list). However, since this is a privileged action and we cannot be sure that everyone feels this way, I think this point should be addressed generally. Perhaps the Code of Conduct could specify that permissions for cloud services that are technically necessary to maintain the project should generally not be used for other purposes unless there is agreement from all affected persons.

One thing to note is that when you make a pull request on github you have the option to opt out of these kinds of changes by maintainers.  I think it's good to add pointers to this in our documentation about making and reviewing PRs, as well as clarify what kind of changes are acceptable.  I think I agree with Matthias' suggestion that these kinds of guidelines are better put in our reviewing code rather than the Code of Conduct, since they feel more like details than guiding principles.

David

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f0fb899b-9871-43b0-877e-00a9602520d2n%40googlegroups.com.