Pitch: automation workflows

[rjpaskin]

Automation workflows

As a user
I want to be able to tell the app to react to events
So that I can be better informed
Or save myself time/effort from doing things manually
And free myself from having to remember to do said things myself

Proposal

Users should be able to create a workflow which consists of a single trigger,
and one (or more?) action that is performed by the app.

Both triggers and actions are predefined, each with their own set of options for the
user to set.

Possible triggers:

• Ticket is moved into a swimlane (option: which swimlane)
• Ticket is labelled (option: which label)
• Ticket is unlabelled (option: which label)
• Connected pull request is merged
• The "next action" (the button that says "merge it" or "fix conflicts") has changed for a pull request

Possible actions:

• Move ticket to swimlane (option: which swimlane)
• Add label to ticket (option: which label)
• Remove label from ticket (option: which label)
• Send a Slack message (options: channel, message)
• Send an email (options: email address, message)
• Merge an open pull request

Workflows can either be "personal", in that only the creator can see and edit them, or "board-wide", where all users can see or edit them.

Question: is there any instance beyond messaging where an action would be better 'private'? In which case, there are really two strands here - the first automating actions on the board, the second sending notifications

Example workflows:

• A branch is created (by being pushed) that contains a ticket number => move the referenced ticket to the "Development" swimlane
• Pull request is connected to a ticket => move the ticket to the "Code Review" swimlane
• A connected pull request is merged => move the connected ticket(s) to the "Code Review - Done" swimlane
• A ticket is labelled "rework" => notify the developer
• A ticket is unlabelled "rework" => notify the project owner

Constraints

• Actions would only be compatible with suitable triggers - i.e. we need a way of obtaining the object to act on from the trigger, so an action that changed a PR may not be compatible with a trigger that related to a ticket.
• Actions would check before running that the conditions that caused them to be triggered were still true - for example, an action that moved a ticket in response to a label being added would check that the label was still present
• Actions would not 'enforce' themselves - for example, if an action moved a ticket into a swimlane, then a use moved the ticket to another swimlane, the app would not try to revert the move. Generally the philosophy should be that the app should try to be helpful, but accept that the user knows best and defer to them.

Alternatives

• GitHub Workflows covers a look of the same ground, with more flexibility in the triggers (minus the FlightPlan-specific bits around moving
  tickets between swimlanes or PR-ticket connections, though there is a mechanism for us to report these back to GitHub as generic RepositoryEvents).
• Having the workflow hardcoded in the app, or in a YAML config file in the repo?

Out of scope

All to reduce complexity:

• Multiple triggers, or 'and/or' logic
• Conditional logic on actions
• Triggers involving deployments
  This needs deployment notifications to be implemented and is better done as a separate piece of work