3 ms·

So, instead of an issue tracker you use a task tracker. Which is like an issue tracker. But different in ways the article actually fails to articulate very well

So, instead of an issue tracker you use a task tracker. Which is like an issue tracker. But different in ways the article actually fails to articulate very well. I'm actually a CTO and product manager. We use Asana for high level planning and github issues for tracking detailed technical work. We design using Figma. Our developers don't go near Asana generally. We have our roadmap and backlog in Asana though and we track some non technical topics there for e.g. management, hr, sales, support, etc. It's good for high level stuff and usable by non technical people. And since I'm in charge, this is an Atlassian free company and that's not an accident. I can work with their stuff but I prefer using the tools I mentioned over their stuff. The reason I like github issues for product management is that they are easy to connect to pull requests and you can close them by mentioning them in commit messages. This cuts down on process bureaucracy, which means less work for me. IMHO any issue tracker needs similar deep integration with the development process like that. End to end life cycle tracking from inception to deployment for any feature and enhancement is key. I also love using meta tracking tickets where I can easily convert TODO items into new tickets, refer existing tickets and PRs, etc. From a project and product management point of view that's great. Labels, milestones, etc. make this easier. And of course being able to use Markdown everywhere is nice too. It's not perfect unfortunately and I'd love a unified ui with tickets from all our github repositories. Their project tool is a weird one; on paper it could do that. But it seems unable to do any sensible integration with the issue tracker unless you configure a lot of actions to copy things over which seems madness to me.

SigKill9 4y ago
Thanks for your feedback! What about task trackers do you think we fail to articulate very well? We try to explain how the design of issue trackers fail to address the needs of how best practices of product development are described by certain authors (Marty Cagan, John Cutler, etc.). I think we support everything you mention here, but at the same time removing some of the hurdles that many teams experience in getting an empowered team to work well together.
- jillesvangurp 4y ago
  Just like every issue tracker. The distinction is nonsensical to me. They are all item trackers. You define what the items mean to you; not the other way around. I've used everything from post-its, spread sheets, text files, jira, and all the rest. It doesn't matter what you use; just how you use it. What I value is low friction usage. It's why I hate Jira because all the key operations involve modal pop ups and a generally high level of friction, lots of waiting for stupidly slow APIs, etc. Sucks all the momentum out of any meeting where you want to focus on content rather than stupid tools. What I explain in 3 seconds shouldn't require 3 minutes to mirror in the tool. It's what I love about Asana. Because it's just type, enter, type, etc. to create issues. Multi select with the arrow keys or control clicking, and boom labels, assignees, etc. added. That's low friction. GH issues strikes a good balance. Create a ticket, add some checkbox list, convert individual list items to issues by clicking them. Nice. Could be better but it works. I have zero experience with Kitemaker, so I'm not going to criticize it. But to me it looks like just another tool. What's so great about it? The article just descends into a nonsensical and completely artificial distinction between issues and goals. Why not do both? Why have two tools? Sounds like friction to me. Or impedance mismatch.
michaelsalim 4y ago
Would you be available for a quick chat? I'd love to hear more about this! Especially on the things that can be improved on your current setup. I actually have a closed beta on a product that allows you to have a unified ui for tickets across github repos. Perhaps it'll be a good fit.

SigKill9 4y ago

Thanks for your feedback! What about task trackers do you think we fail to articulate very well? We try to explain how the design of issue trackers fail to address the needs of how best practices of product development are described by certain authors (Marty Cagan, John Cutler, etc.). I think we support everything you mention here, but at the same time removing some of the hurdles that many teams experience in getting an empowered team to work well together.

jillesvangurp 4y ago
Just like every issue tracker. The distinction is nonsensical to me. They are all item trackers. You define what the items mean to you; not the other way around. I've used everything from post-its, spread sheets, text files, jira, and all the rest. It doesn't matter what you use; just how you use it. What I value is low friction usage. It's why I hate Jira because all the key operations involve modal pop ups and a generally high level of friction, lots of waiting for stupidly slow APIs, etc. Sucks all the momentum out of any meeting where you want to focus on content rather than stupid tools. What I explain in 3 seconds shouldn't require 3 minutes to mirror in the tool. It's what I love about Asana. Because it's just type, enter, type, etc. to create issues. Multi select with the arrow keys or control clicking, and boom labels, assignees, etc. added. That's low friction. GH issues strikes a good balance. Create a ticket, add some checkbox list, convert individual list items to issues by clicking them. Nice. Could be better but it works. I have zero experience with Kitemaker, so I'm not going to criticize it. But to me it looks like just another tool. What's so great about it? The article just descends into a nonsensical and completely artificial distinction between issues and goals. Why not do both? Why have two tools? Sounds like friction to me. Or impedance mismatch.

michaelsalim 4y ago

Would you be available for a quick chat? I'd love to hear more about this! Especially on the things that can be improved on your current setup. I actually have a closed beta on a product that allows you to have a unified ui for tickets across github repos. Perhaps it'll be a good fit.