Roll out `lock-threads` across shinyverse

[gadenbuie]

20 and #23 added a shared workflow for locking closed and inactive issues.

We now need to roll out the lock-threads workflow to shinyverse repos. The list below is not every repo but the most popular repos. The count of would-be-locked issues below is valid as of 2023-07-19.

- [ ] [rstudio/shiny](https://github.com/rstudio/rstudio): (1747 closed inactive issues)
- [ ] [rstudio/plumber](https://github.com/rstudio/rstudio): (440 closed inactive issues)
- [ ] [rstudio/shinydashboard](https://github.com/rstudio/rstudio): (205 closed inactive issues)
- [ ] [rstudio/leaflet](https://github.com/rstudio/rstudio): (330 closed inactive issues)
- [ ] [rstudio/flexdashboard](https://github.com/rstudio/rstudio): (276 closed inactive issues)
- [ ] [rstudio/py-shiny](https://github.com/rstudio/rstudio): (161 closed inactive issues)
- [x] [rstudio/bslib](https://github.com/rstudio/rstudio): (175 closed inactive issues)
- [ ] [rstudio/crosstalk](https://github.com/rstudio/rstudio): (29 closed inactive issues)
- [ ] [rstudio/thematic](https://github.com/rstudio/rstudio): (64 closed inactive issues)
- [ ] [rstudio/httpuv](https://github.com/rstudio/rstudio): (162 closed inactive issues)
- [ ] [rstudio/shinytest2](https://github.com/rstudio/rstudio): (141 closed inactive issues)
- [ ] [rstudio/htmltools](https://github.com/rstudio/rstudio): (126 closed inactive issues)
- [ ] [rstudio/promises](https://github.com/rstudio/rstudio): (32 closed inactive issues)
- [ ] [rstudio/websocket](https://github.com/rstudio/rstudio): (41 closed inactive issues)
- [ ] [rstudio/webshot2](https://github.com/rstudio/rstudio): (9 closed inactive issues)
- [ ] [rstudio/sass](https://github.com/rstudio/rstudio): (41 closed inactive issues)
- [ ] [rstudio/gridlayout](https://github.com/rstudio/rstudio): (12 closed inactive issues)
- [ ] [rstudio/chromote](https://github.com/rstudio/rstudio): (29 closed inactive issues)
- [ ] [rstudio/learnr](https://github.com/rstudio/rstudio): (282 closed inactive issues)

Are the repos on this list that should be removed or repos that should be added?

Roll out questions

Once enabled, the workflow will lock 50 issues per run. This number is not configurable. The long-term goal is to run the workflow once per week (early Monday mornings).

While the main workflow parameters are set in the shard workflow, the run schedule is set in the workflow in each repo. If we roll out the same workflow schedule to all the above repos at the same time, we'd lock 740 issues the first time the workflows run, tapering down from there.

Should we roll out the workflow...

• ...slowly across repos (starting small and working up), once per week?
• ...to all repos and just take the notifications hit?
• ...with an initial schedule that runs daily or staggers our repos across all days? And then follow up with a second rollout that moves to the weekly schedule?
• ...to close much older issues, e.g. 365 * 2 days, and then roll out waves to reduce issue age?

[nealrichardson]

IMO I'd do it all at once so I can ignore/filter out all of the notifications from that moment, rather then get periodic dumps of notifications that I have to inspect to see if it's another automated thing.

[gadenbuie]

@nealrichardson That's a great idea. In that case, I'd want to roll out in two waves:

1. Initially set the schedule to once every hour to run over the weekend. It would take ~36 hours for all old threads to be locked, but we can disable notifications during this period. (And we don't tend to get many community notifications over the weekend anyway.)
2. Follow up with a second wave to update the schedule to lock issues once per week.