Good Workflows đ
We use BitBucket Server at work for code reviews and JIRA for issue tracking. They are ok, but the workflow is a bit⊠icky. For example, in BitBucket after youâve completed a code review you can either select âneeds workâ or âapprovedâ. But âneeds workâ seems a bit harsh when you only had a question, so people donât use it. But this means the ticket is still in the âsomeone needs to review thisâ bucket, which creates extra work when others look at it and see that thereâs a comment⊠over and over and over. The more developers you have the worse this becomes. Itâs basically a polling loop running for each developer multiplied by open pull requests. Running polling loops in human brains isnât good for productivity or happiness!
JIRA has similar issues and the âsolutionâ theyâve implemented is to send tons of notification mails. This is not a good solution because notifications are about changes, not the current state. But I donât care if the ticket went from open to resolved to open to resolved to open. I care that itâs open. Now. Especially when coming back from a vacation one has to deal with this by deleting all mails from JIRA and BitBucket because they are useless in bulk, and then you inevitably miss the one mail in that pile that told you that you need to respond to something. The workflow for that is that hopefully someone notices and taps you on the shoulder.
The basic mistake here is that there is no concept of âwho has the ball?â You donât really want a âneeds workâ button, you want a comment field plus a ânow the developer has the ball againâ button. And then you need a tool to give you a current list of all things (PRs, issues, whatever) you have the ball on (we have one: DevBar + some proprietary and team specific logic). We are working around these limitations the best we can, but ultimately we canât rename the âneeds workâ button so people still donât want to press it because itâs a bit rude.
A plea
If you write an application with some kind of workflow in it, consider the concept of âwho has the ballâ as the primary unit of interaction. Think of machines as things that can âhave the ballâ, for example âwaiting for tests to runâ, âwaiting for deployâ, âclosedâ can be considered places where the ball is at.