It's nothing novel, but it works well for us and we think will work well for other teams, even large ones.
That way if you don't want to figure out what works best for you and want to be told what to do, you can just set one of these workflows and disseminate that information to the people who will be using it.
* Pivotal Tracker is the SaaS software you're thinking of.
* Pivotal Labs is the agile and lean engineering/design/product/data science consultancy, from which Pivotal Tracker first emerged as a product.
* Pivotal is the parent company formed from Pivotal Labs and other products (notably Cloud Foundry, Spring, Greenplum, Gemfire) several years ago.
Disclaimer: I'm work at Pivotal Labs.
My first thought is we should add a "did you mean Tracker?" link somewhere, but that's got problems too. We work on a lot of software.
This is what I get for not pair-posting.
It sounds like you could use the same kind of thing. Someone entering an issue doesn't need to be presented with a JIRA server and told to go at it. A tool like JIRA has some tools for guiding users (e.g. embeddable, customizable javascript forms). And where JIRA isn't cutting it, any self-respecting tool has an API that gives you all the power in the world. You want a dashboard that shows you just the charts you want, and clearly explains what they're showing? There's a lot of material all around you to make building that for yourself easy. Wishing for an opinionated and rigid solution that happens to match what a project of nontrivial complexity needs is not realistic.
(I very much agree with your point)
the pull request is blocked until review is complete, and tickets are automatically closed with pull requests. it's a pretty great workflow
Unless by JIRA does this now you mean, "JIRA allows for a many confusing setups, leading to the above situation more often than not" I have to disagree here.
What it doesn't do is require a workflow. It is possible to start with a Scrum wf, then progressively change it into a waterfall hyena with cumbersome required fields and impossible permission-based transitions. In fact, I've met many people who have the opinion that JIRA is cumbersome, just to discover that their sysadmin is a knee-jerk person who blocks any initiative within their entreprise using misconfigured software.
JIRA isn't opinionated in the sense of OP. OP suggests that saying "We use [Bug tracker name]" is equivalent to saying "We're Scrum with branch tracking and timetracking", because the bugtracker would enforce checks and a layout without much possible configuration.
For example, Trello or Bitbucket Issues are quite opinionated bugtrackers.
Then rely on the users being smart enough to not hang themselves with the rope given.
What you're talking about is, as you said, bad management. The reason opinionated software comes and goes, and JIRA stays is specifically because just like you can build sync on top of async, you can build opinionated on top of flexible, but not vice versa.
I know that workflow, work item types, how to transition between states is kind of a deeply personal thing -- but often I wish I could just eliminate the mental overhead of trying to figure out how this project, manager, and team are using Jira/Rally/TFS/Trello/Pivotal and what state I need to put something at what time and which fields need to filled out and if we are using tags and why adding this critical bug to the current sprint is giving me a big scary warning and are we calling this a feature or a story or an epic or an enhancement or a task or a subtask and if I want to be looking at what this tool is calling a burndown chart or if its really the milestone progress chart in this project and what was that filter you used to see bugs that were open and also defined because I'm not seeing the bug that my customer is asking about and are we supposed to put new information as a comment or in the description or is it a new linked issue or a new child task or a new child bug or a link to the integrated wiki page...
(maybe I'm just the only one with these scars...)