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 On Friday, March 1, 2024 at 9:41:31 AM UTC-8 Martin R wrote: > 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 > On Friday 1 March 2024 at 18:21:59 UTC+1 David Roe wrote: > >> 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 >> <https://groups.google.com/g/sage-devel/c/XDvKkMRoDk4/m/0yrtdKkGAwAJ>), >> I think adding something like this would be appropriate. >> 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1eb0a4b7-931d-4018-a935-b71507db1939n%40googlegroups.com.
