GitHub Actions: Automate In Progress Issue Updates: Add Update Label

[Aveline-art]

Overview

Dependency for #1976 and #1977

As a developer of the team, it is useful to have automation on the project board for tasks that are done on a regular basis by the leadership team.

Action Items (for designers)

• Discuss with PM team and come up with a flow for weekly update reports on the project's assigned issues
  • Some (but perhaps not all) discussion items are in this comment
• Discuss conclusions with the developer team so that this and related issues can be remade to more accurately reflect our desired flow
• Remove the "role:design" label, and include the "role:backend" label
• Recycle this issue back into the backlog for developers
• Also resolve the dependencies on the above issues, and decide whether or not those issues are still needed.

Action Items (for developers)

• To be determined

Psudo-code

• Trigger: At a certain time every week
• Retrieve issues that matches the following criteria:
  • If the issue also has an assignee and,
  • If the Linked PR is added before the last 3 days and,
  • If the issue has been assigned before the last 3 days and,
  • If the issue is in the 'In Progress' column:
    • Add the 'To Update !' label.

Checks

• Automation 1:
  • Note check here

Resources/Instructions

Never done GitHub actions? Start here!

Note that you might want to do something outside the scope of the above psudo-code. If so, be sure to leave comments in your PR or this issue that justifies your reasoning. If you feel you need guidance, be sure to reach out! We cannot foresee whether this issue is solvable, or what hard decisions have to be made, but we would love to hear and help you!

Additional resources:

Events that trigger workflows
Workflow syntax for GitHub Actions
GitHub GraphQL

[Aveline-art]

Current flow of In Progress issues:

• Every Friday, the "To Update !" label is added to issues that follow these criteria
  • The issue is in progress
  • An update has not already been made
  • The issue has an assignee and does not have a linked issue
• Once the update is made, the "To Update !" label needs to be removed by the assignee.
• If an update has not been provided for over 2 weeks, the assignee is to be removed, and the issue is recirculated.

[Aveline-art]

Automation 1

• Progress: Automation 1 is mostly finished, except it is currently impossible to filter issues by their columns using Restv3. GraphQLv4 will work, but does require vigorous finesse and testing as the technology is new and documentation is scant.
• Blockers: Requires more research.
• Availability: Random time here and there on weekdays
• ETA: A week

Automation 2

• Progress: Not started, but feedback is needed on whether this automation is needed, as it might run the risk of over-automation.
• Blockers: Requires a brief discussion.
• ETA: Half a week, after Automation 1

Automation 3

• Progress: A discussion is needed on the design requirements of this automation. When we say an assignee is inactive, what is the definition of "inactive"? What are the cases where this definition can break?
• Blockers: Requires discussion
• ETA: Could be a week, could be a month, depending on requirements.

[Aveline-art]

@Sihemgourou @ExperimentsInHonesty Is there a label for when an item has been inactive for about 14 days?

[Aveline-art]

• Progress: Eureka! Managed retrieve the issues from 'In Progress' via v3API! Oh joy! The issue now is that the many api calls will get expensive, whereas v4 will suffice with only one call. For now, v3 will be used as the more familiar REST API. Since I am able to retrieve from 'In Progress', I can assume that all issues have an assignee!
• Blockers: The API (at least the Timeline API) does not seem to update as quickly as the website itself. This means that if a contributor made an update, the API would not be able to view it. Will see if the label API can do something to amend this problem.
• Availability: Some random time here and there.
• ETA: By the weekend!

---

Addendum:

The action is completed (#2006), and but before merging, a few intricacies of the design needs to be determined:

1. When should this be run?
2. There already exists a GHA that adds a comment when the 'To Update !' label is added. Should that GHA's function be merged with this one? The immediate pro, for the developer, would be that the GHA logs would be much cleaner, as the commenting GHA runs for every label added (regardless of label name), creating an empty log for each run. The con, I imagine, would be that the comment no longer appears when the label is added manually.

[Aveline-art]

As discussed during the meeting July 25 2021, this issue will be passed onto the UX team. Several key points need to be answered before this issue (and other related issues, see below) can proceed:

• The main question is: what is the flow of the team's weekly update reports? How should the labels be used ("Status: Updated" and "To Update !" and maybe others) to support that flow?
• When should updates be asked for?
• Under what conditions is an update needed?
• Under what conditions should an assigned issue be recycled back into the backlog?
• Which tasks should be automated, and how, and which tasks should be manually audited by a member of the team?

As #1976 and #1977 both are related to this issue, I have moved both into the icebox with this issue as the main dependency.

[github-actions]

@ Please add update

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. Pictures: "Add any pictures of the visual changes made to the site so far."