-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Proposal: Make triaging more welcoming to external contributors #4982
Comments
This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___."). Thank you for your contributions. |
Kidding.
😜 I think we should torch the annoying robot for good, possibly encasing its corpse in cement so it doesn't come back as a zombie. Since I'm not the one in charge of making that decision, though, I agree that PRs deserve a longer grace period. Hell, we probably shouldn't close them at all — if a PR needs changes, and the submitter's become unresponsive, it's easier if a maintainer just pushes changes to their branch before merging. If the PR's obviously invalid, and the user doesn't close it themselves, a maintainer can do it at their discretion. |
I'm happy to tweak things or remove the bot entirely. As detailed in the original PR, I started off with the default values with the intention of iterating. I originally implemented it to reduce the manual churn and huge amount of time @pchaigno was spending poking old issues and PRs that would never see any action.
We can do this now, but don't 😄 Any of these labels will be ignored by the stalebot: Regardless, this might be a good thing to start doing. Documenting the process in the CONTRIBUTING.md would be good too. In summary, if @pchaigno and @Alhadis are happy to go back to manually churning through old issues and PRs, and like the idea of implementing a documented triage process, then I'm 👍 . |
This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___."). Thank you for your contributions. |
Ironic ↑ |
Would also be good to remove 'good first issue' from issues pending popularity and issues with attached PRs |
I've contributed on and off to linguist since 2017 and over time I've observed a quite frustrating pattern with issues and pull requests: legitimate issues and pull requests get labelled quite quickly as stale (30 days) and then closed (60), with no further option to reopen them.
I understand that this workflow may be convenient for maintainers, but it seems discouraging in a few ways:
For a casual contributor, 60 days may be a too strict deadline for a Pull Request. It is quite frustrating to come back at a Pull Request a couple of months later (holidays or whatever reason for inactivity) to find you need to create a new one.
For issues, closing an issue just because there is no PR in 60 days hides them from people who are looking for active ways to contribute. It also tends to promote filing duplicates without reading any of the previous discussion.
I think this could be improved in a way that promotes external contributions while maintaining convenience for maintainers. There are probably many good ways, but I'm thinking about something along the following lines:
Pull Requests: Do not close them automatically (or extend the grace period). There's 73 PRs closed as Stale over a ~2 years period. A few of them were mostly ready, so the project could probably benefit from keeping them alive for a while.
Issues: Once an issue is confirmed to be a valid bug or feature request, add a label (e.g.
Help Wanted
) and exclude it from the Stale workflow. This label would be a great way for people looking to contribute, while making it clear to the reporter that it needs someone to work on it. Keeping them open and clearly marked also makes them more easily discoverable by users experiencing the same issue, so they can contribute to the discussion.What do you think?
The text was updated successfully, but these errors were encountered: