Implementation Plan: Openverse Backlog project automation

[krysal]

Problem

We want to sunset the current project board as the Openverse backlog in favor of the new one which provides more funcionalities that GitHub have ben adding.

Description

To fully make the move there are several things needed (like automation, view configurations, etc, specified in another issue) plus instructing the people on how we would be using it. An implementation plan for this would be quiet helpful.

Additional context

Related to #818 and #1168.

[sarayourfriend]

I updated the title to reflect the format we've been using for other implementation plan issues.

@zackkrida Wanted to share some resources of existing GitHub apps I've found that might be easier to use than writing our own automation scripts for syncing labels and fields

• https://github.com/paritytech/github-issue-sync
  • This one might do the trick on its own but the documentation is pretty vague on how custom fields and labels interact. The code is a maze and I haven't deduced the behaviour entirely yet. It's definitely capable of automatically adding issues to projects.
• https://github.com/EndBug/project-fields
  • This one implements the field/label syncing that the new_issues workflow has.

I also wanted to request some new columns. Rather than the broad "in progress" and "done" columns, "blocked", "needs review", and "needs merging" columns would be helpful for getting an idea of what issues may need attention from someone on a daily basis. The blocked column would only show issues that were "in progress" and then blocked (i.e., we're trying to work on them), not issues that are in the backlog and blocked with no assignee. It should exist between the todo and in progress columns to represent visually the fact that the issue is "blocked" but in the pipeline of work. The MSR task for checking in on blocked issues could be changed to look at this view instead of all blocked issues to better align with the projects immediate priorities (unblocking an issue we're not trying to work on could be a distraction, for example).

Needs review should show any issue with an associated, non-drafted PR without changes requested and appear after the in progress column to indicate that it is not currently being worked on by the assignee and needs a review before it can move forward into the "done" column.

Needs merging should appear after needs review and only include issues with associated PRs that have two approved reviews.

I know these are likely to be complicated automations to write, but because I anticipate the implementation plan would have iterative steps that would each improve the project broadly, I think these could be added to the end of the list of steps once the potentially easier "immediate wins" are finished.

I also had an idea for the general implementation approach. Right now we're using an action in a separate repository, but I wonder if it would be easier to write scripts compatible with the github-script action that could be unit tested in the repository and use our existing tooling, etc.

[zackkrida]

@sarayourfriend this is great information and I'll look at these changes when I work on the plan this week.