Vote: Removing Automatic PR Size Labels

[Travis Scrimshaw]

PR labels are being automatically added to roughly indicate their size. There are three options besides keeping the current behavior:

(A1) Remove the automatic adding of labels; the must be added manually (like most other labels).

(A2) Have a "whitelist" of contributors who want to have this automatically added to their PRs.

(A3) Have a "blacklist" of contributors who do not want to have this automatically added to their PRs.

(B) Keep the current way of automatically adding it for all PRs.

This will be assuming that if you vote for (Ai), your vote will automatically count for all (Aj) >= (Ai) unless you state otherwise. For example, if there are 3 votes for (A1), 2 votes for (A3) and 4 votes for (B), we will go with (A3) as the total is 5 votes.

The vote will close on Friday, June 21st.

For the discussion, see: https://groups.google.com/g/sage-devel/c/w4IeYgXgVUc/m/nV-ZT9BpAgAJ

My vote: (A1)

Best,

Travis

[Matthias Koeppe]

-1 on conducting a vote without any discussion of the matter.

[julian...@fsfe.org]

I vote for (A1) and no other option.

(I don't see enough added value of these labels and I think that any *list approach is going to be a too obscure feature to warrant the extra effort of maintaining it.)

[seb....@gmail.com]

I vote for A3. If finally there are more votes for A1 than for B then you may count it for A2, as well.

[Eric Gourgoulhon]

I vote for (A1).

Eric.

[Kwankyu Lee]

+1 to (A1) 

[Vincent Delecroix]

On the material side I vote (A1).

On the human side I vote (B). Matthias raised a delicate point: this
feature was introduced by a newcomer to sage development. The feature
might have been wrongly guided or badly thought. Nevertheless, it
would be very unwelcoming to just revert it.

Ideally, there would be a "make the feature even nicer" solution
rather than "get rid of that s***". Though, this requires a concrete
proposal more than a vote, and I have nothing magical to share at this
stage.

Best
Vincent

On Fri, 14 Jun 2024 at 13:56, Kwankyu Lee <ekwa...@gmail.com> wrote:
>
> +1 to (A1)
>
> --
> 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/cd9f975b-3605-4e98-a165-2a2e1d4ab2b9n%40googlegroups.com.

[Matthias Koeppe]

On Friday, June 14, 2024 at 11:52:00 PM UTC-7 Vincent Delecroix wrote:

> Ideally, there would be a "make the feature even nicer" solution rather than "get rid of that s***". Though, this requires a concrete proposal more than a vote

Exactly, that's why a proper participation in the discussion before calling a vote would have been necessary.

I did share one concrete proposal in https://groups.google.com/g/sage-devel/c/w4IeYgXgVUc/m/N-Qrk3hzAwAJ. Let's call it 

(B7) Automatic labeling, but reduce the feature to: A size label "\tiny" (to encourage quick reviews of trivial changes); a size label "\HUGE" (to help flag problematic PRs). No size labels for "medium-sized" PRs (they do not add much).

I vote for (B7).

 

[Gareth Ma]

I vote for (A1) and no other options.

In fact, I don't think size related labels should be a thing at all, so the
second half of (A1), i.e. "the[y] must be added manually (like most other
labels)", should preferably be removed as well. (The wording suggests they will
be kept and added manually.)

[seb....@gmail.com]

Here I forward this post from Dima, which didn't find the right channel:

Fri, Jun 14, 12:25 PM (3 days ago)

Please record my vote for A3.

I also wonder whether this setup has a side feature which would allow
us to collect stats on the sizes of contributions.

Cheers
Dima

[seb....@gmail.com]

> The feature might have been wrongly guided

I'm sorry, that was my mistake (see my recent comment in #37262). This caused that there is a difference between B and B7.

>  Nevertheless, it would be very unwelcoming to just revert it.

This is the motivation behind Option A3.

[Travis Scrimshaw]

Sorry for the delayed response due to conference travel.

Vote count:

(A1) 5

(A3) 1

(B) 1ish

As such, please remove this automatic labeling of PR sizes.

We can have a proper discussion about how to make it easier for newcommers to find good PRs to review, but we should actually have that discussion before adding such features.

Best,

Travis

[Matthias Koeppe]

It really does not work this way.

[Travis Scrimshaw]

On Tuesday, July 2, 2024 at 11:35:37 PM UTC+9 Matthias Koeppe wrote:

It really does not work this way.

This is how we have always done things when there is a dispute, we vote on it. You might not like the result, but there is a clear consensus after a vote and discussion.

I am happy to have a discussion with you on how to improve things, but I think we should start with the status quo. Additionally, IMO this change really should have had a proper discussion on sage-devel before it was merged.

 

Best,

Travis

[Matthias Koeppe]

This vote is really a showcase of flawed governance.

0. The very premise, that somehow the developers are entitled to the status quo of the development infrastructure, is fundamentally flawed.

As a reminder, the current status quo was established just over a year ago in the Trac-to-GitHub migration, and continues to be refined in numerous PRs by the few individuals who are engaged in discussing, developing, and testing such refinements.

1. As I have already pointed out, it's simply a false claim that in the past (pre-GitHub) the changes to the details of the development infrastructure were widely discussed and voted on in the past. Such changes have always been made by the volunteer admins individually or based on internal discussions, never on sage-devel. In contrast, the change made here was developed and discussed in the open -- in a Pull Request. This is an improvement over how things have been done in the past.

2. Developers who take an interest in discussing development infrastructure know how to engage with it. "Proper" discussions of the development infrastructure _are_ happening -- in public, namely among those who have been take a sufficient interest in participating in it. 

3. The vote was called even though my key points raised in the previous discussion were entirely ignored.

4. The options presented in the vote were cherry-picked,

- to include strawmen (whitelisting, blacklisting users -- which obviously no one would be interested in implementing),

- to exclude relevant proposed changes from my messages.

5. Also my messages pointing out the flaws in the procedure were entirely ignored, without even any acknowledgment.

6. Finally, the idea that after a vote has ended, someone has the duty to implement it, is fundamentally flawed.

[Kwankyu Lee]

6. Finally, the idea that after a vote has ended, someone has the duty to implement it, is fundamentally flawed.

Right. The voting on sage-devel  has been a means to get approval from the community for a proposal that the initiator wants to implement. 

On the other hand, there is no clearcut about what needs approval. It is wrong to say that the size labeler was improperly introduced.

  

[Travis Scrimshaw]

Matthias, let me very explicitly address your points to make sure that you recognized that I did address them (as per your remark 5).

0: That is a misrepresentation of my point: before changes are implemented that affect all developers, some outreach effort to all developers should be done. I am grateful for your efforts to improve things, but a small group working in a way that what they are doing is easily obscured by the snow does not really constitute community involvement nor help ease the developer experience.

1: I don't know what you're basing this on. Things in Sage that affect the whole community in any noticeable way have mostly been discussed on sage-devel, with an exception perhaps with many of the things you have been doing. As noted in (0) and previously, on a PR does not constitute community involvement just because it happens in the public. It is too easy to miss when people are busy and in all of the PRs that appear. You have no basis to claim an improvement against discussions on trac tickets either.

2: This is a fallacy: I take an interest, but I don't always have the time to devote to this. We also have a specific forum for public discussions: sage-devel. Somethings do happen here, but not all, as illustrated by this issue.

3: You might think of them as such, but that doesn't mean other people do. Not only did nobody else raise an issue with this vote, we have had numerous votes in the past as a way to resolve such issues with a disagreement.

4: First, you could have put other options here. However, ultimately any other alternative was simply to keep it in place. I included other options that were proposed and one even received a vote.

5: They don't need to be acknowledged for the process to continue. Referees don't usually acknowledge someone in a game when they want a foul called either.

6: This is not true; somebody has the duty to implement it. Although it is not clear who should, but the initiator of the vote does implicitly have the burden of implementation. As such, I have done so (which now needs approval):

https://github.com/sagemath/sage/pull/38334

Kwankyu, just because there is no explicit legalese definition, a good rule of thumb that we have employed is things that (could) effect everyone should be mentioned here.

Best,

Travis

[Kwankyu Lee]

3. The vote was called even though my key points raised in the previous discussion were entirely ignored.

4. The options presented in the vote were cherry-picked,

- to include strawmen (whitelisting, blacklisting users -- which obviously no one would be interested in implementing),

- to exclude relevant proposed changes from my messages.

Let us use this case as an opportunity to improve the voting procedure, regarding the points (3) and (4).

The general procedure of sage-devel voting is currenly:

(1) Proposal: A developer (the initiator) proposes an actionable item P1, P2. 

(2) Discussion: People discuss on merits and demerits of these items.

(3) Voting: People vote on choices [Do P1], [Do P2], [Do nothing].

(4) Implement the result: the initiator implements the voting result in a github PR. 

(5) Review the PR: the PR goes through the normal review process. The reviewer checks if the PR implements the voting result faithfully.

     (it is implicit that no one can object to the PR)

We may make the following patch to the procedure:

(2.5): The initiator should make up the choices P1, P2, Q1, Q2 reflecting people's suggestions, and list them clearly before voting.

(3 modified) Voting: People vote on  choices [Do P1], [Do P2], [Do Q1], [Do Q2], [Do nothing] 

 

[Matthias Koeppe]

On Thursday, July 4, 2024 at 1:02:27 PM UTC+9 Travis Scrimshaw wrote:

1: I don't know what you're basing this on. Things in Sage that affect the whole community in any noticeable way have mostly been discussed on sage-devel, with an exception perhaps with many of the things you have been doing.

I'm basing this on having read the sage-devel archives from the past decade, as part of my work on preparing the NumFOCUS application. I know exactly what I'm talking about.

[Matthias Koeppe]

On Thursday, July 4, 2024 at 1:02:27 PM UTC+9 Travis Scrimshaw wrote:

3: You might think of them as such, but that doesn't mean other people do. Not only did nobody else raise an issue with this vote, we have had numerous votes in the past as a way to resolve such issues with a disagreement.

That you feel entitled to dismissed my concern on the basis that no one else raised a concern -- that's just an expression of disrespect, and I find it highly problematic that you are now doubling down on it in public. Such behavior cannot have a place in our community.