Ask HN: What is the need for Jira status workflows?
In JIRA, you can configure workflows to control the movement of an issue's status. For instance, you can enforce a rule where an issue cannot move directly from "In Progress" to "Done" without first transitioning through an "In Review" stage.
Question: I never really understood the importance of this feature, do you have use cases where you've found this feature particularly helpful?
We're considering implementing similar workflow customization in Tegon, our open-source project management tool. What do you think? Is this feature needed? Needed? No - it is ultimately a control mechanism that could also be handled within the team itself, not enforced by Jira. But it is helpful - maybe you have a new team that needs some guide rails. Maybe you open up the board to your organization and want free flowing cards into the board, but a gate on cards actually getting assigned to the dev team without a leader checking it out first. There are numerous situations where it could be applied, none of which are critical, many of which are helpful. On my team, is has been used to prevent developers from pushing code straight to production without being tested first. After some of those updates caused high impact bugs. Could you help with how the workflow looked like? How does it ensure that the code is tested? Strictly speaking it doesn’t. It ensures someone else has moved the card to the next status (or, that automated tests have passed and moved it to the next status by automation) You can permission who can move to what status. As a random dev, I personally wouldn’t recommend it unless there are legal requirements for such separation (or your org has lawyers that think such requirement exists) As one example, if your work on something that's audited, this can be useful, for the papertrail: you document (in an enforced way) when and who worked on the different stages of a piece code, which also gives you some extra info when doing failure root cause analysis (where did it go wrong by whom). On projects which are done in the style of code-quick-test-in-prod I think it is usually less useful. Ahh, yeah paper trail makes sense. But the ownership aspect of where it went wrong can we understand without the workflow restrictions also right? For example we use a very restrictive Jira support ticket process to enforce our ISO compliance. Restricting transitions is also necessary if you use approvals in your workflow. If you don't understand the need of ticket workflows for a project management tool, you need to get back to the basics and understand what's project management. Tools are just tools, project management is about managing people's work and expectations.