A tangential follow-up to Matthias: I think that our code of conduct should be part of the distributed documentation. Should it be in the Developer's Guide? In some other existing documentation? As a standalone document?
Meanwhile, Matthias and Dima spent lots of mental energy to produce a prime example showing why we need the policy:
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq35iKf1EkaLkccvNp7kd9e254QD5Y4%2B1BoFROJL2R1iiQ%40mail.gmail.com.
(2) How do we count approvers and disapprovers for a disputed PR: A reviewer becomes an approver (who is in favor of the PR) when he/she sets "Approve" in the github review system. A reviewer becomes a disapprover (who objects the PR) when he/she sets "Request changes" in the github review system.
I think there needs to be a clear indication that a voting period is active (and when it closes). Perhaps we can use a PR label "s: voting" or "s: needs votes"?
In light of this, I would like to propose to change the policy proposal to an automatic system that draws more attention to the PR, with the hope that new people bring new input and ideas, which then resolves the conflict in a natural way.
... instead of a general direction, we have this situation where every developer is having their own ideas and little projects that they are working on, and that are bound to step on toes of others.
To the extent that this specific PR is emblematic of a particular approach to Sage development (a flawed approach in Dima's view, if I understand right), then the whole approach should be discussed here. Probably many of these issues in Sage development have been discussed already, but it's probably time to revisit them, to see if we can reestablish a baseline level of consensus.
On Wednesday, November 29, 2023 at 7:12:31 AM UTC-8 Tobia...@gmx.de wrote:At first I was very enthusiastic about this proposed policy, but after thinking about this for a bit I'm no longer convinced this is a good idea.First of all, the policy sets out to solve the case "where there is a general consensus, but one person (or a few people) disagree". In my experience, this case is not a problem. All the examples mentioned so far (and the few other examples I'm aware of), have usually one positive reviewer and one negative review. This is not a general consensus. The problem is more that a general consensus cannot be reached. Another aspect of the issue is that usually only a very small group of 2 to 3 people is involved in discussing the PR, which perhaps not surprisingly then more easily results in a state where all arguments have been exchanged without finding a solution satisfying everyone.For example, with the proposed policy, Dima and me would have outvoted Matthias in https://github.com/sagemath/sage/pull/35403. But this PR was largely improved by the discussion on the mailing list (that it is still not clear how to proceed with this PR is another sad story).In light of this, I would like to propose to change the policy proposal to an automatic system that draws more attention to the PR, with the hope that new people bring new input and ideas, which then resolves the conflict in a natural way. The proposal is something along the following: if a PR is say a week in the "disputed state" as defined above by Kwankyu, both parties write a short statement of why they think it should or should not be merged, and this summary is then posted to the mailing list. Not to start a voting, but to raise awareness and invite other devs to join the discussion. Similar calls for PR reviews are not uncommon on the mailing list, so I don't think it would annoy subscribers too much.Finally, I think Dima raises a very important point. Most of the discussions in these "disputed PRs" are a result of a lack of a common vision for the project and agreement on what projects to work on. It would be immensely more productive to have a general discussion e.g. about how to proceed with sage-the-distribution (replace it?, with what?, how to sunset it? reduce it? enlarge it?). As an example, I think conda is a good candidate to replace sage-the-distribution and thus naturally open PRs with changes in that direction. But if you don't agree with this general direction, it's easy to find these changes annoying. On the other hand, if there would be an agreement that conda was a nice experiment that we don't want to continue, then I'm happy to delete it completely. But instead of a general direction, we have this situation where every developer is having their own ideas and little projects that they are working on, and that are bound to step on toes of others.On Wednesday, November 29, 2023 at 7:20:12 AM UTC+8 Kwankyu Lee wrote:I think there needs to be a clear indication that a voting period is active (and when it closes). Perhaps we can use a PR label "s: voting" or "s: needs votes"?If we do not want to invent a new label, we may add "s: needs review", "s: needs work", "s:needs info" altogether to get attention.Then the voting period starts when the three labels are added.I suggest to end the voting when a week has passed after the last vote was casted.
--
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/3d62ce18-f2b0-408b-878a-6ccb1d202584n%40googlegroups.com.
At first I was very enthusiastic about this proposed policy, but after thinking about this for a bit I'm no longer convinced this is a good idea.First of all, the policy sets out to solve the case "where there is a general consensus, but one person (or a few people) disagree". In my experience, this case is not a problem. All the examples mentioned so far (and the few other examples I'm aware of), have usually one positive reviewer and one negative review. This is not a general consensus. The problem is more that a general consensus cannot be reached. Another aspect of the issue is that usually only a very small group of 2 to 3 people is involved in discussing the PR, which perhaps not surprisingly then more easily results in a state where all arguments have been exchanged without finding a solution satisfying everyone.For example, with the proposed policy, Dima and me would have outvoted Matthias in https://github.com/sagemath/sage/pull/35403. But this PR was largely improved by the discussion on the mailing list (that it is still not clear how to proceed with this PR is another sad story).In light of this, I would like to propose to change the policy proposal to an automatic system that draws more attention to the PR, with the hope that new people bring new input and ideas, which then resolves the conflict in a natural way. The proposal is something along the following: if a PR is say a week in the "disputed state" as defined above by Kwankyu, both parties write a short statement of why they think it should or should not be merged, and this summary is then posted to the mailing list. Not to start a voting, but to raise awareness and invite other devs to join the discussion. Similar calls for PR reviews are not uncommon on the mailing list, so I don't think it would annoy subscribers too much.Finally, I think Dima raises a very important point. Most of the discussions in these "disputed PRs" are a result of a lack of a common vision for the project and agreement on what projects to work on. It would be immensely more productive to have a general discussion e.g. about how to proceed with sage-the-distribution (replace it?, with what?, how to sunset it? reduce it? enlarge it?). As an example, I think conda is a good candidate to replace sage-the-distribution and thus naturally open PRs with changes in that direction. But if you don't agree with this general direction, it's easy to find these changes annoying. On the other hand, if there would be an agreement that conda was a nice experiment that we don't want to continue, then I'm happy to delete it completely. But instead of a general direction, we have this situation where every developer is having their own ideas and little projects that they are working on, and that are bound to step on toes of others.
On Wednesday, November 29, 2023 at 7:20:12 AM UTC+8 Kwankyu Lee wrote:I think there needs to be a clear indication that a voting period is active (and when it closes). Perhaps we can use a PR label "s: voting" or "s: needs votes"?If we do not want to invent a new label, we may add "s: needs review", "s: needs work", "s:needs info" altogether to get attention.Then the voting period starts when the three labels are added.I suggest to end the voting when a week has passed after the last vote was casted.
--
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/c602514f-b7a1-4afc-bb04-cdde37b4a879n%40googlegroups.com.
If we do not want to invent a new label, we may add "s: needs review", "s: needs work", "s:needs info" altogether to get attention.
To the extent that this specific PR is emblematic of a particular approach to Sage development (a flawed approach in Dima's view, if I understand right), then the whole approach should be discussed here. Probably many of these issues in Sage development have been discussed already, but it's probably time to revisit them, to see if we can reestablish a baseline level of consensus.As a person who has been involved in Sage a long time, I just want to +1 John's remark that major issues involving the direction and approach to Sage development, even if they have been discussed before, are definitely something that should be discussed again. The optimal choices for a Sage can easily change as the world changes, and there are many relevant factors to Sage's development that are massively different now than in the past. Examples: python is much more popular now than ever before; GPU's are vastly more powerful now than before; GitHub with its amazing free CI infrastructure exists; Conda exists; GCC isn't the only free C compiler; WebAssembly exists, ...
This is a good place to thank embray and darthandrus (among many others) for work on previous Windows and Mac "one-click" download options, and especially the 3-manifolds project for the current one for Mac.
Relevant to both the overall issue of project direction *and* the specific one about Sage-as-distribution, I would just add keeping in mind the Sage mission (at least, as it currently stands):Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.