Other tools primarily track tasks or issues. In Kitemaker, you will track work items representing features, fixes, and experiments you plan to ship to your users.
Either this doesn't express the intent properly, or it summarizes as 'you call it issues, we call it work items' i.e. not really a difference. From the screenshots it also doesn't really look too different from other software I'm using (work items, like in other issue trackers, have labels and priorities and members and so on, can be put in a roadmap, etc.). My takeaway would be: if you want me to sign up to try this, you should highlight differences with say Jira/Gitxxx premium/...
Thanks for good feedback! Noted! It's always hard to convey how you are different in a few words on a webpage. Teams that do try Kitemaker find us quite different, but getting the message across on a page that people (mostly) skim is not super easy.
You could even go a step further and play the SEO game by creating landing pages for all the comparisons. Ie. vs Trello, vs Jira, vs Github Issues. Zapier did it (and automated) with success.
Far from a time-wasting "SEO game", comparison pages would be highly informative content (an unavoidably detailed and accurate product description) and a very good advertisement (showing and not merely telling how and why whatever one's currently using or considering is inferior).
We should be focusing on what we plan to deliver to our users, regardless of the size. This is at the center of “outcome” before “output”
What I'm struggling with is seeing exactly how tracking a huge, "fluffy" outcome would be an improvement. For example, at my work we recently got a fairly big customer. As part of that, we will need to integrate with about 30 of their systems as well as implement a new API for them to send data to us.
Reading what you've written naively, it seems to me we should have a single "Integrate customer Foo" task to track. Without further details, I struggle to figure out to what degree this would be an improvement to what we're currently doing, which is using JIRA issues for high-level stuff like "integrate with invoicing system A", with a bunch of sub-issues for the details.
It could very well be we're missing out on something amazing, but without any concrete examples to compare to what we're doing, it's hard to determine. At least for me.
They can and should. And it turns out that teams can improve an existing task writeup simply by adding an explicit outcome goal and metric, such as: "Aim for outcome X as measured by Y".
Co-founder at Kitemaker here. You're exactly right. However, when people start micro-splitting deliverables down into tasks, those metrics and outcomes tend to get lost in the shuffle.
The way we're structuring things in Kitemaker (large, collaboratively edited work items) is an attempt to prevent that. But of course it's not the only way to achieve it.
Awesome if you can make it work in your current tool of choice! As the article mentions, another way teams have solved this is by augmenting their issue tracker with a document-based tool like Notion or even Google docs and motivating their team to stay on top of those outcomes.
Thanks for your comment! Don't disagree, but issue trackers are mainly designed to make you track (individual) tasks. If you make your issue represent outcomes, we have found that teams often feel like they are trying to force a square peg into a round hole. Your mileage might vary, though :)
The title is problematic, because the thesis of the article is not that issue trackers are harmful, but that using them for a product development workflow is problematic.
I’m going to call them bug trackers from here on, because I don’t like the name “issue”, which I find an insipid term that’s kinda part of the problem.
Generalising and simplifying (to the point of at least mild inaccuracy), bug trackers are excellent in open source work, but work trackers and planners are more useful in business.
Also a remark of my own: bug and work trackers both have a painful tendency to slowly increase in scope and try to cover each other’s purposes, but poorly. They’re similar, and there’s definitely some overlap, but they’re quite different in how you treat them, most of all in how you maintain them. An automatic stale bot may be reasonable in a work tracker (though it’s not ideal), but has absolutely no place in a bug tracker. (I have various comments on HN up to +76, and one outlier at +283, https://news.ycombinator.com/item?id=27274146, showing that lots of people agree with me in hating stale bots on bug trackers.)
Actually, what am I saying? Not just such trackers, not even just software, but human endeavour in general tends to scope creep and the problems that arise from it.
And yeah, the title was written in a way to be a bit provocative, but also pointing at that many (maybe most) teams use issue trackers for their product development flow.
Trouble with the title for this site is that a very significant fraction of the users will approach it from the open source perspective where bug tracking is what you want. :-)
I might perhaps title it “bug trackers aren’t good for tracking work” or “bug trackers aren’t good for product development workflows”. I like literal and direct (and often verbose!) in my titles.
I was thinking this was going to be about the transition from "using issue trackers to track what we're working on" into "we only work on tracked issues" mindset.
The former is using it as a tool, while the latter is using as a way to control.
Fair enough. The title was meant to be a bit provocative for sure.
The point we're trying to make is that a tool can help nudge you in a certain direction, and we're trying to make Kitemaker the tool that nudges you towards working in a way that gets the whole team focused on outcomes instead of focusing on small tasks.
If teams are able to achieve that in their current tool of choice, that's ok too. We just believe working in this way is healthy and productive and hope to see more teams thinking along these lines.
Thanks for your comment! The main point we wanted to come across is that issue trackers are _not_ designed for best of practice product development practices. Still, teams use the for product development, and there are challenges to that.
> ...we built Kitemaker. As far as we know is the only tool built specifically to help development teams work in a way that they can focus on outcomes.
This is where everybody would expect a screenshot, or at least a detailed comparison with the competition. Since you mention "Epics", you clearly have a certain competitor in mind: you don't need to be vague.
They haven't looked that far then. There's certainly other tools out there with similar aims. I work for Aha! who have a developers tool focusing on teams delivering outcomes, which works in parallel with our product management and roadmaps tool. It's a competitive space with interesting takes on the problem. It just so happens to be dominated by a large entrenched product that is/was primarily aimed at issue tracking.
I'm honestly a little confused here. For starters, the "X considered harmful" clickbait title that doesn't actually talk about X but about a certain use of X to sell you an alternative tool feels weird. I also don't think that "focusing on tasks or issues daily" is different from "not getting the right stuff out the door". That's just a problem of how you use the tool, isn't it?
But I honestly don't see the fundamental difference between this tool and, say, my Gitlab issue tracker. Not just from the home page but even going into the guide. You have work items, Gitlab has issues (funnily enough, I was just reading before that Gitlab is migrating under the hood to "work items" to integrate issues/epics/incidents into a single entity), both can break down a single item into multiple ones, have a collaborative document at the top, an activity feed, roadmaps, labels... I don't what's the feature that would make me migrate development workflow to yet another tool (with more costs possibly, because 100 work items doesn't look like much if you deal with multiple projects).
Easy one first - pricing. It's always a challenge but we try to find something that's reasonable when compared to the competition. We're not big fans of tools that do limited time feature stuff (this feature only works for the first two weeks unless you pay) so this is what we're trying for now. We're very flexible with teams as well. If they don't feel like they've gotten a fair chance to try it out, we raise the limit and let them keep trying for free. We'll gladly take your money once you're satisfied.
With regards to GitLab or any other traditional issue tracking tool - if you're able to get this sort of a workflow where your team is really focused on the outcomes and not mechanically processing tickets, then that's great! We're not building the only tool in which this is possible, just building a tool that we feel does a great job of nudging people in the right direction.
Thanks for you comment! Gitlabs issue tracker is one I'm not super familiar with. There are definitely other popular and well-known issue trackers which would, by design, make it harder than it should be.
Congratulations, might be a good product but now I could never consider it because "considered harmful" posts are not only incendiary but usually completely wrong and is 99% of the time someone who doesn't know what they're talking about trying to force deprecation onto everyone else.
The biggest problem I have with all those tools which imply that requirements are part of the ticket is that at some point you have no idea what your product looks like. I have seen so many times when a change is planned that does not take into account some of the use cases, because you have no visibility into those cases - they are buried somewhere in the hundreds of closed tickets. Once feature is released, the broken part is suddenly discovered and in the best case fixed few months later. In worst case buried as an open bug in the backlog.
When you start something new, it's not a big deal. Everybody loves to work on something new. Nobody loves working on legacy products, because they don't have enough documentation and full of bugs, driving up costs of support and becoming a pain in the ass of some CIO. Yet somehow all those fancy new tools focus on creating great experience for building something new. Plenty of decent software was written in the last 50 years, but we are burning the money, electricity and silicon to replace it, because we could not come up with methods and tools for building on top. Why it is always about integrating something like requirements and context into planning? Why not doing it the other way, integrating planning into requirements and context, being product-centric rather than work-centric?
This is very insightful feedback. Thank you for that!
One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker.
Thank being said, your comment has my gears turning on how we could do an even better job of it.
Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult.
For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it.
Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.
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.
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.
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.
We've discussed introducing automation to move done things to the archive periodically (just to keep the board tidy) but we haven't gotten many requests for automatically closing stale things. Yet.
Maybe there's a bit way to surface these old things and remind teams to deal with their skeletons.
Completely OT, but I'm a bit fed up with "X considered harmful" headlines. Considered by whom? No one says "Chocolates are considered tasty" to express a personal opinion. There's an implication of the opinion being held by "us", or a wide body whose opinion matters (like general public).
But these headlines pop up everywhere and, at best, present an opinion, usually of one person who neither surveyed a large group nor has the authority to make such claims personally.
I might write an article "Articles \"X considered harmful\" considered harmful".
> I might write an article "Articles \"X considered harmful\" considered harmful".
People were annoyed by those and wrote such an essay at least 20 years ago [1,2] (possibly there were others). Didn't help much, but generally fighting idioms/memes/fashion doesn't seem quite productive: perhaps it's more useful to focus on not being frustrated by those (and accept the way this phrase is used).
Edit: Though ranting about titles on HN is still a fine activity, not trying to discourage that. Just an idle musing on being more content with those.
We honestly started this company because there is a big gap between best practice product development and the tools that were available. I hope that if you read the article that you'd at least find some interesting (maybe provocative) content there. It's not intended as clickbait.
Most of the points raised in the article are opinions based on a limited understanding or use of issue trackers. For example:
One can easily ask, "why can’t issues represent outcomes?" They can, but they are not designed for it
You raise a point only to dismiss it and then defend it again.
Issues typically have only one assignee.
Yeah, because the assignee is the person working on it, managing it, owning it, etc. What good is it to list 5 people's names on an issue? If it's just to track it, you can already do that without assignment. If it's just to record "these 5 people are working on it", you can do that with a comment or in a description. If it's for change management, that's what a change management system is for, or you can use the issue tracker in lieu of one by adding subtasks per stakeholder.
They don't give you ample space to describe the problem and solution
What issue trackers have you been using? Jira gives you tons of space.
Issue trackers focus more on metadata and workflow than on supporting the team in collaborating, reaching decisions, and shipping to our customers
Maybe because those are all very different things? Collaboration involves chat, video conferencing, document sharing/group editing, email, using various enterprise systems, etc. Reaching decisions it actually can help with, but whatever. Shipping to customers involves delivery management software, customer support specialists, customer-centric portals, etc. Trying to build one thing that does all of that is insane. Even Microsoft wouldn't bloat up a single product like that.
Some issue trackers will even actively suggest scoping issues to be as small as possible, which is the opposite of what a sound product development framework will suggest
Because an issue tracker is for tracking issues... not... oh nevermind.
First, we should be aware of the shortcomings of the issue tracker. [...] The challenge is that you will end up tracking work in two systems.
Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.
> Because an issue tracker is for tracking issues... not... oh nevermind.
That's exactly the point we are trying make. Issue trackers are good at tracking issues, but now people use issue trackers to track everything, from product development to task tracking, which they're often sub-optimal for.
> Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.
That's the bit I think we disagree on. My co-founder and I have both managed very large teams at large organizations. If you start splitting up everything into different tools, suddenly product is entirely disconnected from development and vice versa. We've seen it over and over where a tool becomes a "PM's domain" and is totally disconnected from the reality of the developers' work.
Now obviously you can make it work with discipline, but you can make anything work with discipline. We think Kitemaker makes it easier for product/development/design by creating one place for them all to meet. I agree that there are different types of hammers, we do not try to replace git/figma/slack but rather integrate with them.
I think we mostly agree at a high level, we just disagree where the split should be between different tools and you don't like the click-baity style of the article (that's fair and we'll try to work on it next time)
So the tool seems to conflate specifications with work tasks. In my previous job (pretty much top-down btw) product owners did that as well in Azure DevOps. There were huge Product Backlog Items with lots of description and sketches. After the work was done nobody would look at them again, and they went to the pile of other completed PBIs. When you were touching the same place of the code again you would often wonder how the program should behave and usually left wondering, because it's impossible to find the specification again. What I really longed for was specifications checked in as markdown in git.
What I liked least about Jira was how it turned a project into a maze full of pages of boilerplate, all alike. I was continually walking the issue/subissue tree via hyperlinks, and the pages were slow to load, and sometimes I went in circles looking for something that turned out to be over on a Confluence page instead. There's so much visual noise with all the optional tick boxes & fields (that were not used), I got banner blindness - which contributed to my difficulties in finding things.
My solution was to manually maintain a bulleted list of links directly to the relevant issues.
56 comments
[ 2.4 ms ] story [ 101 ms ] threadEither this doesn't express the intent properly, or it summarizes as 'you call it issues, we call it work items' i.e. not really a difference. From the screenshots it also doesn't really look too different from other software I'm using (work items, like in other issue trackers, have labels and priorities and members and so on, can be put in a roadmap, etc.). My takeaway would be: if you want me to sign up to try this, you should highlight differences with say Jira/Gitxxx premium/...
So you'd like to see something along the lines of "in Jira you'd do it like XYZ, in Kitemaker it'd look like ABC"?
We should be focusing on what we plan to deliver to our users, regardless of the size. This is at the center of “outcome” before “output”
What I'm struggling with is seeing exactly how tracking a huge, "fluffy" outcome would be an improvement. For example, at my work we recently got a fairly big customer. As part of that, we will need to integrate with about 30 of their systems as well as implement a new API for them to send data to us.
Reading what you've written naively, it seems to me we should have a single "Integrate customer Foo" task to track. Without further details, I struggle to figure out to what degree this would be an improvement to what we're currently doing, which is using JIRA issues for high-level stuff like "integrate with invoicing system A", with a bunch of sub-issues for the details.
It could very well be we're missing out on something amazing, but without any concrete examples to compare to what we're doing, it's hard to determine. At least for me.
They can and should. And it turns out that teams can improve an existing task writeup simply by adding an explicit outcome goal and metric, such as: "Aim for outcome X as measured by Y".
The way we're structuring things in Kitemaker (large, collaboratively edited work items) is an attempt to prevent that. But of course it's not the only way to achieve it.
Awesome if you can make it work in your current tool of choice! As the article mentions, another way teams have solved this is by augmenting their issue tracker with a document-based tool like Notion or even Google docs and motivating their team to stay on top of those outcomes.
I’m going to call them bug trackers from here on, because I don’t like the name “issue”, which I find an insipid term that’s kinda part of the problem.
Generalising and simplifying (to the point of at least mild inaccuracy), bug trackers are excellent in open source work, but work trackers and planners are more useful in business.
Also a remark of my own: bug and work trackers both have a painful tendency to slowly increase in scope and try to cover each other’s purposes, but poorly. They’re similar, and there’s definitely some overlap, but they’re quite different in how you treat them, most of all in how you maintain them. An automatic stale bot may be reasonable in a work tracker (though it’s not ideal), but has absolutely no place in a bug tracker. (I have various comments on HN up to +76, and one outlier at +283, https://news.ycombinator.com/item?id=27274146, showing that lots of people agree with me in hating stale bots on bug trackers.)
Actually, what am I saying? Not just such trackers, not even just software, but human endeavour in general tends to scope creep and the problems that arise from it.
And yeah, the title was written in a way to be a bit provocative, but also pointing at that many (maybe most) teams use issue trackers for their product development flow.
I might perhaps title it “bug trackers aren’t good for tracking work” or “bug trackers aren’t good for product development workflows”. I like literal and direct (and often verbose!) in my titles.
The former is using it as a tool, while the latter is using as a way to control.
The point we're trying to make is that a tool can help nudge you in a certain direction, and we're trying to make Kitemaker the tool that nudges you towards working in a way that gets the whole team focused on outcomes instead of focusing on small tasks.
If teams are able to achieve that in their current tool of choice, that's ok too. We just believe working in this way is healthy and productive and hope to see more teams thinking along these lines.
Using issue trackers to track bugs is great.
This is where everybody would expect a screenshot, or at least a detailed comparison with the competition. Since you mention "Epics", you clearly have a certain competitor in mind: you don't need to be vague.
But I honestly don't see the fundamental difference between this tool and, say, my Gitlab issue tracker. Not just from the home page but even going into the guide. You have work items, Gitlab has issues (funnily enough, I was just reading before that Gitlab is migrating under the hood to "work items" to integrate issues/epics/incidents into a single entity), both can break down a single item into multiple ones, have a collaborative document at the top, an activity feed, roadmaps, labels... I don't what's the feature that would make me migrate development workflow to yet another tool (with more costs possibly, because 100 work items doesn't look like much if you deal with multiple projects).
Easy one first - pricing. It's always a challenge but we try to find something that's reasonable when compared to the competition. We're not big fans of tools that do limited time feature stuff (this feature only works for the first two weeks unless you pay) so this is what we're trying for now. We're very flexible with teams as well. If they don't feel like they've gotten a fair chance to try it out, we raise the limit and let them keep trying for free. We'll gladly take your money once you're satisfied.
With regards to GitLab or any other traditional issue tracking tool - if you're able to get this sort of a workflow where your team is really focused on the outcomes and not mechanically processing tickets, then that's great! We're not building the only tool in which this is possible, just building a tool that we feel does a great job of nudging people in the right direction.
When you start something new, it's not a big deal. Everybody loves to work on something new. Nobody loves working on legacy products, because they don't have enough documentation and full of bugs, driving up costs of support and becoming a pain in the ass of some CIO. Yet somehow all those fancy new tools focus on creating great experience for building something new. Plenty of decent software was written in the last 50 years, but we are burning the money, electricity and silicon to replace it, because we could not come up with methods and tools for building on top. Why it is always about integrating something like requirements and context into planning? Why not doing it the other way, integrating planning into requirements and context, being product-centric rather than work-centric?
One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker.
Thank being said, your comment has my gears turning on how we could do an even better job of it.
Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.
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.
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.
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.
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.
Most obvious example ? Stale-closer bots.
I mean, sure it makes you look good because you have a low number of open issues.
But its basically 21st century sweeping under the carpet.
Maybe there's a bit way to surface these old things and remind teams to deal with their skeletons.
But these headlines pop up everywhere and, at best, present an opinion, usually of one person who neither surveyed a large group nor has the authority to make such claims personally.
I might write an article "Articles \"X considered harmful\" considered harmful".
People were annoyed by those and wrote such an essay at least 20 years ago [1,2] (possibly there were others). Didn't help much, but generally fighting idioms/memes/fashion doesn't seem quite productive: perhaps it's more useful to focus on not being frustrated by those (and accept the way this phrase is used).
Edit: Though ranting about titles on HN is still a fine activity, not trying to discourage that. Just an idle musing on being more content with those.
[1] https://en.wikipedia.org/wiki/Considered_harmful#Snowclones
[2] https://meyerweb.com/eric/comment/chech.html
Ah, so they're impartial, and this isn't clickbait at all.
Most of the points raised in the article are opinions based on a limited understanding or use of issue trackers. For example:
You raise a point only to dismiss it and then defend it again. Yeah, because the assignee is the person working on it, managing it, owning it, etc. What good is it to list 5 people's names on an issue? If it's just to track it, you can already do that without assignment. If it's just to record "these 5 people are working on it", you can do that with a comment or in a description. If it's for change management, that's what a change management system is for, or you can use the issue tracker in lieu of one by adding subtasks per stakeholder. What issue trackers have you been using? Jira gives you tons of space. Maybe because those are all very different things? Collaboration involves chat, video conferencing, document sharing/group editing, email, using various enterprise systems, etc. Reaching decisions it actually can help with, but whatever. Shipping to customers involves delivery management software, customer support specialists, customer-centric portals, etc. Trying to build one thing that does all of that is insane. Even Microsoft wouldn't bloat up a single product like that. Because an issue tracker is for tracking issues... not... oh nevermind. Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.That's exactly the point we are trying make. Issue trackers are good at tracking issues, but now people use issue trackers to track everything, from product development to task tracking, which they're often sub-optimal for.
> Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.
That's the bit I think we disagree on. My co-founder and I have both managed very large teams at large organizations. If you start splitting up everything into different tools, suddenly product is entirely disconnected from development and vice versa. We've seen it over and over where a tool becomes a "PM's domain" and is totally disconnected from the reality of the developers' work.
Now obviously you can make it work with discipline, but you can make anything work with discipline. We think Kitemaker makes it easier for product/development/design by creating one place for them all to meet. I agree that there are different types of hammers, we do not try to replace git/figma/slack but rather integrate with them.
I think we mostly agree at a high level, we just disagree where the split should be between different tools and you don't like the click-baity style of the article (that's fair and we'll try to work on it next time)
My solution was to manually maintain a bulleted list of links directly to the relevant issues.