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

Add Probots #4111

Closed
RichardLitt opened this issue May 18, 2018 · 6 comments · Fixed by #5082
Closed

Add Probots #4111

RichardLitt opened this issue May 18, 2018 · 6 comments · Fixed by #5082
Labels
Accepted Accepted issue on our roadmap Needed: design decision A core team decision is required

Comments

@RichardLitt
Copy link
Member

Why

I want to add probots because I think that they can significantly make it easier for us to do triaging, and will relieve the maintainers of some pressure.

Wait, what are probots?

They're automated scripts that interact with GitHub issues and basically do some work for you, such as checking that users respond in times, that old threads are locked, and other things which are easy for a bot to do but laborious for maintainers.

Ok, which ones?

What do you think?

@RichardLitt RichardLitt added the Improvement Minor improvement to code label May 18, 2018
@agjohnson
Copy link
Contributor

@humitos originally brought this up internally, though we sidelined the work as we have a lot of bigger priorities on our roadmap.

I think this is a good list to get started with. A few notes:

  • ProBot No Response - we'll need to audit these issues and perhaps update our triaging guidelines before enabling. I use "Needed: more information" to track issues without responses, but I don't think that is a universal rule for all contributors triaging
  • ProBot Stale - I have the most problems with this. I'm not sure we can find one simple ruleset that applies to us. We have a lot of feature issues that I'd prefer to keep -- a lot would be wiped out immediately by this without a lot of time spent auditing our issues. I wish this plugin operated on a label inclusion basis instead of exclusion. If we could start with just "Support" and "Community Effort", I think that is maybe okay. This seemed like a pain to configure though. Also, in line with our existing triage guidelines "Status: stale" for a label.
  • ProBot WIP - +1 except for using the tag PR: work in progress instead

I think a few triage clarifications are needed:

  • Enhancement should only be accepted enhancements, we don't use this label to imply the underlying work would be considered a feature addition
  • We might need a separate label for long-lived support issues -- for example, handing off a project, which can stay open for months in a valid state. Maybe a Status: blocked works here.

@agjohnson agjohnson added this to the Development improvements milestone May 31, 2018
@RichardLitt RichardLitt removed the Improvement Minor improvement to code label Jun 1, 2018
@agjohnson
Copy link
Contributor

Oh, also, I think automating branch deletion is another plugin that would be easy to configure and get started with:
https://github.com/sandfox/probot-baumpfleger

@RichardLitt
Copy link
Member Author

Good points, @agjohnson. I agree. I also don't know how I feel about Probot Stale, in general, but it was worth bringing up. I'm actually in favor of simply not including it as one of the one's we start with; I think that it's better to wait a bit.

I think we should update the triaging guides or simply send around a re-read to triagers about the label differences. If we all used the same labels the same way, it would be better for the whole project. Thanks for your clarifications.

Status: blocked seems to work for long-lived support issues, to me.

@humitos
Copy link
Member

humitos commented Jun 4, 2018

Anthony opened a PR regarding the guidelines upgrade at #4180

@agjohnson agjohnson added the Accepted Accepted issue on our roadmap label Jun 8, 2018
@humitos humitos added Needed: design decision A core team decision is required and removed Community Effort labels Jan 7, 2019
@humitos
Copy link
Member

humitos commented Jan 7, 2019

I want to start working on this because I think this could have been very useful and the effort that we need to set this up is probably smaller than the one we need to keep our issue tracker clean.

I'm marking it as design decision because we may want to tweak more things or setup more aggressive bots still, but I will start with the simple ones/not invasive.

@RichardLitt
Copy link
Member Author

Thanks, @humitos. Looking forward to seeing these. I think we should also add a note to the contributing docs about having bots and what they do, too, when we add them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Needed: design decision A core team decision is required
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants