The original proposal allows for anyone to post to sage-devel to try to
raise awareness ("Also note that an objector is welcome to attempt to bring
others into the discussion on their side if they remain firmly opposed"). I
prefer allowing the various participants the freedom to decide whether to
start a discussion in sage-devel rather than forcing this to happen, but
I'm happy to hear arguments for changing it as you propose.
For some topics and disputes, it is clear that they should be discussed on
sage-devel, perhaps even discussed here before getting to the point of a
PR. Recalling one of William's old April 1 jokes, if we wanted to consider
switching the infrastructure from Python to Lisp, that would require a
discussion on sage-devel first. You mentioned
https://github.com/sagemath/sage/pull/35403, and I think that's another
good example. That deals with which versions of Python we support and
whether to automatically reject certain versions. Python plays such a
central role in Sage, but at the same time that PR is somewhat technical,
so I feel that it's on the border of "clearly should be discussed first on
sage-devel" vs. "can be handled in the background". Once the conflict
arose, it made a lot of sense to bring it to sage-devel. A third example:
Kwankyu raised https://github.com/sagemath/sage/pull/36726, and in my view
this one is very minor and technical, and I don't see a case for a long
discussion or vote on sage-devel. Mentioning it here to raise awareness
makes sense, but that should be the extent of it; the rest of the
discussion can happen on github.
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+unsubscr...@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.
