Open philschatz opened 6 years ago
Listed below are some boards and examples of columns that could be mostly automated using the Automatically Add and Move Cards section described above. Note the a person can always move items on the board manually.
Trello Column | How Cards/Issues/PullRequests can automatically move into it |
---|---|
Backlog | New Issue (or it goes into another board) |
Needs Clarification | |
On Deck | assigned to a user? (was not assigned before) |
New PR (or reopened PR), all reviews done but not merged, has WIP in the title | |
Waiting for Code Review | has a Reviewer assigned |
Need Test Plan | PR reviews are Accepted (or PR is merged) |
Needs Deployment to QA/Staging | |
In Sprint Testing | |
Regression Testing | |
Ready to be Released | |
Done/Already Released | |
Will Not Be Released | PR is closed, Issue has wontfix label (and is closed) |
Trello Column | How Cards/Issues/PullRequests can automatically move into it |
---|---|
1A: Backlog Define Design Decomp | New Issue (or it goes into another board) |
1B: a15k Backlog | |
2A: DEFINE, DESIGN, DECOMPOSE | |
2B: UX Design | |
3A: Backlog Code | |
3B: CODE & PEER REVIEW | New PR (or reopened PR) |
4: UX REVIEW | PR reviews are Accepted (or PR is merged) |
5A: Functional Verification | Issue is assigned |
5B: Verified on QA | Add verified label |
5C: In Regression | |
5D: Ready To Be Deployed | |
Release 8.02.15-1 | |
Done: Assessment Network | |
Done: Will Not Release | PR is closed, Issue has wontfix label (and is closed) |
Trello Column | How Cards/Issues/PullRequests can automatically move into it | |
---|---|---|
Inbox for Prioritization | New Issue | |
Non-10K Backlog | ||
Winter 10K Backlog | ||
Coding | New PR (or reopened PR) | |
Editorial | ||
Production | ||
QA | PR reviews are Accepted (or PR is merged) | |
Done | Issue is closed | PR is closed |
Trello Column | How Cards/Issues/PullRequests can automatically move into it | |
---|---|---|
Backlog Define/Design/Decomp | New Issue | |
Backlog UX Design | ||
Define/Design/Decomp | ||
Backlog Develop | ||
Doing | New PR (or reopened PR) | |
Dev Verify | PR has a requested reviewer | WIP title is removed |
UX Review | Requested review from Fred | |
5A: Functional Verification | PR reviews are Accepted (or PR is merged) | |
5B: Verified on QA | ||
5C: In Regression | ||
5D: Ready To Be Deployed | ||
Release 8.02.15-1 | ||
Done Not Released | Issue is closed | PR is closed |
The 1st-level list describes the category of features that others have expressed as important, and the 2nd-level list describes how GitHub Projects can address those feature requests
+
on a column on the Board:github:
emoji (only enabled for the #cnx
channel for now)@mention
individuals or Teams, Assigning/Reviewing/Commenting are all emailed... Can [Unsubscribe]
if no longer participatingOther issues that may arise:
GitHubproject-bot - Automatically add and move Issues/Pull Requests on a Project board
GitHubstaxly - :robot: beep boop
This issue contains items that point at manual bookkeeping (error-prone) we do in our current system and how they can be solved using GitHub Projects for Organizations. (All of the screencaps are working code that you can try today!)
(vote on this idea below)
Accurate Sprint Progress
Currently, there are several places where manual effort causes things to be missed. Automation can help us with these. For example, development work is done in GitHub while PM status is in multiple Trello Boards and time/effort recording is in TrackingTime. This leads to multiple different places that need to be manually kept in-sync. An example story would be:
Click me to expand the story (it's a lot of steps)
1. An issue is discussed and discovered in slack 1. A person finds the right board on Trello and copies an existing template to create a Card 1. A PM adds the correct labels and associates the card with a Key Deliverable somehow (maybe an additional label) 1. The dev ("dev1") opens Trello and finds the Card to work on 1. The dev adds a time estimate to the Trello Card 1. The dev begins working on the Card 1. The dev submits a PullRequest to fix the Issue 1. The dev opens Trello and finds the Card 1. The dev updates the time on the Card 1. The dev moves the Card to the "Needs Testing" column 1. Another developer ("dev 2") opens Trello and finds the board 1. Dev2 finds the Card 1. Dev2 clicks the Pull Request 1. Dev2 reviews the code 1. Dev2 re-opens Trello, finds the card, and updates their time 1. Dev2 moves the Card to the Testing column 1. QA repeats a similarly-complicated process that dev does, but it includes deploying the code for testingAutomatically Add and Move Cards
Currently:
With Projects, the cards can move automatically when any of the following occur:
You can see an example of this by checking out these Projects that, with zero effort, already move Cards around automatically as Issues/PullRequests are updated:
Note: The moving logic can be configured differently for each board the Issue/PullRequest is in.
Quickly Create a Card (with context)
Currently, discussion frequently happens in Slack and then a Card is created.
With Projects, anyone can convert a Slack discussion into a card by just adding a
:github:
reaction (or 🌲 ). A Card is automatically created on the appropriate Project with a link to the Slack discussion. This card can then be easily moved but it is not lost.Accurate KeyDeliverable Progress
Currently, a Card can only be on one board. This makes it difficult to know the status of larger concepts like KeyDeliverables, resorting to labeling.
With Projects, cards can be on Multiple Boards.
No app needed, just webpage links
Automated reporting and burnup charts
As people update/move cards, the charts update. No waiting, or running scripts.
Why spend $$$k for 3rd party?
... when we can spend that money internally to have a tool that works for us.
Disadvantages
Vote!
What do you think? (click a bar to vote)