Project board / issue / PR automation

[cameel]

Replaces #8969 as the catch-all issue for board automation.

There have been a lot of ideas flying around related to boards so I thought I'd gather them in a single issue. Ultimately we may want to split it into smaller issues if some parts turn out to require significantly more effort but I think most of these will be fairly easy and the biggest bottleneck here is making decisions about what exactly we want and how to achieve it. For this a single list is easier to manage and update.

1. Welcome note for external contributors
   • Automatically posting a short message welcoming the contributor in new external PRs (https://github.com/ethereum/solidity/blob/develop/.github/workflows/welcome-external-pr.yml).
     • Should link to the Contributing page.
     • Should link to the review checklist.
     • Should invite the contributor to ask questions on #solidity-dev.
   • Needs decision: what about solc-js?
2. Handling stale issues
   • Initial implementation: Add workflow to label and comment stale issues and PRs #13499.
   • Needs decision: specific rules what and when to warn/close.
   • Needs decision: what about solc-js?
   • Do dry-run and evaluate results.
   • Enable.
3. Handling stale PRs
   • Initial implementation: Workflow to label and comment stale pull requests #13522.
   • Needs decision: specific rules what and when to warn/close.
   • Needs decision: what about solc-js?
   • Do dry-run and evaluate results.
   • Enable.
4. Board automation
   • Adding new issues in the solidity repo to the Triage column on the board (https://github.com/ethereum/solidity/blob/develop/.github/workflows/triage.yml). Note: It only works for project boards at repository level (i.e. GH Project Classic).
   • Blocker: permissions for the bot (https://github.com/ethereum/devops/issues/1128).
   • Moving triaged issues to the right column
     • An issue is considered triaged when it has at least the effort and impact labels.
     • An triaged issue without a desirability label goes to a column for issues that need a decision.
     • An triaged issue with a desirability label but with needs design goes to design backlog.
     • An triaged issue with a desirability label and without needs design goes to implementation backlog.
   • Moving PRs with takeover label to the Takeover column on the focus board. Add removing them when the label is removed.
   • Handling issues from solc-js as well in all of the above.
   • Automatically archive issues after a release has been posted on GitHub
5. Automatic PR labeling
   • external contribution label for PRs submitted from people not in the Solidity team.
   • Adding has-dependencies label for PRs or issues that have "Depends on #<PR/issue number>".
   • Labels for simple cases where PRs touch only selected files (we'll have to still apply then manually in mixed cases):
     • documentation label for PRs touching only files inside docs/, READMEs and maybe a few other docs files we have.
     • testing if the PR only touches tests.
     • optimizer if the PR only touches optimizer source.
   • Handling PRs from solc-js as well in all of the above (when it makes sense).
6. Random assignments
   • Needs decision: do we want this?
   • Randomly assigning team members to issues that need triage.
   • Randomly assigning team members as reviewers for external PRs.

[cameel]

Two more issues that are related to automating PRs, though IMO not enough to be a part of the list above:

• Make whitespace errors from check_style.sh easier to understand for contributors #13617
• check_style.sh fails to post comments in external PRs #13616.

[cameel]

@r0qs Update regarding (2). Before we can start closing stale issues, we need to deal with closing very old issues from the backlog. As discussed with @NunoFilipeSantos, we're going to do this via our board automation. So let's repurpose #13672 for this. Later, when we're done with closing the backlog, we'll turn it into actual stale issue bot. Here's my proposal on how to do this:

• Make it actually close issues (currently it's only adding the label). I think that for backlog cleanup we should close them immediately, without marking as stale.
• Bugs and roadmap issues must be excluded. We should consider also excluding issues triaged as must have or must have eventually.
• Only issues older than a hard-coded cut-off date should be closed. @NunoFilipeSantos will provide the initial date and once we enable the action, we'll also be gradually moving that date forward in further PRs to include more and more issues until we decide we're done.
• @NunoFilipeSantos should provide the message we're going to post in these issues. IMO the message should say why we're closing these issues and that people are free to reopen them if they think they're actually still relevant.
• Issues closed as a part of this cleanup should get a special label so that we can easily identify them.
• Let it run slowly, so that we're not immediately flooded by hundreds of notifications and comments from people who get pinged by the issues being closed and respond. Maybe something like 10-20 issues per day? This will also let us review what's getting closed and react if needed.
  • We'll also need a way to prevent reopened issues from being closed again. How do we do that?
    • My suggestion would be to have the bot close only issues which have no desirability label (i.e. untriaged + those triaged for which we did not decide whether we want them) or where desirability is only nice to have.
    • Alternative solutions: we could use a moving time window so that the bot does not go back to issues it already processed or mark them with yet another label.
• We should do that with solc-js as well. Though not sure if in parallel of after solc.