Skip to content
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

Closed
smola opened this issue Aug 31, 2020 · 7 comments · Fixed by #5502
Closed

Proposal: Make triaging more welcoming to external contributors #4982

smola opened this issue Aug 31, 2020 · 7 comments · Fixed by #5502

Comments

@smola
Copy link
Contributor

smola commented Aug 31, 2020

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?

@Alhadis
Copy link
Collaborator

Alhadis commented Aug 31, 2020

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.

@Alhadis Alhadis added Stale and removed Stale labels Aug 31, 2020
@Alhadis
Copy link
Collaborator

Alhadis commented Aug 31, 2020

Kidding.

What do you think?

😜 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.

@lildude
Copy link
Member

lildude commented Sep 1, 2020

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.

  • 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.

We can do this now, but don't 😄 Any of these labels will be ignored by the stalebot:

https://github.com/github/linguist/blob/98f19f1b60bb4d8c7f35329c8d94ecf61ade69d2/.github/stale.yml#L19-L25

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 👍 .

@stale
Copy link

stale bot commented Dec 25, 2020

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.

@stale stale bot added the Stale label Dec 25, 2020
@Nixinova
Copy link
Contributor

Nixinova commented Feb 5, 2021

Ironic ↑

@smola
Copy link
Contributor Author

smola commented Feb 5, 2021

@Nixinova Ironic ↑

Yeah 🤣

But to be fair, the state of affairs has improved a lot (thanks @lildude!). Now many issues and PRs are labelled, preventing going stale spuriously.

@stale stale bot removed the Stale label Feb 5, 2021
@Nixinova
Copy link
Contributor

Nixinova commented Feb 6, 2021

Would also be good to remove 'good first issue' from issues pending popularity and issues with attached PRs

@github-linguist github-linguist locked as resolved and limited conversation to collaborators Jun 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants