Readthedocs.org: Add Probots

[RichardLitt]

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?

• ProBot Request Info (https://probot.github.io/apps/request-info)
  
  
  
  • Follow up when a user opens an issue/PR with no description
  
  
• ProBot Welcome (https://probot.github.io/apps/welcome)
  
  
  
  • Welcome users who open their first issue/PR
  
  
• ProBot Lock (https://probot.github.io/apps/lock)
  
  
  
  • Lock threads that have been closed and have no activity for 180 days to prevent random drive-by comments
  
  
• ProBot No Response (https://probot.github.io/apps/no-response)
  
  
  
  • Close issues that have "need more info" label after 7 days with no response from issue opener
  
  
• ProBot Stale (https://probot.github.io/apps/stale)
  
  
  
  • Mark issues with no activity in 90 days with a "stale" label and leave a comment, then close the issue if there's still no activity 7 days later. Issues with the "accepted", "enhancement", or "bug" label will never be marked stale.
  
  
• ProBot WIP (https://probot.github.io/apps/wip)
  
  
  
  • Prevent merging of PRs with "WIP" in the title
  
  

What do you think?

[agjohnson]

@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]

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]

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]

Anthony opened a PR regarding the guidelines upgrade at #4180

[humitos]

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]

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.