Urgent: Please vote on these "disputed" PRs

[Matthias Koeppe]

Dear Sage developers,

I need your help on these PRs. Please vote. 

Special expertise is not required for voting. You will find the comments in these PRs instructive -- also as illustration for a (long overdue) discussion about governance and review standards in the Sage project.

1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 and https://github.com/sagemath/sage/pull/37138 ("Move metadata from setup.cfg to pyproject.toml").

These are trivial "chore" PRs. They update metadata of our pip-installable packages "sage-conf" and "sagemath-standard" to the latest format.

These straightforward and appropriately focused PRs have been held back by months by bundling the review of the PRs with unrelated issues. I call this "artificial friction"; see the discussion in the PRs. To help overcome this artificial friction, please vote.

2. Please vote -1 on both https://github.com/sagemath/sage/pull/37387 and https://github.com/sagemath/sage/pull/36951. These PRs are about a Developer Experience issue, namely the workflow on GitHub that notifies developers when the HTML documentation is ready for inspection by PR author and reviewers. Now a few developers have made it known that they are annoyed by the notifications (whether received by email or the notification tool on the GitHub website), and the PRs seek to turn off most or all of the notifications. That these notifications enable a productive notification-driven development style, and that the notifications serve the project's need for quality control on the formatted documentation, has not received meaningful consideration.

What's happening on these PRs is exactly what I had cautioned about in https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873 regarding the (then-proposed, now established) system of majority votes as a conflict resolution mechanism for PRs. To balance it, we need the involvement of the larger developer community: please vote.

Matthias

[Gareth Ma]

Dear Sage developers,

Note that https://github.com/sagemath/sage/pull/37740 is an alternative to https://github.com/sagemath/sage/pull/37387, so people reading this thread should also vote on that. It's a quick read and an easy to understand issue.

A picture is worth a thousand words, so here's a thousand words:

I will add some of my thoughts that led me to +1 both/either of these two PRs:

1. Other big projects also uses the "one notification" system, e.g. SymPy for their benchmarks and SymPy bot. Mathlib (kind of) uses a "zero notification" system, which is also suggested in the PRs above;

2. To me and most average Sage developers who has contributed more than twice, we pretty much know what the docstring should look like in code, and in case of mistakes the reviewers should catch that by checking the (still as easily accessible) built documentations during review stage. So "quality control on the formatted documentations" isn't affected at all;

2.5. I doubt many people use a notification-driven development style that requires constantly checking the built documentations. That's only required when there are large nontrivial changes to the docs, and for people that write math Sage code that's usually not the case;

3. The "notifications" are not just email notifications, but also GitHub notifications. This means the solution proposed by Kwankyu (who is one of the -1) doesn't solve the problem;

For statistics, I received 282 emails from github-actions[bot] this year despite barely being active, sometimes just by me leaving a comment on a PR that I don't work on/review actively, and approximately 282 of them are pure noise to me.

---

Also, I am confused about your call to vote -1 on https://github.com/sagemath/sage/pull/36951. That's your own PR, you voted +1 on it yourself, and put positive review on it yourself after counting votes (3 to 1). Did you link a wrong PR?

[Dima Pasechnik]

On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe <matthia...@gmail.com> wrote:

I need your help on these PRs. Please vote. 

Special expertise is not required for voting. You will find the comments in these PRs instructive -- also as illustration for a (long overdue) discussion about governance and review standards in the Sage project.

1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 and https://github.com/sagemath/sage/pull/37138 ("Move metadata from setup.cfg to pyproject.toml").

These are trivial "chore" PRs. They update metadata of our pip-installable packages "sage-conf" and "sagemath-standard" to the latest format.

These straightforward and appropriately focused PRs have been held back by months by bundling the review of the PRs with unrelated issues. I call this "artificial friction"; see the discussion in the PRs. To help overcome this artificial friction, please vote.

This is not true - the friction is not artificial. It is due to legitimate concerns of developers who are not interested in

spending all of their time on ever growing "Sage the distribution", and/or who see little merit in Matthias' sagelib modulalisation

project, which uses Python features (most of all, namespace packages)

not universally supported by a number of important tools, such as  Cython and pytest.

Please vote -1 on these two PRs (there are more similar PRs around). This will force Matthias to reconsider his priorities, and enable

other voices to be heard. So far, Matthias refuses to reassess the priorities of the project - instead he puts away

the criticism as "abuse" directed at him.

As a result of this friction, a number of developers have left or about to leave the project, or are discussing

creation of a hard fork of Sage. 

In particular, I think it is urgent to re-access the need for sagelib modularisation in its current form.

It appears to be harming the project, and its benefits are questionable.

As well, it's urgent to make Sage more modular on the level of Sage the distribution - the "interesting" part, sagelib,

is getting increasingly entangled in Sage the distribution (which is just a constantly growing pile of Jupyter, Python, ans Sphinx-related

packages, which Matthias and few others are all too keen on hoarding). 

This in particular makes Sage harder and harder to package for Linux, and other, distributions (Packaging of Sage for Debian/Ubuntu and

Fedora has been stalled for years already).

2. Please vote -1 on both https://github.com/sagemath/sage/pull/37387 and https://github.com/sagemath/sage/pull/36951. These PRs are about a Developer Experience issue, namely the workflow on GitHub that notifies developers when the HTML documentation is ready for inspection by PR author and reviewers. Now a few developers have made it known that they are annoyed by the notifications (whether received by email or the notification tool on the GitHub website), and the PRs seek to turn off most or all of the notifications. That these notifications enable a productive notification-driven development style, and that the notifications serve the project's need for quality control on the formatted documentation, has not received meaningful consideration.

We are not an enterprise with full-time developers 24 hours a day ready to react to these endless notifications.

They are spam for almost everyone, and should be turned off.

Please, please vote +1 on them.

What's happening on these PRs is exactly what I had cautioned about in https://github.com/sagemath/sage/pull/36726#issuecomment-1820148873 regarding the (then-proposed, now established) system of majority votes as a conflict resolution mechanism for PRs. To balance it, we need the involvement of the larger developer community: please vote.

No, what we really need is an honest general discussion on directions the project is taking.

Right now it's going  nowhere, to ever growing pile of bugs noone even talks about addressing (e.g. Pynac; Maxima;

memory leaks related to Singular; etc etc), to huge package bloat, etc.

Dima

[Matthias Koeppe]

Thanks to Gareth Ma for pointing out that I got some links wrong. I'll try again:

1. Please vote +1 on https://github.com/sagemath/sage/pull/36561 and https://github.com/sagemath/sage/pull/36951 ("Move metadata from setup.cfg to pyproject.toml"). Straightforward PRs, held back since November/December by hostile demands that have nothing to do with our standards of review.

2. Please vote -1 on https://github.com/sagemath/sage/pull/37387 and https://github.com/sagemath/sage/pull/37740 (documentation preview notifications).

I've got some more requests:

3. Please vote +1 on https://github.com/sagemath/sage/pull/37351 ("update Linux platforms"). An update of our CI, which among other things will make workflows such as Build&Test and Docbuild faster. 

4. Please vote -1 on https://github.com/sagemath/sage/pull/36580, https://github.com/sagemath/sage/pull/36753, and https://github.com/sagemath/sage/pull/37138, which attempt to obstruct the modularization project and the mechanism for the distribution on PyPI.

5. Please vote +1 on https://github.com/sagemath/sage/pull/36869, for completing the support for Python 3.12.

6. Please vote -1 on https://github.com/sagemath/sage/pull/36725, https://github.com/sagemath/sage/pull/36610, which attempt to sabotage the portability testing infrastructure that I built for Sage.

[Nils Bruin]

Thank you, Matthias, for drawing attention to votes on tickets that have gained "disputed" state and were not getting much attention. If we're going to decide these tickets by voting, then having a more representative voting population should help in getting a more representative result.

Thank you, Dima and Gareth for providing opposing opinions to Matthias' interpretation of the matter. These are "disputed" tickets after all, so in the discussions of these tickets no arguments arose that convinced all sides on the best road forward. It makes sense that potential voters receive "campaign materials" from all sides.

I am happy to see Matthias and Dima agreeing that this voting procedure has draw-backs. It's only meant as a band-aid solution to get items unstuck in the absence of consensus. Shall we just give it a try? It may not lead to technically optimal solutions in all cases, but at least it's a procedure that is easily seen as "fair". None of the decisions made are definitive -- perhaps finding consensus on a different solution is easier once another has been tried and new patches can be made.

I think Dima has a good point that a clearer roadmap for sagemath would probably help in making it easier to reach consensus instead. A technical committee with some authority could help, but only if they can reach consensus. From my perspective as a member of the CoC committee, I would urge the community to have a bit of patience. We are making our way through a backlog of issues that quite probably have a root cause in lack of agreed-upon direction in the sagemath project and we do hope to come with some recommendations for improving the situation in the near future.

I am writing this as a community member, but informed by my service on the CoCC and a desire to not see the workload of the CoCC increase.

Nils

[Nils Bruin]

Dima,

I am writing as a member of the Code of Conduct concerning one particular phrase from your message https://groups.google.com/g/sage-devel/c/Wjw2wcvgf8k/m/ynwiz66_AQAJ :

> This will force Matthias to reconsider his priorities, and enable other voices to be heard. So far, Matthias refuses to reassess the priorities of the project - instead he puts away the criticism as "abuse" directed at him.

Such allegations will have no effect other than to antagonize the other party. This is not helpful in fostering constructive debate. Please keep this thread to a simple explanation of the issues at hand, so that interested community members can make an informed decision on their vote (or on whether to vote at all).

Sincerely,

Nils, on behalf of the code of conduct committee.

[Kwankyu Lee]

Hi,

Reviewing a PR is a technical work, but voting on a disputed PR has a political element. So I want to make a political remark concerning most of the disputed PRs.

The modularization project (making pip-installation packages that contain portions of the sage library) started years ago with a general consensus of the sage community. Matthias led the project and did most of hard works. Many others did not care much about the project and still do not feel the impact except when encountered with the (annoying) "# needs ..." tags.

Matthias is also managing much of the sage build system and the CI (mostly testing infrastructure) on github, partly to support the modularization project. Many of us would appreciate that.

Certainly Matthias is not an appointed dictator ruling the developers, but I think we should at least acknowledge the leading role of him in the area of his expertise. On technical discussions on PRs, we should give more weight on his opinions from his expertise.

I hope that you decide your vote by weighing the conflicting arguments on the issues.

Kwankyu

[Dima Pasechnik]

I think I will quit the Sage project as soon as decisions on technical merits of PRs and issues will start to be taken in a nakedly political way.

I am very strongly against any political overtones in  these matters - it reminds me all too well what's wrong is in academia in general.

Dima

[Martin R]

Please don't!

Martin

[julian...@fsfe.org]

Matthias,

We have carefully reviewed the arguments people have brought for and against the disputed PRs and find it credible that both sides have genuine concerns. We therefore disagree with characterizing opposing opinions as “artificial friction”, “hostile demands”, or an “attempt to sabotage”.

Such allegations will have no effect other than to antagonize the other party. This is not helpful in fostering constructive debate. Please keep this thread to a simple explanation of the issues at hand, so that interested community members can make an informed decision on their vote (or on whether to vote at all).

The Code of Conduct Committee

[kcrisman]

Please don't!

+1 for sure

> The modularization project (making pip-installation packages that contain portions of the sage library) started years ago with a general consensus of the sage community. Matthias led the project and did most of hard works. Many others did not care much about the project and still do not feel the impact except when encountered with the (annoying) "# needs ..." tags.  Matthias is also managing much of the sage build system and the CI (mostly testing infrastructure) on github, partly to support the modularization project. Many of us would appreciate that.

Also +1 for sure

> Such allegations will have no effect other than to antagonize the other party. This is not helpful in fostering constructive debate. Please keep this thread to a simple explanation of the issues at hand, so that interested community members can make an informed decision on their vote (or on whether to vote at all).

+1 to both times this was said (even though I'm violating "issues at hand" with this comment)

It's worth noting that "whether to vote at all" is, as typical in Sage, mostly being honored by not voting.  Trac was similar - it was often hard to get people to review even simple tickets that weren't squarely in people's domain of experience within the vast Sage library.  For those of us who don't really know that much about .toml files, packaging, or modularization, we would like to trust that some roadmap that addresses all concerns *in an acceptable, if quite imperfect, compromise* can be come up with by those who *do* have expertise in those matters.  

But they'll have to ignore the personal/political matter, hard as it might be.  *Even if it's true* that there is "sabotage" or "refusing to assess" (which this post remains neutral on), if it is *possible* to interpret a code change request as being well-intentioned and helping some aspect of packaging, then that should be done.  Until such time as another Sage Days *in person* could be held on a topic like packaging, the best operating procedure for online-only discussions is to give the most charitable possible interpretation to a given code request - and refrain from any comments that imply ill will on the part of another, *even if you think there is ill will*.  (Then the truly ill willed statements will be clear, at least, instead of currently sometimes being themselves ambiguous.)

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:

We have carefully reviewed [...]

We therefore disagree with characterizing opposing opinions as “artificial friction”, “hostile demands”, or an “attempt to sabotage”.
Such allegations will have no effect other than to antagonize the other party. This is not helpful in fostering constructive debate.

Julian, please, that's highly inappropriate. I'm not characterizing opposing *opinions*.

With this terminology I'm describing the modes of existing, persistent, non-constructive *actions* on these PRs by others.

These are not "allegations"; what I am describing has been happening in plain sight, is fully documented, and has been reported to the sage-abuse and CoCC committees. As you know, some of these have already led to sanctions by the committees, while I am still waiting for acknowledgment (and clear actions) regarding numerous reported violations of our code of conduct (and reviewing code) by the current committee.

I do understand that the new committee is still learning how to recognize and handle abuse; it's a complicated and challenging topic to master. In the meantime, as I have asked the committee in private already, more thoughtful restraint in issuing public reprimands is necessary.

[Matthias Koeppe]

On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:

On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe <matthia...@gmail.com> wrote:

 You will find the comments in these PRs instructive -- also as illustration for a (long overdue) discussion about governance and review standards in the Sage project.

1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561 and https://github.com/sagemath/sage/pull/37138 ("Move metadata from setup.cfg to pyproject.toml").

These are trivial "chore" PRs. They update metadata of our pip-installable packages "sage-conf" and "sagemath-standard" to the latest format.

These straightforward and appropriately focused PRs have been held back by months by bundling the review of the PRs with unrelated issues. I call this "artificial friction"; see the discussion in the PRs. To help overcome this artificial friction, please vote.

This is not true - the friction is not artificial. It is due to legitimate concerns of developers who are not interested in

spending all of their time on ever growing "Sage the distribution", and/or who see little merit in Matthias' sagelib modulalisation

project, which uses Python features (most of all, namespace packages)

not universally supported by a number of important tools, such as  Cython and pytest.

Please vote -1 on these two PRs (there are more similar PRs around). This will force Matthias to reconsider his priorities [...]

What Dima is describing here is exactly the inappropriate bundling that I have called out. It's a violation of our standards of review.

As majority voting on PRs is our current conflict resolution mechanism: All, please vote.

[Dima Pasechnik]

On 10 April 2024 21:50:43 CEST, Matthias Koeppe <matthia...@gmail.com> wrote:
>On Monday, April 8, 2024 at 5:19:02 PM UTC-7 Dima Pasechnik wrote:
>
>On Mon, Apr 8, 2024 at 7:19 PM Matthias Koeppe <matthia...@gmail.com> wrote:
>
> You will find the comments in these PRs instructive -- also as

>illustration for a (long overdue) *discussion about governance and review
>standards* in the Sage project.
>
>
>*1. Please vote +1 on both https://github.com/sagemath/sage/pull/36561

><https://github.com/sagemath/sage/pull/36561> and
>https://github.com/sagemath/sage/pull/37138

><https://github.com/sagemath/sage/pull/37138>* ("Move metadata from

>setup.cfg to pyproject.toml").
>These are trivial "chore" PRs. They update metadata of our pip-installable
>packages "sage-conf" and "sagemath-standard" to the latest format.
>These straightforward and appropriately focused PRs have been held back by

>months by *bundling the review of the PRs with unrelated issues.* I call

>this "artificial friction"; see the discussion in the PRs. To help overcome
>this artificial friction, please vote.
>
>
>This is not true - the friction is not artificial. It is due to legitimate
>concerns of developers who are not interested in
>spending all of their time on ever growing "Sage the distribution", and/or
>who see little merit in Matthias' sagelib modulalisation
>project, which uses Python features (most of all, namespace packages)
>not universally supported by a number of important tools, such as Cython
>and pytest.
>
>Please vote -1 on these two PRs (there are more similar PRs around). This
>will force Matthias to reconsider his priorities [...]
>
>
>What Dima is describing here is exactly the inappropriate bundling that I
>have called out.

There seems to be nothing else, short of a project fork, to make Matthias reconsider.

> It's a violation of our standards of review.

By calling out for a mass vote you have essentially asked for such a violation.

Otherwise the whole thing about designing PRs by massive voting is a massive waste of developers' time, as normal reviewing can be a time-consuming process, in particular if the PR concerns a not a very familiar topic.

>
>As majority voting on PRs is our current conflict resolution mechanism:
>All, please vote.
>

So what exactly are you asking for? For reviews, or for massive violation of our reviewing standards?

Dima

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 6:14 PM Matthias Koeppe <matthia...@gmail.com> wrote:

On Wednesday, April 10, 2024 at 6:49:11 AM UTC-7 julian...@fsfe.org wrote:

We have carefully reviewed [...]

We therefore disagree with characterizing opposing opinions as “artificial friction”, “hostile demands”, or an “attempt to sabotage”.
Such allegations will have no effect other than to antagonize the other party. This is not helpful in fostering constructive debate.

Julian, please, that's highly inappropriate. I'm not characterizing opposing *opinions*.

Matthias, you keep characterizing my input into discussions as "persistent abusive conduct", see e.g. your

https://github.com/sagemath/sage/pull/36676#issuecomment-2048352139

I demand a public apology, and a lift of the block on GitHub.

Else Matthias should be banned from SageMath for a while, if not 

permanently. Enough is enough.

Dima

  

With this terminology I'm describing the modes of existing, persistent, non-constructive *actions* on these PRs by others.

These are not "allegations"; what I am describing has been happening in plain sight, is fully documented, and has been reported to the sage-abuse and CoCC committees. As you know, some of these have already led to sanctions by the committees, while I am still waiting for acknowledgment (and clear actions) regarding numerous reported violations of our code of conduct (and reviewing code) by the current committee.

I do understand that the new committee is still learning how to recognize and handle abuse; it's a complicated and challenging topic to master. In the meantime, as I have asked the committee in private already, more thoughtful restraint in issuing public reprimands is necessary.

--
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/2bdbf209-edc2-4a0d-9b4c-de1c665d406bn%40googlegroups.com.

[Matthias Koeppe]

Reported.

[Tobia...@gmx.de]

> 4. Please vote -1 on https://github.com/sagemath/sage/pull/36580, https://github.com/sagemath/sage/pull/36753, and https://github.com/sagemath/sage/pull/37138, which attempt to obstruct the modularization project and the mechanism for the distribution on PyPI.

Please refrain from such unfounded and wrong accusations. The purpose of these PRs is to solve concrete problems. If there are conflicts with the modularization project, we can discuss these technical questions and try to find a solution (perhaps by changing the PR, or by slightly changing the design of the modularization distributions). Please also don't use the modularization project as a political tool to prevent PR from being merged. For example in https://github.com/sagemath/sage/pull/36753 you claim that it conflicts with the modularization project (and this is then cited by others as the reason for their -1) but so far you have not given a single example where the CI or some documented behavior is actually broken (you only have given slight change in behavior in an artificial edge case).

I would also kindly ask the developers working on https://github.com/sagemath/sage/pull/36676 to not consider the vote on this PR as a vote on the question weather we should proceed with the whole modularization project. I'm actually a fan of the modularization and would like to see it come into reality. But that doesn't mean that one cannot question certain design choices in the modularization project. Concerning this particular PR, there is no technical need for the addition of these `all_xyz` files and multiple different solutions have to be proposed. Such technical question should be open for discussion, especially since they have not been discussed before (the general program has been discussed on the mailing list, but many details of the modularization project have not). So please let's try to not load the discussion by unnecessary politics.

[David Roe]

We have received messages from several people that the level of discord on display between Dima and Matthias makes them feel uncomfortable participating on this email list. To protect the community from this acrimony, we are for now restricting Dima and Matthias to moderated contributions on sage-devel.  We are sad in taking this step, and are continuing to work privately with both Dima and Matthias to resolve this conflict.

David

for the sage-conduct committee

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4ec2449a-90cc-479a-be88-723f7f9135cfn%40googlegroups.com.

[Matthias Koeppe]

I have asked David Roe to recuse himself from any further discussions/actions involving me in the CoCC.

The persistent refusal to make a distinction between *abusive conduct* and *calling out abuse* has caused too much damage already.

Matthias

[jplab]

Dear all,

The Code of Conduct Committee considered the issue and found no need for David to recuse himself as requested.

We would like to use this opportunity to clarify that messages sent by any of us and signed as “The Code of Conduct Committee” have been approved by the entire committee. The person sending that message is just the messenger, the one who volunteered to send the message at an agreed time.

Sincerely,

The Code of Conduct Committee

[julian...@fsfe.org]

On Wednesday, April 10, 2024 at 8:14:44 PM UTC+3 Matthias Koeppe wrote:

I do understand that the new committee is still learning how to recognize and handle abuse; it's a complicated and challenging topic to master. In the meantime, as I have asked the committee in private already, more thoughtful restraint in issuing public reprimands is necessary.

 We are grateful for the trust that the community put into us in handling violations of our Code of Conduct. We will continue to enforce the Code of Conduct, privately, and when we deem it necessary, in public.

The SageMath Code of Conduct Committee