Hi,
Another "disputed" PR is piled on the heap:
https://github.com/sagemath/sage/pull/36999
Behind a disputed PR, there is a lot of time and energy wasted from the
author, the reviewers, and the audience. The disputed PRs discourage
everyone in the community.
I am aware that one policy about
Hi,
Another "disputed" PR is piled on the
heap: https://github.com/sagemath/sage/pull/36999
Behind a disputed PR, there is a lot of time and energy wasted from the
author, the reviewers, and the audience. The disputed PRs discourage
everyone in the community.
I am aware that one policy about
Wish you a happy new year!
A year ago, we successfully escaped from a sinking issue management system.
Hopefully, the new year will save us from the current spiral that's
drowning us.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
The most recent response in this discussion thread was posted over 3 weeks
ago.
(There has been major activity on PRs linked in some of the posts, though.)
Do we have a timeline for the next step in this effort?
Best wishes for the new year to all members of the Sage community!
Matthias
On
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*.
We are discussing shortcomings of a huge mono-repo which only keeps growing.
GitHub's idea that you release a whole repo makes it quite impossible to
release parts of Sage without a lockstep. While back in 2021 we haven't quite
realised this, it's becoming clear now.
The issue #36803 is an
In the discussion in one of the PRs linked here, we have identified a
separate issue.
The SageMath project has a high complexity, which can be overwhelming to
some.
As part of our goal to make the Sage development community more inclusive,
we should expand the developer's guide with
On Thursday, November 30, 2023 at 3:14:57 PM UTC-8 kcrisman wrote:
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.
+1
--
You
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
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.
The pending script (https://github.com/sagemath/sage/pull/36292) that
automatically manages the github labels won't be happy with this (several
status
On Wed, Nov 29, 2023 at 10:12 AM 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
On Thu, Nov 30, 2023 at 12:37 PM John H Palmieri
wrote:
> 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
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
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 already promotes more discussion by
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
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
On Saturday, November 25, 2023 at 1:24:42 AM UTC-8 Kwankyu Lee wrote:
(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
On Tue, Nov 28, 2023 at 10:02 PM David Roe wrote:
>
> Let's try to focus on the policy proposal, rather than specific disagreements
> on individual PRs.
The whole thing about specific disagreements on individual PRs comes
exactly from the wrong overall direction of the project.
Which replaced,
Let's try to focus on the policy proposal, rather than specific
disagreements on individual PRs.
Dima, I'm sorry that you're feeling frustrated with the whole process. It
may be helpful to have additional directions about the overall strategy for
Sage's build system, but that's better put off to
On Tue, Nov 28, 2023 at 9:25 PM Kwankyu Lee wrote:
>
> Meanwhile, Matthias and Dima spent lots of mental energy to produce a prime
> example showing why we need the policy:
>
> https://github.com/sagemath/sage/pull/36726
>
> Please come down from sun-shining deck to the murky bottom of our ship
On Tuesday, November 28, 2023 at 1:25:17 PM UTC-8 Kwankyu Lee wrote:
Meanwhile, Matthias and Dima spent lots of mental energy to produce a prime
example showing why we need the policy:
https://github.com/sagemath/sage/pull/36726
I endorse this example as one that is safe to study, without the
Meanwhile, Matthias and Dima spent lots of mental energy to produce a prime
example showing why we need the policy:
https://github.com/sagemath/sage/pull/36726
Please come down from sun-shining deck to the murky bottom of our ship to
see the danger that might drown all of us...
--
You
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?
Yes. I agree that it is very relevant. But to keep a single source of
I agree that we need a policy, and I am happy with David's proposal.
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?
--
I agree that we need a policy for disputed PRs.
Such a policy should not operate in a way to condemn those raising
objections to the PR since we want to keep kind, productive, caring
atmosphere as Matthias put it. The policy should be clear and operate
semi-automatically. So I suggest the
Thanks, David, for opening this (overdue) discussion with your thoughtful
post.
I would like to put it in a larger context. I'm sure most here would agree
that we want our project to be trustworthy for current and future users, to
be welcoming to new users and developers, and to maintain a
26 matches
Mail list logo
