-
-
Notifications
You must be signed in to change notification settings - Fork 26.1k
Add FAQ entry about the spam label #31822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
I think a set of labels of the format 'lacking ...' would be nice (e.g., 'lacking context' for issues where there is not linked triaged issue and no explanation for the change). These labels could even be linked with a bot that gives information about how to improve the PR. I think this is more informative for the contributor. It also means we can more easily add such a label when the PR is poor quality, without worry about offending, as it is not so 'negative'. |
Can we do labels for helping people who made an honest effort but need help in a new issue/PR? For me that is a separate topic from having a label for things that people put no effort into. |
Fair point. I guess
This one is tricky because I have seen genuine PRs where their linter or git mishap has cause unrelated changes. |
The list of things to do is meant as something people can do, not as "messy diff, let me slap a spam label on this PR!". At least for me a spammy/low effort/not in good faith PR judgement is the result of the overall impression. Of which a terribly messy diff might be one factor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving some comments, thank you @betatim!
doc/faq.rst
Outdated
The "spam" label is used for many reasons, it is an indication for other | ||
maintainers that the issue or pull request has only received low effort. | ||
|
||
Some steps to increase the chances of the label being removed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the chances of the label being removed: In the past we had closed all of the PRs that have the spam label and did not leave any open. So this promise would change the usage scope of the label. I still wonder if there should be a new label for this instead of "spam", because certainly not everything labeled as spam is worth the attempt of saving.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we keep it that all spam PRs are closed but invite people to fix and open a new PR?
I think this may result in less work for maintainers as we wouldn't have to recheck to see if the label should be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I listed some things people can do is to avoid the impression that the spam label is "fatal" for a PR. While I might label it spam, someone else might want to review it or help the author out.
I'm also fine with closing them. In which case I think we can remove this section? To me a PR that gets marked as spam is probably more work to revive than to just make a new PR from scratch (unlike stalled PRs where reviving is worth it)
Co-authored-by: Stefanie Senger <91849487+StefanieSenger@users.noreply.github.com>
doc/faq.rst
Outdated
|
||
The "spam" label is an indication for reviewers that the issue or | ||
pull request may not have received sufficient effort or preparation | ||
from the author for a productive review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should be explicit about the motivations behind the introduction of this label (e.g.: increase in the volume of low quality PRs and noisy issues, some of which we suspect have been 100% generated by automated tools).
We might want to also use this label to PRs that are closed right away, for instance because the PRs was opened before reaching a conclusion in the related issue. If we do so we need to update the FAQ accordingly. |
Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>
What does this implement/fix? Explain your changes.
This adds a short FAQ entry explaining what the "spam" label means, and gives some hints what people can do to increase the chances of it being removed.
The idea is to use this label to mark issues and PRs that are somehow "spammy". This could be because they contain no content, are duplicates, fully automated contributions, or other reasons that make a maintainer think "no effort went into making this contribution". The goal is to provide a simple way to deal with "low effort" contributions.
A label is a simple way to get started with this. It will allow us to collect some experience with how often this happens, how people react to it and we can build more tooling on top of it (e.g. a bot that comments on labelled issues or auto closes them, etc).
While maintainers can comment on an issue directly with a short note and explanation I think this has two disadvantages:
Please do not use this label for "low quality" issues/PRs - what we judge to be a low quality issue/PR might be the result of a beginner putting in a lot of effort. We should respect that and try to coach people as we do today (within the constraints we have). I hope we will manage to separate between "low effort contributions by capable people" and "low quality contribution by a beginner", even though they might appear similar.
I decided to (re)use the "spam" label because it already exists, isn't widely used and while maybe not the best name we did not manage to come up with a great name either.
Any other comments?
We briefly discussed this in discord and in #31679, there is no dedicated issue for this though.