Create workflow to track time since a project item's status changed

[jmbowman]

It's currently easy to lose track of items that we think someone should be working on, but have actually just been sitting idle for weeks without a clear party responsible for taking next steps. To make such cases easier to spot in GitHub Project boards, we'd like to add the ability to add an auto-populated field in a project's items displaying how long it has been since each one changed status. There's no built-in GitHub Projects feature for this, and I've had no luck finding an existing workflow in the GitHub marketplace for this, but it looks like it should be feasible to implement.

A/C:

• Create a workflow to iterate over each item in one or more specified projects and update a specified number field to contain the number of days since the item's status last changed.
• The field name and list of projects should be input parameters.
• The workflow should be packaged so as to allow listing in the GitHub marketplace (this feels like it would be generally useful to a lot of people).
• Add an appropriate field to the Maintenance project at https://github.com/orgs/edx/projects/17/
• Create an instance of the workflow that successfully sets the new field.
• Schedule the workflow to run daily.
• Make the new field visible in at least the "Board" tab (we probably want it visible in all the team-specific tabs also).

I think the way to implement this is via the GraphQL API:

1. Fetch all the items in the specified project.
2. For each one:
   1. fetch the timeline for the represented issue.
   2. Starting with the most recent event, iterate backwards in time until a MovedColumnsInProjectEvent or AddedToProjectEvent for the project in question is found.
   3. Calculate the number of days since that event's "createdAt" time.
   4. Send an update for the value of the target number field in the project item.

There are very similar events available via the REST API, although the documentation implies that these are only for "Classic" Projects, which were specific to individual repositories.

Useful references:

• https://docs.github.com/en/graphql
• https://docs.github.com/en/graphql/overview/schema-previews#project-event-details-preview

[jmbowman]

As Ed discovered, this seems to be blocked on a bug in GitHub's GraphQL API:

• https://github.com/orgs/community/discussions/49602
• https://github.com/orgs/community/discussions/57326
• Integration with V2 Projects github/issue-metrics#57

Switching to an event-driven approach won't work either, as the only project-related events that can trigger workflows are for "classic" projects, not modern "v2" projects.

Axim's workaround for now is described in https://discuss.openedx.org/t/pull-requests-review-delays/10497/26 .

[jmbowman]

There is a workaround in https://github.com/orgs/community/discussions/49602#discussioncomment-6768032 which basically scrapes the status change timeline from each issue's HTML page. Hacky, but could work if we really want it before they get around to fixing the API bug. Might hit problems in longer-running issues where part of the issue history is collapsed until you click to load and display it.