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). On Saturday, March 2, 2024 at 2:17:59 AM UTC+8 John H Palmieri wrote: > 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/bc056bc5-ed90-4305-a233-67561fc8cb8dn%40googlegroups.com.
