Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread David Roe
Dear Sage developers,
Dima is correct that there are several developers who have blocked each
other.  The Sage Code of Conduct Committee is aware of several cases and is
working on resolving them.  We believe both that the presence of these
blocks is harming the Sage project, and that it can be appropriate to block
another user.  In an extreme example, if one user "A" was stalking or
harassing another "B", it would absolutely be appropriate for B to block A.
Any resulting harm to the project is completely the responsibility of A in
such a situation. We are not saying that this situation applies for any of
the existing blocks, but there will certainly be less extreme cases in
which blocking remains appropriate.

In any case, the committee asks that anyone affected by blocking to please
channel their understandable frustration towards patiently working with us
to constructively resolve the current blocks individually and voluntarily.
We will continue to work toward addressing the underlying reasons
(revisions to the code of conduct, recruiting new members, new policies on
labels and reviewing, additional actions on github and in private).

Thanks,
David
for the Sage Code of Conduct Committee

On Fri, Mar 8, 2024 at 9:30 AM Dima Pasechnik  wrote:

>
>
> On 8 March 2024 14:11:41 GMT, 'Martin R' via sage-devel <
> sage-devel@googlegroups.com> wrote:
> >I don't know exactly what case of blocking you have in mind,
>
> on GitHub you can block a user - such a block prevents the blocked user
> from commenting and changing the status of your PRs and issues.
>
> Currently there are a few Sage team members blocking each other.
> I have made our CoC committee aware of this fact, but they are in no rush
> to rule on it, it seems.
>

-- 
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/CAChs6_%3DOQMThbcJz5o%3D-X%3D-kmOrm%3DJJraC%3Dm%2BsJw7_CrAY4Nqw%40mail.gmail.com.


Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread Dima Pasechnik



On 8 March 2024 14:11:41 GMT, 'Martin R' via sage-devel 
 wrote:
>I don't know exactly what case of blocking you have in mind,

on GitHub you can block a user - such a block prevents the blocked user from 
commenting and changing the status of your PRs and issues.

Currently there are a few Sage team members blocking each other.
I have made our CoC committee aware of this fact, but they are in no rush to 
rule on it, it seems.



>  but I'm going 
>to be bold and state that blocking among fellow developers (this is not 
>about private messages, right?) cannot really be a solution, in my opinion:
>
>* either there has been a substantial breach of conduct, in which case I 
>think the person cannot be part of sagemath anymore,
>* or otherwise, there shouldn't be a reason to block.
>
>I hope that we are talking about the empty set.
>
>Martin
>
>On Friday 8 March 2024 at 10:22:30 UTC+1 Dima Pasechnik wrote:
>
>> On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:
>>
>>> Addressing a comment from Travis 
>>>  on 
>>> the voting thread:
>>>
>>> "but might want to consider cases when its 2 vs 1 as requiring at least 
>>> one other person involved. (Sorry for being late to realize this.)"
>>>
>>> This border case was actually one of the reasons that I suggested a 2 to 
>>> 1 threshold.  I think that if a single objector thinks that a PR should not 
>>> proceed and the author and reviewer both think it should, the onus should 
>>> be on the objector to find other developers who share their objections.
>>>
>>
>> As long as the issue of GitHub blocks is not resolved, this issue is moot. 
>> A developer can block their opponents
>> on GitHub to make sure there is not enough opposition to their PRs.
>>
>> David
>>>
>>> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>>>


 On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  
 wrote:

> Apologies for the basic question in this thread, but recently I have 
> seen lots of conversation about the different labels and I want to 
> clarify 
> something for myself.
>
> In the past few PR I have made for Sage, randomised testing has 
> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>
> If there is code causing CI failure in random testing, should I mark 
> the fix for this as a "blocker", even if the chance of this failure is 
> small? I don't want to be melodramatic in my PR for fixes but I also want 
> to make sure I'm labelling things as expected,
>

 I don't think we ever tag anything but most onerous maths bugs as 
 blockers
 (e.g. we have a plenty of outstanding symbolic integration bugs).
 That is, unless it's absolutely Earth-shuttering, don't use "blocker".

 Dima
  

>
> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>
>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>
>>> Thank you for making progress on these urgent issues. I suggest the 
>>> following:
>>>
>>> 1. Open two other new threads, each of which is for voting on each 
>>> proposal. 
>>> 2. On a proposal, it should be clear that *a positive vote (+1) is 
>>> for the whole proposal,* and if one is negative to any part of the 
>>> proposal, (s)he should give a negative vote (-1).  
>>>
>>
>> Voting threads seem reasonable.  I'll wait a day or two to see if 
>> people have any final comments before voting.
>>  
>>
>>> 3. A proposal is accepted if the number of positive votes is at least 
>>> twice of the number of the negative votes.
>>>
>>
>> Despite the fact that we're asking for this threshold in voting on a 
>> PR, the standard for votes on proposals on sage-devel is just a plain 
>> majority (though of course I hope that we can come to a 2-1 consensus!).
>>
>> A minor suggestion for Proposal 2: for the label to be readable, I 
>>> suggest "CI fix" for the name of the label (a blank between words). 
>>>
>>
>> I'm happy to adjust the label to be "CI fix."
>>  
>>
>>> We may use this thread to get more comments on the Proposals before 
>>> opening voting threads.
>>>
>>> -- 
>>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>> -- 
> You received this message because you are subscribed to the Google 
> 

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread 'Martin R' via sage-devel
I don't know exactly what case of blocking you have in mind, but I'm going 
to be bold and state that blocking among fellow developers (this is not 
about private messages, right?) cannot really be a solution, in my opinion:

* either there has been a substantial breach of conduct, in which case I 
think the person cannot be part of sagemath anymore,
* or otherwise, there shouldn't be a reason to block.

I hope that we are talking about the empty set.

Martin

On Friday 8 March 2024 at 10:22:30 UTC+1 Dima Pasechnik wrote:

> On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:
>
>> Addressing a comment from Travis 
>>  on 
>> the voting thread:
>>
>> "but might want to consider cases when its 2 vs 1 as requiring at least 
>> one other person involved. (Sorry for being late to realize this.)"
>>
>> This border case was actually one of the reasons that I suggested a 2 to 
>> 1 threshold.  I think that if a single objector thinks that a PR should not 
>> proceed and the author and reviewer both think it should, the onus should 
>> be on the objector to find other developers who share their objections.
>>
>
> As long as the issue of GitHub blocks is not resolved, this issue is moot. 
> A developer can block their opponents
> on GitHub to make sure there is not enough opposition to their PRs.
>
> David
>>
>> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>>
>>>
>>>
>>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  
>>> wrote:
>>>
 Apologies for the basic question in this thread, but recently I have 
 seen lots of conversation about the different labels and I want to clarify 
 something for myself.

 In the past few PR I have made for Sage, randomised testing has 
 uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.

 If there is code causing CI failure in random testing, should I mark 
 the fix for this as a "blocker", even if the chance of this failure is 
 small? I don't want to be melodramatic in my PR for fixes but I also want 
 to make sure I'm labelling things as expected,

>>>
>>> I don't think we ever tag anything but most onerous maths bugs as 
>>> blockers
>>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>>
>>> Dima
>>>  
>>>

 On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:

> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>
>> Thank you for making progress on these urgent issues. I suggest the 
>> following:
>>
>> 1. Open two other new threads, each of which is for voting on each 
>> proposal. 
>> 2. On a proposal, it should be clear that *a positive vote (+1) is 
>> for the whole proposal,* and if one is negative to any part of the 
>> proposal, (s)he should give a negative vote (-1).  
>>
>
> Voting threads seem reasonable.  I'll wait a day or two to see if 
> people have any final comments before voting.
>  
>
>> 3. A proposal is accepted if the number of positive votes is at least 
>> twice of the number of the negative votes.
>>
>
> Despite the fact that we're asking for this threshold in voting on a 
> PR, the standard for votes on proposals on sage-devel is just a plain 
> majority (though of course I hope that we can come to a 2-1 consensus!).
>
> A minor suggestion for Proposal 2: for the label to be readable, I 
>> suggest "CI fix" for the name of the label (a blank between words). 
>>
>
> I'm happy to adjust the label to be "CI fix."
>  
>
>> We may use this thread to get more comments on the Proposals before 
>> opening voting threads.
>>
>> -- 
>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
 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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com
  
 
 .

>>> -- 
>>> You received this 

Re: [sage-devel] Re: Labels and Reviewing

2024-03-08 Thread Dima Pasechnik
On Thu, Mar 7, 2024 at 8:39 PM David Roe  wrote:

> Addressing a comment from Travis
>  on
> the voting thread:
>
> "but might want to consider cases when its 2 vs 1 as requiring at least
> one other person involved. (Sorry for being late to realize this.)"
>
> This border case was actually one of the reasons that I suggested a 2 to 1
> threshold.  I think that if a single objector thinks that a PR should not
> proceed and the author and reviewer both think it should, the onus should
> be on the objector to find other developers who share their objections.
>

As long as the issue of GitHub blocks is not resolved, this issue is moot.
A developer can block their opponents
on GitHub to make sure there is not enough opposition to their PRs.

David
>
> On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:
>
>>
>>
>> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope 
>> wrote:
>>
>>> Apologies for the basic question in this thread, but recently I have
>>> seen lots of conversation about the different labels and I want to clarify
>>> something for myself.
>>>
>>> In the past few PR I have made for Sage, randomised testing has
>>> uncovered (usually) trivial bugs. I then write new PRs to fix these bugs.
>>>
>>> If there is code causing CI failure in random testing, should I mark the
>>> fix for this as a "blocker", even if the chance of this failure is small? I
>>> don't want to be melodramatic in my PR for fixes but I also want to make
>>> sure I'm labelling things as expected,
>>>
>>
>> I don't think we ever tag anything but most onerous maths bugs as blockers
>> (e.g. we have a plenty of outstanding symbolic integration bugs).
>> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>>
>> Dima
>>
>>
>>>
>>> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>>>
 On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:

> Thank you for making progress on these urgent issues. I suggest the
> following:
>
> 1. Open two other new threads, each of which is for voting on each
> proposal.
> 2. On a proposal, it should be clear that *a positive vote (+1) is
> for the whole proposal,* and if one is negative to any part of the
> proposal, (s)he should give a negative vote (-1).
>

 Voting threads seem reasonable.  I'll wait a day or two to see if
 people have any final comments before voting.


> 3. A proposal is accepted if the number of positive votes is at least
> twice of the number of the negative votes.
>

 Despite the fact that we're asking for this threshold in voting on a
 PR, the standard for votes on proposals on sage-devel is just a plain
 majority (though of course I hope that we can come to a 2-1 consensus!).

 A minor suggestion for Proposal 2: for the label to be readable, I
> suggest "CI fix" for the name of the label (a blank between words).
>

 I'm happy to adjust the label to be "CI fix."


> We may use this thread to get more comments on the Proposals before
> opening voting threads.
>
> --
> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
> 
> .
>
 --
>>> 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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> 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/CAAWYfq2eMM%3DzUHCZ_dpfDvxattotQmaD-0kht6J8ZxCL9K005w%40mail.gmail.com
>> 
>> .
>>
> --
> 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 

Re: [sage-devel] Re: Labels and Reviewing

2024-03-07 Thread David Roe
Addressing a comment from Travis
 on
the voting thread:

"but might want to consider cases when its 2 vs 1 as requiring at least one
other person involved. (Sorry for being late to realize this.)"

This border case was actually one of the reasons that I suggested a 2 to 1
threshold.  I think that if a single objector thinks that a PR should not
proceed and the author and reviewer both think it should, the onus should
be on the objector to find other developers who share their objections.
David

On Wed, Feb 28, 2024 at 10:53 AM Dima Pasechnik  wrote:

>
>
> On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope 
> wrote:
>
>> Apologies for the basic question in this thread, but recently I have seen
>> lots of conversation about the different labels and I want to clarify
>> something for myself.
>>
>> In the past few PR I have made for Sage, randomised testing has uncovered
>> (usually) trivial bugs. I then write new PRs to fix these bugs.
>>
>> If there is code causing CI failure in random testing, should I mark the
>> fix for this as a "blocker", even if the chance of this failure is small? I
>> don't want to be melodramatic in my PR for fixes but I also want to make
>> sure I'm labelling things as expected,
>>
>
> I don't think we ever tag anything but most onerous maths bugs as blockers
> (e.g. we have a plenty of outstanding symbolic integration bugs).
> That is, unless it's absolutely Earth-shuttering, don't use "blocker".
>
> Dima
>
>
>>
>> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>>
>>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>>
 Thank you for making progress on these urgent issues. I suggest the
 following:

 1. Open two other new threads, each of which is for voting on each
 proposal.
 2. On a proposal, it should be clear that *a positive vote (+1) is for
 the whole proposal,* and if one is negative to any part of the
 proposal, (s)he should give a negative vote (-1).

>>>
>>> Voting threads seem reasonable.  I'll wait a day or two to see if people
>>> have any final comments before voting.
>>>
>>>
 3. A proposal is accepted if the number of positive votes is at least
 twice of the number of the negative votes.

>>>
>>> Despite the fact that we're asking for this threshold in voting on a PR,
>>> the standard for votes on proposals on sage-devel is just a plain majority
>>> (though of course I hope that we can come to a 2-1 consensus!).
>>>
>>> A minor suggestion for Proposal 2: for the label to be readable, I
 suggest "CI fix" for the name of the label (a blank between words).

>>>
>>> I'm happy to adjust the label to be "CI fix."
>>>
>>>
 We may use this thread to get more comments on the Proposals before
 opening voting threads.

 --
 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
 
 .

>>> --
>> 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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAAWYfq2eMM%3DzUHCZ_dpfDvxattotQmaD-0kht6J8ZxCL9K005w%40mail.gmail.com
> 
> .
>

-- 
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/CAChs6_nR1T2CtkD%2BEY7AHFDU5Y4TE0u1WUeWZ9crVkbhLt4%2Byg%40mail.gmail.com.


Re: [sage-devel] Re: Labels and Reviewing

2024-02-28 Thread Dima Pasechnik
On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope  wrote:

> Apologies for the basic question in this thread, but recently I have seen
> lots of conversation about the different labels and I want to clarify
> something for myself.
>
> In the past few PR I have made for Sage, randomised testing has uncovered
> (usually) trivial bugs. I then write new PRs to fix these bugs.
>
> If there is code causing CI failure in random testing, should I mark the
> fix for this as a "blocker", even if the chance of this failure is small? I
> don't want to be melodramatic in my PR for fixes but I also want to make
> sure I'm labelling things as expected,
>

I don't think we ever tag anything but most onerous maths bugs as blockers
(e.g. we have a plenty of outstanding symbolic integration bugs).
That is, unless it's absolutely Earth-shuttering, don't use "blocker".

Dima


>
> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>
>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>
>>> Thank you for making progress on these urgent issues. I suggest the
>>> following:
>>>
>>> 1. Open two other new threads, each of which is for voting on each
>>> proposal.
>>> 2. On a proposal, it should be clear that *a positive vote (+1) is for
>>> the whole proposal,* and if one is negative to any part of the
>>> proposal, (s)he should give a negative vote (-1).
>>>
>>
>> Voting threads seem reasonable.  I'll wait a day or two to see if people
>> have any final comments before voting.
>>
>>
>>> 3. A proposal is accepted if the number of positive votes is at least
>>> twice of the number of the negative votes.
>>>
>>
>> Despite the fact that we're asking for this threshold in voting on a PR,
>> the standard for votes on proposals on sage-devel is just a plain majority
>> (though of course I hope that we can come to a 2-1 consensus!).
>>
>> A minor suggestion for Proposal 2: for the label to be readable, I
>>> suggest "CI fix" for the name of the label (a blank between words).
>>>
>>
>> I'm happy to adjust the label to be "CI fix."
>>
>>
>>> We may use this thread to get more comments on the Proposals before
>>> opening voting threads.
>>>
>>> --
>>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com
> 
> .
>

-- 
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/CAAWYfq2eMM%3DzUHCZ_dpfDvxattotQmaD-0kht6J8ZxCL9K005w%40mail.gmail.com.


Re: [sage-devel] Re: Labels and Reviewing

2024-02-28 Thread Kwankyu Lee


If there is code causing CI failure in random testing, should I mark the 
fix for this as a "blocker", even if the chance of this failure is small?


No. A "blocker" blocks the release. We use it for serious fixes worth the 
delay. 

-- 
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/dfc5bbd0-eecb-45f4-a8f0-487933c5300en%40googlegroups.com.


Re: [sage-devel] Re: Labels and Reviewing

2024-02-28 Thread Giacomo Pope
Apologies for the basic question in this thread, but recently I have seen 
lots of conversation about the different labels and I want to clarify 
something for myself.

In the past few PR I have made for Sage, randomised testing has uncovered 
(usually) trivial bugs. I then write new PRs to fix these bugs.

If there is code causing CI failure in random testing, should I mark the 
fix for this as a "blocker", even if the chance of this failure is small? I 
don't want to be melodramatic in my PR for fixes but I also want to make 
sure I'm labelling things as expected,

On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:

> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>
>> Thank you for making progress on these urgent issues. I suggest the 
>> following:
>>
>> 1. Open two other new threads, each of which is for voting on each 
>> proposal. 
>> 2. On a proposal, it should be clear that *a positive vote (+1) is for 
>> the whole proposal,* and if one is negative to any part of the proposal, 
>> (s)he should give a negative vote (-1).  
>>
>
> Voting threads seem reasonable.  I'll wait a day or two to see if people 
> have any final comments before voting.
>  
>
>> 3. A proposal is accepted if the number of positive votes is at least 
>> twice of the number of the negative votes.
>>
>
> Despite the fact that we're asking for this threshold in voting on a PR, 
> the standard for votes on proposals on sage-devel is just a plain majority 
> (though of course I hope that we can come to a 2-1 consensus!).
>
> A minor suggestion for Proposal 2: for the label to be readable, I suggest 
>> "CI fix" for the name of the label (a blank between words). 
>>
>
> I'm happy to adjust the label to be "CI fix."
>  
>
>> We may use this thread to get more comments on the Proposals before 
>> opening voting threads.
>>
>> -- 
>> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com.


Re: [sage-devel] Re: Labels and Reviewing

2024-02-27 Thread David Roe
On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:

> Thank you for making progress on these urgent issues. I suggest the
> following:
>
> 1. Open two other new threads, each of which is for voting on each
> proposal.
> 2. On a proposal, it should be clear that *a positive vote (+1) is for
> the whole proposal,* and if one is negative to any part of the proposal,
> (s)he should give a negative vote (-1).
>

Voting threads seem reasonable.  I'll wait a day or two to see if people
have any final comments before voting.


> 3. A proposal is accepted if the number of positive votes is at least
> twice of the number of the negative votes.
>

Despite the fact that we're asking for this threshold in voting on a PR,
the standard for votes on proposals on sage-devel is just a plain majority
(though of course I hope that we can come to a 2-1 consensus!).

A minor suggestion for Proposal 2: for the label to be readable, I suggest
> "CI fix" for the name of the label (a blank between words).
>

I'm happy to adjust the label to be "CI fix."


> We may use this thread to get more comments on the Proposals before
> opening voting threads.
>
> --
> 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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com
> 
> .
>

-- 
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/CAChs6_%3DWSQ9s_kqtMocoHnwuiGYp-Ad%2B6RmgEvpZOMNjx4sZxA%40mail.gmail.com.


[sage-devel] Re: Labels and Reviewing

2024-02-27 Thread Kwankyu Lee
Thank you for making progress on these urgent issues. I suggest the 
following:

1. Open two other new threads, each of which is for voting on each 
proposal. 
2. On a proposal, it should be clear that *a positive vote (+1) is for the 
whole proposal,* and if one is negative to any part of the proposal, (s)he 
should give a negative vote (-1).  
3. A proposal is accepted if the number of positive votes is at least twice 
of the number of the negative votes.

A minor suggestion for Proposal 2: for the label to be readable, I suggest 
"CI fix" for the name of the label (a blank between words). 

We may use this thread to get more comments on the Proposals before opening 
voting threads.

-- 
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/554961a0-4ace-4317-bfcf-55b6a128bcden%40googlegroups.com.