Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
> 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. -- 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/4db1774e-716e-436e-a30e-8397e80ae0bdn%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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. -- 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/78822461-092e-4a31-a3ed-075bc8e49ae2n%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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 On Thursday 11 January 2024 at 14:32:51 UTC+1 kcrisman wrote: > 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). > -- 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/ca61d246-0d99-4912-8c15-518de90d254an%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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). -- 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/34eb570c-6686-4ebd-b425-2d51a1371e11n%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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 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. -- 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/c989ac2e-51fd-4806-bf1e-5202375497ebn%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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. -- 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/dd1261c7-4bcc-40cb-9c45-ee77adfde077n%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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 On Wednesday 10 January 2024 at 16:21:54 UTC+1 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... > > 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. > -- 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/93374416-398b-49fc-a5c8-2ad7982efdf2n%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
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, vbraun.n...@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. -- 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/8d3dbe043ffe7bc6f6e60d2994c67abaebf97796.camel%40orlitzky.com.
