Removing the automatic size labeler #38334
Conversation
There was a problem hiding this comment.
I agree that we should stop auto-labeling, as more people find it annoying than helpful. On the other hand, I agree with @videlec 's post in the Sage devel thread that it is not very welcoming to simply remove a new Sage developer's code. So my suggestion is to change the job's reaction events so that it still can be triggered manually:
diff --git a/.github/workflows/pr-labeler.yml b/.github/workflows/pr-labeler.yml
index 63f70bb653..ab5eaf5931 100644
--- a/.github/workflows/pr-labeler.yml
+++ b/.github/workflows/pr-labeler.yml
@@ -2,14 +2,8 @@
# based on files edited and no of lines changed.
name: Size Labeler / Checker
on:
- pull_request_target:
- types:
- - opened
- - reopened
- - synchronize
- - ready_for_review
- - review_requested
- - edited
+ workflow_dispatch:
+ # Allow to run manually
Furthermore, I think it would be fair to involve the author of the code here, as well.
|
While I agree with you @soehms and with @videlec that it can be seen as unwelcoming to simply revert this, I find that argument to be a very weak reason to not revert it for a number of points. In particular, with broader input sought before merging, the original PR would have gotten to a point where it would have been seen by the community as net benefit. Nor do I think it is fair to tell someone that you cannot modify/remove someone’s code just because they are new. (For example, what if I want to completely rewrite how a function works after a new contributor just did the same?) Additionally, we had a vote that included an option to keep it with manual inclusion (and exclusion), but the vote was clearly for removing it. I don’t think it is fair to wait around with this auto-checker trying to figure out a better solution. It will still be there in the git history if we want to revive it later. One other point is the labels themselves will still be there for people to add manually. IMO we have enough clutter around already with GH’s various things, in addition to the Sage specific stuff; I don’t want to add more things for new contributors/reviewers to have to sort through with some extra button (if that is even possible). |
Travis, what are you talking about? It's really not possible to discussion Developer Experience issues on the level of such general rants. Honestly I find these claims that (1) the automatic labels somehow are harmful, (2) adding the mechanism would have required consultation, and (3) now require urgent action ("p: critical") to be removed -- absurd and disrespectful. |
|
@mkoeppe I am sorry I have made you feel that way. We have a clear difference of opinion about this. I stand by my reasoning and opinion, and you are also entitled to your opinion on these matters. We can downgrade the priority to "p: major" if you think that is better, but I think we should enact the result of the vote as soon as possible because it is constantly affecting the development process. |
I don't mean that you can't do this in general. It's a question of how you bring the new contributor along. If @amanmoon can follow your reasoning and agrees to remove his code, then I will agree too. If not, you should at least try to convince him. |
Also the majority of people who voted to stop that automatic labeling would find it disrespectful if we left it as it is. |
|
I feel there is nothing unwelcoming in reverting the changes. According to me the unwelcoming part shouldn't be one of the arguments here. I am grateful to @soehms for reviewing the changes, I learnt a lot about GH workflows while creating the PR. |
|
@amanmoon Thank you for your understanding. Thank you also for your efforts to try and improve the developer experience too. |
No, Travis, this is not about "feelings". Public disrespect poisons our community, and moreover it is an instrument of bullying.
No, Travis, what is happening is not a difference of opinion. What has happened here is something very problematic, and something that I have observed several times in the recent past -- that someone is trying to force their will by bringing their own personal version of project procedures. I've explained it already in detail in the sage-devel thread. I won't repeat it here, but you should re-read it and think about it. The idea that this mechanism needs to be urgently reverted before even a "proper discussion" of it can happen -- that's just absurd. |
@soehms Would they? Nobody is saying that the opinion of the voters should be ignored. And most people understand what a spoiled ballot is. |
At least it is not clear to me whether we have rules to distinguish between valid and invalid votes. However, my impression is that we loop around in a chain of misunderstandings. Wouldn't it be best to reboot and start with a modified approach from the begining? My suggestion:
|
|
There's no need to "reboot". How we discussed and implemented this DX feature was following best practices. People who have become newly interested in discussing DX matters should join the discussion in a normal way, not by alleging that something was done wrongly etc. |
|
@soehms Could you please approve the PR so we can proceed? The community has made clear its opinion through the vote (and the original author has agreed to this); we do not require unanimous consent to do so. |
The vote is invalid because of its obvious and severe violations of every principle of governance. |
This is simply not true. We did have a discussion with a consensus forming, which then there was a vote which included the options presented in said discussion. In addition, I have very carefully again (re)read and thought your objections and still find them to be completely meritless in general. Furthermore, I will point out that you raised these objections during the vote and nobody else concurred with you. If you disagree with our processes, then you are free to try to change them. I would also appreciate it if you could refrain from using charged language during these discussions as it does not help with making this into an inclusive and respectful community. |
What do you mean by DX-feature? I understand that people object to sudden changes that influence their daily work. |
I still don't understand this and I think all participants of the vote don't. Can you explain this in more detail and mention other community members who support your opinion? |
|
Because the discussion on this issue included concerns about conduct and procedure in the SageMath project, the Code of Conduct Committee believes it is important to clarify a few points for future reference. This ticket was created to implement the decision of a vote conducted in https://groups.google.com/g/sage-devel/c/3PLZD-4UFIA This timeline is in line with how votes of impactful decisions are generally conducted and the end of discussion well before the closure of the vote indicates that all parties had ample opportunity to discuss their views and concerns. Subsequently, issue #38334 was created to implement the favoured option. This is also in line with how generally votes are conducted (although usually the issue already exists before the need to vote becomes apparent). We therefore see nothing unusual in how this change was discussed, voted on, or implemented and find any allegations otherwise unfounded. The Sage Code of Conduct Committee. |
|
Making such "clarifications" is outside of the mandate of the Sage Code of Conduct committee. |
We revert #37262. This was voted on sage-devel: https://groups.google.com/g/sage-devel/c/3PLZD-4UFIA
📝 Checklist
⌛ Dependencies