We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker.
I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems.
New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!
But I don't think it really solves the problem. For most organizations, tracking tickets is a solved (by many products) problem. Starting with a new tool has the appearance of making things better, but leads to the same place. The problem is not the tool, it's the structure of the organization.
Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs:
As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP limits, even for backlog.
But, since backlog is now the primary output of "product orgs" at many (less-than-great) companies, you now have an entire org whose jobs depend on not learning that lesson.
I don't know what the answer is, but I really am starting to hate this entire "product org" concept in general. It feels like we used to be able to just engineer our way around many of these challenges ("here, look what I built last week to justify my case"), or just get people into a room and talking. But once the decision channels become explicitly siloed off into a separate org with C-Suite-level autonomy, I'm not sure how you effectively bridge the gaps that form.
Any engineers who feel like having a separate product org has been a benefit to your company's product quality and delivery speed want to comment on how you see this sort of thing working effectively?
Depending on your company culture, this may be difficult to do, but I've seen good luck with moving toward a model where the product team doesn't push things into developers' to-do lists. The product folks supply a strictly prioritized wish list, and developers pull from it. Always one thing at a time, always the very first thing on the list.
It's the only way I've seen to get the product people to shift their thinking from, "What's a giant list of all the things we wish we could build?" to, "What is thing we actually need to build next?" And, without that change in thinking, the natural impulse is going to be to try and pack more features into the product using a close analogue to the technique that farmers use to produce foie gras.
You may have to be willing to sit back and let them drop the ball and get burned for it a few times. If they're pure business folks with little customer support experience, they might never personally understand how fixing a bug can be more valuable to the business than building a new feature, if you don't give them a chance to talk to a user who's irate about some piece of deferred maintenance.
How do you deal with the possible disconnect between product and engineering in terms of feasibility? If #1 on the list is something that will about absorb all of engineering for years, but #2-5 can be developed in weeks each?
What kind of scope level do you think works when talking about that list? Like project level instead of tasks, and then engineering figures out how to deliver the prioritized project? Otherwise it kinda just sounds like a backlog to me, just curious how you see the difference there.
Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.
It's going to invariably depend on how your company is organized, and its culture.
If you're at all able to start with something approaching the business-facing parts of Scrum, I think that's a great place to start. In Scrum, there are ideally two completely separate queues: The product backlog belongs to the business folks, and is organized in a way that works for them, and the dev team's list of tasks belongs to dev, and probably shouldn't look similar at all. And the only way for things to move from one queue to the other is during a regular meeting where the dev team says, "OK, it looks like we've got room to take on X additional work, what can you give us?"
And then, and I think this is secretly one of the most important things, the dev team physically creates new tickets for the new work they're taking on. You should never be able to just drag-and-drop tickets from one queue to the other. Ideally, it shouldn't even be physically possible to do so. Where I am right now, one is in $JIRA_COMPETITOR, and the other is an Excel spreadsheet. (If we all worked out of the same office, I'd probably go for an Excel spreadsheet and yellow sticky notes on a wall. Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.)
This little ceremony, and the associated firewall between two related but separate business functions, is, I think the heart and soul of what Scrum should be. It's the thing that sets up all the little firewalls and incentives that encourage business and dev to maintain a relationship that's more functional than dysfunctional. Everything else - sprints, story points, standup meetings, all that jazz - is just window dressing that some teams may or may not find makes that ceremony go more smoothly.
And if you can get a formal handoff like that in place, and get people to respect it, my (admittedly hopelessly idealistic) belief is that the rest of it gets easier to figure out. What's the correct scope and size of individual requests that the product people make of the dev team? Whatever size and scope best enables people to come out of the meeting feeling good about how it went.
But if everything's being jammed into one gimongous ticketing system, like all the ticketing system vendors seem to want you to do, you're doomed.
I prefer a single queue with simple rules of who can do what.
The approach I learned at Pivotal Labs was that product management decides the order of stories and bugs, since these add or subtract user value. Engineering can put chores anywhere in the backlog according to their considered discretion, since these reduce drag and risk. Each week you have the Iteration Planning Meeting to look at what's coming up. Each day engineering pulls whatever's on the top of the backlog and works on it until it's done.
If I am getting the drift right here, the root of the problem is that the Product Org is not prioritising well, and putting an upper limit on the total story points pushed in a release ?
That would lead to a large number of stories being classified as "Priority" and left to engineering to figure out how to deliver.
Separate Product Orgs, like or hate it, are not going away anytime soon. If anything, I believe they will become more ubiquitous.
Probably what we need is not more and better ticketing system, but better prioritisation systems, with well defined upper limits on how many story points can be released at once.
Thanks, this is a neat idea to think about. You helped me start anchoring some untethered thoughts I've had floating around about this stuff recently.
>like all the ticketing system vendors seem to want you to do
It's so annoying how misaligned the incentives are between these vendors and the users. Standard fare for B2B products focusing on the people signing the checks though...
> Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.
Wow! You should buy a .io domain name throw up a landing page and start selling this as a feature! (On a subscription model, naturally.) Seriously though I love this point.
> As we move more and more towards ubiquitous "Product Orgs," separate from engineering
I've only seen this separation recently and I am not a fan. It just seems like a terrible wasteful way to consume time, money and goodwill. I've never seen anything more effective than small balanced teams.
yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points).
in every company i've been at that is larger than a handful of people that all know each other, a separate product org is a requirement if you want a product with broad appeal.
i'm not sure what your complaint about the product backlog is. product people should be generating a large backlog. that is literally their job, is it not? it's only through a large backlog that you can say, hey we need more engineers. or hey, our vision doesn't match our capabilities -- refine it. and so on.
How exactly does a large backlog have a negative effect on velocity?
>engineers almost always make poor product decisions
You seem to be misinterpreting my thoughts as being against the idea of a product manager role. That's not what I mean. I'm talking about product as a separate autonomous org with a CPO, versus embedded PMs reporting to EMs alongside the rest of the product development team. I have similar, though less strong, feelings about Design as a separate org as well, for many of the same reasons (communication overhead/bottlenecks).
With regard to backlog, there is actually some capacity planning math that can show that (unintuitively) backlog size negatively affects product delivery velocity. I'm not an expert there, I've just watched some internal tech talks about it in the past.
At a higher level, think about what happens when the business side requests a new feature, or a product change. What is the difference in terms of confidence of estimates that can be given if you have 20 tasks in the backlog, versus 200. Sure, for that one thing you can up the priority and jam it in above a bunch of other stuff. But then, once that starts happening to people where you prioritize a newer request above theirs, how does that affect their confidence in your planning ability on a longer timeline?
> in my (vast) experience
Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.
>Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.
literally made me lol, thanks for that. i mean it in a good way, not a defensive sarcastic way. that particular phrase is funny. can't recall the movie that made it popular but it forces a smile.
i'm not trying to gain your trust. like 95% of posters, i just like the sound of my own voice. i could not care less what you do with the info ... and i shouldn't care. it's opinionated. if you agree with it, you already agreed with it. it's not like i'm trying to convince you that JWT is bad. i have no agenda.
i was just using the adjective to note that this is what i've seen over a long time in this industry. AFAICT most of HN is 25-somethings with hardly a clue so i felt it useful to note that my opinion doesn't come from the 2 jobs i've held since graduating. that's all. i wasn't trying to speak from a position of authority, so as to command respect.
i understand though why you reacted as such, as in retrospect it sure looks like the typical kind of comment, i'll admit that.
as to the rest of your reply, yup i misunderstood your argument.
as to priority churn, that's not a problem of the backlog per se, that's a function of poor management, or the simple state of being of an early startup. whether you have an actual backlog or not, the whiplash priorities are the problem and the backlog merely the embodiment. by removing the backlog, you haven't addressed the problem.
Great point! Compartmentalisation is one thing but in large orgs, everyone starts focusing on one metric they need to boost (backlogs or PRs or design mocks) and we have no idea how this will affect other teams. We just have good metrics to show.
Having an entire separate org whose sole job is to create backlog items inevitably ends up with 100s of items, 15-30% of which are "high" priority. Many of these will have out of date specs by the time engineering can pull them in.
I would much rather have product folks embedded in the engineering team. That way they can be working on making sure any issues on deck to be worked on next have up to date, clear requirements, and issues are prioritized correctly.
Having product people separated into their own organization almost always leads to a "throw it over the wall" situation.
You're not wrong about incentives, but an org where PMs have fully segregated duties from devs is exactly the organizational context that breeds disconnected engineers juicing their burndown chart. I mean what do you think is the predictable outcome from a PM whose main job is googling his competitors and stuffing high fantasy JIRA tickets in the engineering backlog based on his mystic customer divinations. Neither of these people has made contact with a customer in their lifetime.
however that's not a [dys]function of simply having a product org, that's a problem with poorly qualified, poorly performing employee. or a poorly describe job function. usually with the boss/management similarly poorly equipped since they don't see past the metrics they themselves (usually) have established for "success".
i think like the GP, you are conflating poor execution of the concept/model with the deficiencies of the model itself. one does perhaps encourage the other, however it doesn't need to be that way and isn't inherent.
i mean, in 3 words, "haters gonna hate". meaning that people that are poor at execution are going to be poor at it no matter the model in which they are embedded. but when you do have a good product team, the product org (as a model) gives them the ability to maximize a less than ideal engineering team. of course, still there's many a slip twixt cup and lip.
What I wish is that companies had people specialized in handling issue tracking systems. Expecting developers to do this is absurdo, a lot of the work is just making sure that the ticket is not a duplicate, and similar issues.
On some level, I kind of wish the entire cottage industry of "issue tracking systems" would just go away. What's wrong with a simple Kanban board? What has ever been wrong with that? It seems to me like, in a lot of cases, engineers just lost their nerve in terms of confidently talking to sales people and the business side of the company, and couldn't deal with the (imo, healthy) tension any more. I understand that people want estimates and timelines and stuff like that, and those are totally reasonable. But flagellating ourselves over absurdly small timelines, and hand-wringing over tiny pieces of features of projects as the core driver for engineering productivity, just seems crazy to me. It seems a lot more like purely signalling to the business side some vague ideas about "commitment," or "hustle," or whatever without having to speak to "those obnoxious sales people."
By product org do you mean a silo of an organisation dedicated to one particular product (so if a company has five "apps" they have five siloes and five marketing teams five engineering teams and five board members ?
I understand it to mean that there is a part of the org (separate from the engineering team) that shapes the direction of the product; decides "these are the features we're going to implement, these are the issues we're going to address"; one way of looking at it is that their primary output is putting things in to the engineering team's backlog.
Aha - so you are saying there is a product manager (plus "org") whose job it is to produce big backlogs separate from the people who will implement them.
I tend to agree but I have a anecdotal counterexample. We recently switched from JIRA to Clubhouse by importing our history and backlog wholesale. Due to the substantial performance bump we have definitively leveled up as a team.
Status updates that used to happen in slack channels are now captured in Clubhouse, people log in to check on progress, stories get love and details.
JIRA cloud was unusably slow and as a result we didn’t want to use the tool. We hated it even though it technically “worked”.
I was a JIRA admin for a number of years for an organization that had a heavy QA workflow. It was all about making sure that every issue had an "owner," at any given time, a strict approval and verification process was followed, and that as much up-front data as possible was collected during the initial report.
In my experience, unless the people entering the issues are paid, professional engineers, we'll never get the information we need up front.
I have found that the basic GitHub model works well for me.
When someone reports a bug, they are doing me a favor. It's in my interest to ensure there are as few roadblocks as possible to them sending a report. If they give contact info, then I can contact them with specific questions.
In my experience, a simple email form is the best way to solicit reports. It may have a workflow hidden behind it, but I have found that the simpler the workflow is, the more likely it is that the issue tracking will work.
JIRA basically starts off complicated, and it's possible to make it much, much worse.
It's also slow, but that wasn't really the problem we had. The workflows and forms were where it fell down for us.
As a current Jira admin, I constantly have to fight this. A non dev team came into Jira and implemented a huge octopus of a workflow (despite my strong advice against it) and were shocked to find out it didn't really help them work better.
The handful of teams inside that department that I've gotten to switch over to a simpler To Do / In Progress / Done style workflow have been much happier.
Jira has many, many faults, but most of them are what the users do to themselves.
Jira is laggy as fuck and makes every interaction I have with it take 5 times as long as it needs to, or at least it has been in the two organizations that I've worked for that used it.
We're in what I tend to think of as Jira's pit of despair: there's no explicit support for the on-prem instance; workflow configuration regularly seems to go wrong and has a wide blast radius when it does; nobody trusts the data so we don't get any useful reporting out of it; the UI is... not exactly slow, but I wouldn't call it snappy either; and there's no money for addons that would genuinely help us.
Github Projects would be absolutely fine for us, but we can't switch out because Jira is "what everyone uses" and "has more features", despite us not really using any of them.
A lot of issues can be mitigated when you self host vs using JIRA Cloud, not just because you might have beefier hw and better network link. While I suspect it got better, periodic reindexing and similar cron jobs were a hell on a team separated by 9 hour timezone difference, because time chosen for convenience in San Francisco meant many Mondays of "Atlassian Cloud is down" for team in Warsaw.
While we're all in the same timezone in our company, we're also programmers... so that doesn't always matter. I've been using our JIRA in the middle of the night on several times, and it's just... there.
edit: so yeah just highlights the self-hosting vs cloud...
Not sure what happened to you - but speaking anecdotally, but from someone who logs into Jira Cloud every day, and spends 20-30 minutes interacting with the interfaces over 8-10 hours a day, and has done so for the last 3 years - it's had a handful of outages, nothing that really rose to the level of being memorable though (and less than any internal issue tracker I've worked with) - and the performance is, fine? I mean, it's not <50ms twitch fast, so, I guess I'm losing a minute or do wall-clock time + whatever larger blocks of time that occur when I get distracted waiting for a ticket to come up - but it isn't at all what I would call "unusably slow".
In our case though, we only have about 50 engineers and a few hundred thousand issues. Jira has performance issues in the 500 engineer / 100mm+ issue space - or it used to, perhaps they've resolved those issues by now.
Ours JIRA instance took multiple seconds to load modals. Think 5+ seconds. It was miserable.
I would have gladly paid more for faster speed but it turned out the APIs were blazing fast and it was the JS that was slow. Not sure how we have had such different experiences. Seems impossible that your JS was executed that much faster than mine. I was using chrome FWIW.
I actually got $work to pay for a new desktop computer to prevent me from going insane because of the slugish JIRA and Google Cloud Web Console, and it actually solved it.
My old x260 was not able to run jira/gcp/slack at a reasonable speed due to javascript performance :(
The main problem with Windows 95 stability was garbage third party drivers, but we had no problem blaming Microsoft for that.
Really, why wouldn’t you blame the maker of the bed?
If you make a tool that encourages Rube Goldberg machines, then you made something far worse than a Rube Goldberg machine; you built a device to construct them.
> But can be usable if you are not super sensitive to small latency.
Our JIRA instance would lag while typing in the description box. You have to wait a second or two for it to catch up after typing a sentence. It was absolutely unusable.
5+ seconds sounds wild. Our active users number is a multiple of the 5k max users for jira cloud and the only actions i can think of that are >2s are bulk edits and complex jql
I haven't noticed JIRA cloud being that slow, but maybe that's because the team is small.
Did you start to experience performance issues as team size increased? Did you have a lot of issues or data held in the issues? Or was there another issue that you think led to the slowness?
I'm interested in your insights as we went with JIRA initially, since it was pretty much the gold standard and we thought it would scale nicely as we added team members, but if it is not going to do so, then it may not be worth the JIRA premium.
I don't want to put words in OP's mouth, but I suspect that OP was referring to just like... "you click and something and then wait" type of slow. Something like, taking several seconds to load an issue.
In my case, we were a small team (<10 users, <1k total issues split in maybe 8 projects), and were running into random load time slowness irritations. It never stopped us from doing what we needed to do, but it sure did make it more frustrating to do it. We are using a cloud instance.
It’s a documented phenomenon in UX that if an activity involves a quantity of small pauses in a short enough time span, that the user perceives them as a single, long pause.
If your app is fast but your workflows are terrible, people will call you slow because everything takes four interactions. If you have a bad workflow and a slow-ish app, people will talk about you on the Internet.
I do agree that lot of the process issues often reside in the organization itself.
In ideal world, you don't need any kind of tracking or process. Right things just happen. However, in reality is that companies often have goals and roadmaps they have to deliver. Things move fast and teams need to know what is being worked on. We've worked in 5 and 5000 person engineering organizations and need for coordination is always there. And personally, I just need to know what I need to do next.
We spent the past year talking with our our early users. New startups and even teams of very successful companies, struggle with the process. They might know how they should improve things, but it's hard to find the time or energy to actually implement it. We want to help with this.
So in addition to the tool, we are developing the understanding and practices software help the team to focus and reduces some of the bad habits we might have. The tool will then help teams implement and maintain these practices going forward. We ourselves also been working with this "Linear Method" which we shared here: http://linear.app/linear-method
Boo to this take. Not all tools are the same and “Good tools obviate bad processes.” is a mantra I saw once in a talk that has stuck with me for 15 years. You’re not wrong that it’s a people problem, but tools shape human behavior. That’s Design.
The quote is attributed to Michael B. Johnson, aka wave, Software Director at Pixar.
API design is a great example of this. Good API design incentivizes the right choices and clean integration. I often argue that it's not just "oh this API matches the spec better" or "this API is lower maintenance" but rather that I've found certain APIs can almost trick developers into writing good code. It's a neat experience.
That being said, there is some necessary internalization that a tool is solving a people problem which is maybe what OP is trying to get at. No matter how good an API is, if a developer is dead set on writing bad code, it'll be bad. So just deploying a new tool, no matter how clever, won't fix an organization that doesn't want to be fixed.
I haven't tried Linear, but my company uses Jira. It's abysmally slow. Not "there are too many tickets and it's hard to manage" slow, just the interface is slow. I opened an issue link in a new tab. It took about 7 seconds for the page to become interactive (able to click on the issue status and get a dropdown) and about 9 seconds for the loading to complete and elements to stop jumping around. This is in Firefox 78 on a Lenovo T480 with 8th-gen Core i7 CPU. Speed.cloudflare.com reports 28.5ms latency with 38.1ms jitter, 339Mbps down. Not a generally slow setup. At least in the case of Jira the interface speed is a huge issue.
Is there a site that lets you run performance profiles in browser developer tools and share the results? I could imagine that being really useful internally for devs troubleshooting and working with support.
It'd be harder to pull off as a way to shame poor performance because of the need to compare like with like, but I think it's needed to get the attention of folks.
Accessibility checkers are often rudimentary, but they are available to non-technical folks in companies and can be very effective at getting a conversation started.
The other problem cycle is “we’ll get JIRA right this time”. This is followed by happy clicky people immediately shafting it, at least two years of suffering and then some PM selling some new clothes to the emperor. Everything degrades this way. Even GitHub the moment someone adds workflow automation. Intent versus causality are two very different things.
My favourite problem is a JIRA instance that sets a resolution as incomplete immediately on a ticket, which is a valid resolution so all my tickets are closed as far as it’s concerned. Ugh.
I’m slowly working on an OSS replacement for all of this hell which is designed for inflexibility from an organisational perspective. It’ll be open source. I’m sure no one will use it because it’s inflexible.
"I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems."
Imagine what would happen if everyone in an organisation had to use the same tool for text and code editing, say for some reason the PhB inflicted Word on the organisation as the only allowed code editor. Would that be good?
From my pov, most of the churn with ticket trackers is down to current solutions trying to own everything and apply a one size fits all model to everyone in the enterprise. The upshot being that the ticket trackers are invariably a sh*tty compromise for many/most individuals in the organisation. Think about the number of slides and reports that are hand generated for progress meetings in an enterprises. What about all of the various todo apps and systems people use? Why would so much effort be expended if the enterprise ticket tracking system was meeting requirements?
Fixing the problem requires using systems based on common standards that allow _individuals_ to use what works best for them but still interoperates freely with each other. fwiw, another shiney issue tracker will not do that unless its basic unit of tracking is something akin to a text file that can be shared with the next shiney issue tracker.
It's not just speed, it's complexity. I've seen the cycle play out enough to know the real thing that drives how productive a ticketing system feels: How many distinct kinds of people are using it.
The new one always seems great, because whatever team pilots it is the only team using it, so they're able to keep it nice and lean and closely adapted to their own needs. But, as soon as the decision to migrate is made, then you don't just have additional teams using it. You have additional teams wanting to use it as a communication and monitoring channel, and building up reports and metrics and dashboards on top of it, and imposing restrictions on the ticketing system that ultimately limit other groups' ability to streamline their own workflows, and by the time everyone realizes they're back on the same old pain train yet again, it's too late to do anything about it.
It seems that developers are always the ones who get hit the hardest, because they end up with the largest number of outside parties who want to get involved in their business.
> Don't migrate your backlog, start with only a couple engineers in a new issue tracker...
I experienced this in the wiki/documentation space some years ago when my org migrated from the trac wiki to Confluence. It seemed like such a boost initially, but it wasn't a boost at all, it was just the fact that for the first ~12 months after migrating, you could trust that everything you found in the wiki was freshly written and up to date (and the overall corpus was small enough that the search function actually returned useful results).
The whole experience has given me the idea of making a Confluence plugin that slowly fades out each page to grey as a visual indication of its waning relevance. Anyone editing, commenting, or "liking" the page immediately freshens it again, unless they somehow indicate that the action is actually a vote against (like nofollow is for links). When a page is sufficiently abandoned, it goes on a candidate-for-deletion list, gets a warning box at the top, and is blacklisted from appearing in the default search results.
If it’s late afternoon and I’ve finished or am about to start a particularly challenging task, I’ll tend to take on other tasks like basic research or wiki maintenance.
Essentially I treat the wiki like a B-Tree. When the landing page gets crowded, I move a bunch of related things down one level in the hierarchy, trying to retain keystone ideas within the first to levels (and letting related concepts be discoverable from those).
Over time the oldest links and links of only temporary utility get pushed out to the leaf nodes, where you aren’t likely to encounter them accidentally.
Really, though, we should be applying the same sort of version control we have in our source code. You should be able to track down how old a paragraph is in the wiki.
https://www.getguru.com/ has a so verification where each page, called cards, has an owner or group of owners and a set expiration period (1 week, 3 months, 1 year etc.). Past the expiration the page gets marked as untrusted (it's on top of each card) and require to be reviewed by the owner(s). Any user can also mark a card as untrusted, prompting a review. Every expired card owned by owner get displayed to their owners in a dedicated UI (page) and can be quickly reviewed. The editor in Guru is a bit clunky at time (worst than Confluence... if that's possible) and not really suitable for something like specs, but I have yet to find anything that actually tries to prevent wiki rot.
> New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!
Sluggish software can be more than just a data bloat issue. It can also be caused feature bloat, or software architecture that scales poorly.
Anecdotally, I recently worked on a project using a fresh Jira Cloud account. It was still slow.
We do a lot of work at Clubhouse to keep things fast.
We have alerts set up that fire if the p50 or p95 of certain actions spike and we treat it as a bug if things are headed in the wrong direction.
We still see a lot of random cases of things being slower though (shakes fist at random browser plugin upgrades).
It's a hard problems, but if you don't design (and monitor) for this from the beginning things are going to slow down over time as you scale to hundreds of thousands of users.
Jira is so slow I installed plugins in both the devtools I use a lot to view tickets without having to use the web interface, it's just painful when you have to view a lot of tickets quickly.
It's the same with communications tools. "Our email is an INBOX-trillion mess because we use unstructured email rather than structured tickets to manage our processes. Slack is the answer!". Six months later, they have the exact same problem with Slack because the communications patterns haven't changed.
That said, some tools are really just abysmal, and richly deserve the hate directed at them.
> New issue trackers feel faster for the same reason switching browsers tends to feel faster
It's not necessary about faster process, but Jira is agonizingly slow: each click triggers a cascade of HTTP requests in a synchronous way and it literally takes seconds every time you want to do something. Everytime I have to touch it, I feel angry for the next hour just because of the induced frustration. Any tool more responsive would be an improvement for me.
I'm genuinely interested: is this really true? Is Jira necessarily slow when there's a lot of stuff in it? I'm not sure I believe it. There are graph-of-objects-plus-metadata applications out there that are pretty fast. I'm not an expert in this domain, but I bet an issue tracker can be made that doesn't feel painful at real scales.
I didn't interpret the OP to mean slow from an "application performance" perspective - instead, as slow from a "process" perspective.
The ticket needs to be filed in the right queue. It needs the "right" tags. It needs to traverse the "approved" workflow correctly. It didn't get assigned to the right epic. etc, etc, etc.
It's all of that - the process built up over time, in response to organic needs - that makes things "slow" and drives such a rejection of these tools by developers and their teams. We (collectively) rarely step back and say "what process can we cut?" - only when we use a new tool do we have the chance to address that.
It's both. JIRA can often be terribly slow. Each page loads about 10 seconds for me, and I don't know why. Other people say it is ~2s for them. I suspect it has something to do with networking and amount of requests being made, etc.
Then, on top of it the flows in Jira can be super slow, which is another story.
What's your question here? The premise of the OP is that they created a fast issue tracker.
People complain about Jira being slow (me being one of them.) No one has claimed that all issue trackers are slow. ClickUp, Hive, Linear, are all snappy.
The comment I replied to said that trackers are slow because they are full of stuff, and when you try a new tracker it feels fast because of lack of stuff.
I think you might be misinterpreting him. When I read that, "full of stuff" meant old tickets, process that you had to go to, etc. Slow =/= app performance but general cruft.
I don't think he literally meant that the app's performance was slowed down by the volume of tickets. I don't think Jira's performance gets much worse even with 10,000s of tickets in it.
The baseline performance of the web app is just baseline bad though.
"New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!"
I think the issue with issue trackers is that every organization has it's own way of tracking issues. So issue trackers often try to do everything for everyone, and end up being at most mediocre for most users.
Is Superhuman any good for that matter? I refuse to have to talk to a sales person on the phone in order to use a mail app. Which is what their signup flow required last time I tried.
Founder here. Here to answer any questions you might have.
We built Linear as we’re frustrated the practices and the available tools when it came to managing software projects.
On the product, we especially tackled the performance problem. Everything is synced to the client and we sync just delta packages between the cloud and client as changes happen. This way all actions a happen instantly and navigating around the app is really fast. And the app works offline too.
We also streamlined the UI and UX, overall we are rethinking what comes after agile for software development. I think many teams looking for something simple to run their teams.
One of the common workflows for us with Jira is to search for things that have changed in the last day
status changed during (-1d, now())
That lets me as a manager or a lead, see activity in their project and know when engineers update their tickets with details or comments. Is there a way to do that with Linear?
For all the hate that Jira (deservedly) gets, its search is extremely powerful. Maybe it's best feature. I'm not sure how well Linear would scale for a larger org of hundreds of engineers, dozens of teams, and tens of thousands of tickets without similar search abilities. Any roadmap plans for that?
We want Linear to scale large orgs with hundreds of engineers. We think most of the time you still work in ~10 person teams so we think lot of the experience stays the same but there are just more teams, more layers, and you need powerful search like this.
We do have plans to enable creating custom views so you could build views like this that present the information in a specific way. We do have GraphQL api it's even possible to build external view like this today: https://github.com/linearapp/linear/blob/master/docs/API.md
We have been using Linear at work, but at times loading a page can be dirt slow at 30+ seconds or more in Firefox. Once he page loads interactions are fairly quick, but the page loads times for me make it hard to load an issue to look at the comments so I use them less frequently now.
We've been using Linear for an 8-person engineering team for the last few months, and I just want to say thank you -- we've really loved it. The well-designed app with hotkeys makes managing tickets and cycles so fast that it doesn't interrupt your concentration to update a ticket and continue working. It's really brought the fun back to engineering management.
I went looking for a version of the site with some issues in it I can just play around with. Perhaps that's something you could link to from the homepage.
Looking forward to trying out Linear. I'd really love to use a tool with good performance and offline support! Your website looks slick and lovely too.
Alas, the e-mail sign up seems to take a while to send the registration link e-mail. When I got the e-mail after maybe 5-10 minutes of waiting, the sign up link had already expired. :( It says "Verification code expired. Please request a new one." I did, but the same thing happened.
We had some issues (and wondering if Gmail is having issues) with emails today. We rolled a fix that increased token expiration and currently looking our email provider if there are things we can do to speed it up.
I think it's Gmail having issues since our login emails sent to Gmail and GSuite arrived late as well. It's been like 7-10min delay, even though our mail delivery system said that the email was delivered.
The download page says only macOS is currently supported. Electron supports Windows and Linux quite well - any ETA on when you will be adding these platforms?
Hello. Looks good on the screenshots, I'd love to try it for my team but the signup link somehow sends me to Google instead of signup. /s How do I try it?
On a side note, I use Edge on a Mac and the signup page doesn't detect my browser as compatible; it's just Chromium inside, must be totally compatible with everything.
This shouldn't be the case. Would you mind sharing screenshots of the link you're pressing, preferably with video to hello@ our domain? We'll investigate. In the meantime, you can signup/login here: https://linear.app/login
On browser detection, we need to look at Edge. I don't think we updated the list in a while (we support all evergreen browsers).
Using any ticket/bug/issue tracker is better than not using one.
That said, much of the information you put in one of these is really sensitive, perhaps even confidential and quite often embarrassing if leaked.
So. Privacy policy? Extremely generic, and doesn't guarantee you anything.
Terms of Service?
"We take no responsibility and assume no liability for Content you or any third party posts on or through Service. However, by posting Content using Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through Service. You agree that this license includes the right for us to make your Content available to other users of Service, who may also use your Content subject to these Terms."
I don't know about you, but I don't really want the discussion of security-critical bugs in my product to be publicly reproduced and made available to other customers.
Thanks, we'll be updating our ToS soon and addressing this feedback. We take user privacy and security extremely seriously (many of us worked at Coinbase) and would never expose anything without your consent. I think this clause was for potentially opting into public sharing but it's not something we do.
But that's not what it says, so it's not appropriate.
"We keep the data that you store with us confidential. Our staff will not look at it unless you specifically ask us to investigate a specific issue. Other than legal requirements (e.g. a valid subpoena) we won't share it with anyone unless you've identified them to us as part of your team or otherwise authorized to see your data."
I was ruined for bug trackers by RT (https://bestpractical.com ). Driving issue tracking from email is brilliant - I only had to look at the application for reference or planning, all the normal back and forth happens from email. (Optionally - you can of course type in a web browser if you prefer.)
Jira's email behavior is pointless to the point of being counterproductive, and I disabled it. I have to look at it constantly anyway, why would I want it peeing in my inbox, too?
Of course, those who hate email are would react to it differently.
RT + zero inbox is my best experience with collaboration tools.
But for many many years now I am forced to look at jira, mail, teams/slack, and stash/gitlab to understand what people are doing and what's going on with that serious issue that's being passed around and lost in communication :(
I haven’t tried Linear, but while browsing the site I couldn’t help but notice what an exquisite job the designer did with the Linear site.
It’s consistent, lightweight, it has pleasant proportions, a nice color theme, etc. It’s also sprinkled with all kinds of little details that show care, attention and craftsmanship.
They should open up their own issue tracker for public viewing, so that (1) you see how many issues they have, and (2) you get a feel for what the end-user sees when they use the tool.
I have a rough time understanding why I'd pick this over the issue tracker integrated with my source control. I get that it can sync with GitHub or GitLab (Does it sync the issue text/comments such that GitHub users can comment on the issues? Are the issues on both sides using the same numbering? In this case, is Linear just a GitHub issues client?) but I imagine I am losing out on any given feature that my source control adds for issue integration, at least until Linear also does it.
Basically, I feel like you need to sell me a lot more on why I should use Linear over GitHub Issues, and how the benefits outweigh the added complexity of going two places.
You don't want your issue tracker in your source control if your product includes multiple source repositories, and a single bug might span several, or need to move between them.
Also, if you have customers who file bugs, they don't care about your code structure. And maybe they shouldn't have read access to your code?
Last I checked, GitHub lets you create projects that span multiple repos. But it’s still a good point that you shouldn’t be mangling your source control system to be a customer-facing support portal.
Jira is a hot circle of garbage. I am going to check out Linear for my team because I can’t stand how slowly Jira pages load and how long it takes Atlassian to address documented bugs.
Anyone who makes general complaints about Jira like this a) works in a place where Jira has not been correctly configured or b) works in a place with a terrible internet connection c) works in a place where both a) & b) are true or d) doesn't have any idea what they are talking about. P.S. what exactly is "a hot circle of garbage" other than a mixed metaphor?
> works in a place with a terrible internet connection
That excuse just doesn't hold up when any comparable issue tracker (or web app in general) works fine on the same internet connection.
JIRA, just like any other Atlassian product has a slowness to it on every click and navigation that makes it feel like you are wading through molasses.
We use Jira cloud, so if it is misconfigured, blame them. My internet isn’t great, but I will anecdotally note that Atlassian sites are the only ones that ruin a videocon connection. As for your general criticism comment, glass houses.
- they’ve had a ticket to hide completed epics from the roadmap open for over a year.
- their user management is a unmitigated disaster. God help you if you use bitbucket or Trello (although Trello users are getting integrated in after 4 years!).
- it took me literally 2 months of help desk tickets to figure out how to get an invoice. The former billing poc was fired, and even though I was the site admin, I had to recreate his account in our SSO, log in as him, and then assign the role to me.
- have you tried to set up even a slightly customized Jira Service Desk?
- want to expire “done” issues faster than 14 days? Pound sand.
- I could keep going, but what’s the point? Atlassian is a bunch of decent products drowning in scope creep, terrible cross-product integration, and a painfully slow development cycle that is focused way more on cosmetic features that fixes their trainwreck of a dumpster fire.
There are myriad ways to misconfigure a cloud instance of Jira. You thought I was referring to the configuration of the actual web app I suppose. That's kind of a silly assumption but gives me a lot of insight into what you've said here...
A quote from a funny TV show still doesn't really make it a thing, does it?
If it's not, there probably is a way to do what you are trying to do that you just don't know about.
I work at a very large organization. The user lookups in Jira are lightning fast & the permissions are granular for a reason.
Can't help you with your billing problems but it kind of sounds like a "you" problem.
I have fully configured a Service Desk instance, yes.
It sounds like maybe you aren't actually using the release feature & or that maybe you don't know how to write JQL queries or maybe I don't know anything about the amazingly advanced way you are trying to use the features. "Hey doc, my arm hurts when I do this?" The doctor says "Then don't do it."
I could keep going too but it would be a waste of my time to try & have a reasonable discussion on something which you have prononuced your verdict: "Atlassian is a bunch of decent products drowning in scope creep, terrible cross-product integration, and a painfully slow development cycle that is focused way more on cosmetic features that fixes their trainwreck of a dumpster fire."
I‘m working for 2 companies atm where one uses Jira and one uses Linear.
Doing anything in Jira / confluence is really slow. It’s a nightmare to navigate and it seems like every time I click on anything, it takes 2-3 seconds to load.
It’s really hard to explain but I guarantee you that if you tried linear out, you’d “get it”.
This isn't quite true, as others have mentioned throughout the thread, JIRA Cloud is noticably slow to use, to the point where doing non-trivial stuff is frustrating - page loads take several seconds, and most operations require a page load. I'd expect their hosted version to offer the best performance, but apparently it doesn't. It's not unusable or anything but it's definitely a very sluggish feeling experience compared to a lot of the SaaS we are used to.
Which would be a fairly rubbish take, because when it's my workflow, it's MY WORKFLOW. What they might mean is "I have not set up my workflow according to Jira's needs" which is entirely Jira's problem to solve.
We took a bet on Linear fairly early on (moved over last August!) and have been consistently impressed. I've used many different tools in the past (Pivotal Tracker, Jira, Trello, Asana, Github...) and Linear has by far the most polished, productive interface of the bunch.
We have fairly strong opinions about our workflow (using points, planning sprints, etc) and have found that even in the cases where Linear isn't as opinionated as we are, or doesn't have granular tools/configuration to manage things, we can get most of the benefits we need by using tags and other features appropriately. I was a die-hard Pivotal Tracker user before this, and it's very hard to imagine going back now.
Super impressive product and team, highly recommended!
And you use RequestTracker for software development?
A simple glance at their website clearly shows to me that it's a tool to manage customer-facing ticketing mainly (allowing integration via email addresses). Linear's purpose is for managing software projects and features/issues within those projects.
I'm by no means a Linear advocate, I couldn't care less what people use to manage their software projects. But tools tend to have specific purposes and RT seems quite different from Linear with respect to their distinct purposes.
One of the founders of this thing was my first EM at Uber. He was (and is) a very strong engineer, and a great overall guy. Huge kudos, and I wish him the best success. If you wanna put your money in a company started by decidedly not-scumbags, this is the place.
But cool as it looks, I'm personally reluctant about replacing my locally hosted open source developer tools by pay-per-month SaaS solutions which are closed-source and handle possibly sensitive data of me and my customers.
Spolsky sold FogBugz a couple years ago. The tool was fine enough for small teams, but it was a mess for larger teams (tons of cases, no good way to organize).
I want issue tracking where everything thing is saved to a hit repository.
I’ve started using a crude version of this where each open issue is a directory, there is README.md for each issue and supporting files go in the same directory and get relatively linked to in the readme. When an issue is closed you delete the directory. When you need to reopen an issue you revert the commit that deleted the directory.
It’s all manual and no UI and works for my personal stuff but it strikes me as odd that there is no widely used issue tracking with a nice UI that tracks all the data in git and git-large-file-store
Honestly, I don't really see the value over any other tools (Jira, Trello, Asana, Monday, etc).
Sure they have a command palette and the UI is pretty fast (like Trello) which is nice but you still need too many clicks/keyboard shortcuts for simple tasks like adding 2+ issues.
Their Slack integration is also non existent. You can't create issues based on a conversation for example.
So overall, I will keep using it but will probably not evangelized it or bring it with me to another company.
What's the purpose of a restricted "free" plan with a max of 250 issues? There are enough actually free options out there that the free plan doesn't bring anything to the table. Why wouldn't you do a free trial of an unrestricted plan instead? The obvious thing that stands out is that you'd have no way to test their support before paying.
We wanted to make the product free for smaller teams to get started without worrying about who to invite. We only count active issue to the limit, and once you're done with them, you can archive them. And yes, we do have support for all users and priority support (faster response times) for paying users. We want to build a long lasting sustainable business and charging for the product is big part of it.
Just some feedback, but I would consider doing a free tier for open source projects which would get your the coverage and in turn the adoption you need. You need to win developers over who in turn influence tool procurements.
Just to be clear, I wasn't suggesting you should have a better free plan, I was wondering why you have one at all. Free users are expensive and a hassle and I'm skeptical that you'll acquire a lot of paying customers that way. I can't claim to have any idea about the inner workings of this market, though I've spent a lot of time looking at the options in this space. There are plenty of free options for those without the cash to pay $8/user/month. Your free plan isn't particularly compelling.
I imagine the free plan also doubles as a trial for a paid subscription. Moving issue trackers can be a hassle, so having unlimited time to test out the workflow and features for a small team or project makes good sense, and if you decide to switch it should be easy enough to upgrade.
It’s good to see the command palette pattern gain adoption. I’ve introduced a few people now to command-space in macOS and they’ve all loved it. Why hunt for an icon when you can just type “TextEdit”?
Maybe a future macOS will allow apps to hook into the spotlight search bar and present their command palettes there, in a standard way?
This may be a minority opinion, but I'm disappointed that so many core workflow apps like ticketing still living in the browser. Any serious programmer would scoff at the idea at their main IDE being within a browser, so why is it acceptable for a ticketing system, which is nearly as core to our workflows?
> Any serious programmer would scoff at the idea at their main IDE being within a browser
Are you talking about just the browser chrome or the actual implementation? Because maybe it means that I'm not a serious programmer, but I love VS Code.
The filesystem access issues make IDEs a bit different than issue trackers IMO, I don't have a problem with an issue tracker living in a browser, or being browser + Electron options.
We recommend people to install the desktop app so it's easy to keep open. However, people still like the ability to easily link to issues, even if they don't have the app installed, hence the web browser support.
Many issue trackers have APIs that let you use them from within IDEs, and often in quite powerful ways. JetBrains does this nicely with trackers like JIRA and the native one in GitHub.
Yes, we're a small team and as we're building Linear for both the web and desktop, it was the obvious choice at least at this stage. It's essentially the same app and experience on both but desktop provides better notifications and faster "in and out" of the app experience - it's important for us that Linear is there when you need it and doesn't get on the way.
I'm interested in a native (MacOS optimized) issue tracker client and then a dictation software that is adept at understanding software terms. I've watched my doctor friend dictate to his laptop without a microphone and it took down notes perfectly.
Not the intended purpose but I've been using Linear for a personal project of mine (stocks-related iOS app to learn iOS dev) and it's been so much fun to use compare to the JIRA I use at work all day.
It would be neat to have Github, Gitlab, etc. mirrored because I've always seen issue software that doesn't directly integrate with repositories to be more work to manage than not.
I make heavy use of the `fixes #` feature on Github to auto-close issues. This adds up over one or two years when you're closing multiple issues per week.
I’m working on TaskSift which, although it’s not a pure issue tracker, does use a mix of sources like email, github, etc as its source of truth when it comes to issue status.
We struggled quite a bit with getting this status thing right, finally settling for model where user stories inside TaskSift are based on multiple inbound tickets (each with a different status), and where each story can be published eg to GitHub, QA queue, an l10n tool, etc again each with its own status and completion time.
Once all published tasks are finished the folks who contributed to the inbound tickets can all be notified, and the tickets can be closed, either from within TS or using the tool in which the ticket was created originally (Zendesk etc).
> You'd be completely hamstrung by the available GitHub API's and speed.
Out of all the APIs I've built similar projects on, GitHub has been among the ones that's the easiest to mirror/cache to your own DB, so I wouldn't say that's really a problem in practice.
I've been playing around with this casually for a few weeks and am quite impressed. It's a definite improvement over Jira in simplicity and performance, but is missing quite a few features still. But still, it's my preference. I have started to appreciate light, fast, minimalist interfaces much more over time.
I am usually keen to try new tools. However, with the limit of 250 active issues and hassles to archive old ones, not many open source projects will be able to use it. On the other hand, I can't recommend it in my BU/company unless I have evaluated it for full extent.
Consider, providing a free-tier for open source projects.
We started using Linear a couple weeks ago and overall we're very happy.
There is no doubt that @tyre's points about a "reset" being part of the reason folks like new issue trackers.
But setting aside the "reset" we got (our backlog from other tools wasn't _that_ big), we really enjoyed the speed and accessibility (ex: desktop app, keyboard shortcuts, etc).
I recommend folks give it a try.
My only feedback to the Linear team is: I get notifications for the desktop app to upgrade too often. I love rapid iteration, but it feels like it's daily.
Because I get it so often, it's caused me to start to not pay attention to the "red dot", which my brain has convinced itself is "update ready" and not "unread items in inbox", which it really is.
Hopefully you can find a happy balance or some other UX tricks to help me out here. Thanks!
Thanks! It's a balance we need to strike, we also looking what would the best way to ask people to upgrade. We have bit too many recently, so we put a hold on new releases for now.
I've also thought about how many updates have been coming through lately. I love the velocity, but not the notification. Maybe there is a less obtrusive way of updating regularly?
I'd like to mention one less orthodox solution to a problem of managing issues: a little tool called github-agent I wrote https://github.com/k-bx/github-agent
It lets you sync your issues as a git directory of markdown files which you can edit with your favorite Emacs/Vim/Whatever editor. This way it's possible to not get yourself into a "tracker hell", having big and very verbose issues with checklists in them.
There are many possible improvements to the tool, it's pretty much MVP and PRs are welcome, but it's already been an amazing helper, esp for my teams that work remotely.
All issue trackers can be placed on a spectrum: one end is occupied by very fast and very simple apps, another by complex and flexible ones.
Fast ones win in the ease of creation of an issue (just type and hit enter), and generally feel more sexy and attractive, but complex ones can be set up to the exact workflow you need.
For example, Google tasks or now-dead service do.com by Salesforce clearly belong to 'easy' end, and software like Redmine to 'complex' (though it can be made to look rather attractive by the use of skins).
For us, we're sticking to redmine, because it is good and very extendable by the use of plugins. We've found that ease of use does not cover for the reduced flexibility.
We're using Circle theme [1], it's not the most modern out there, but it looks OK with our agile plugin. Abacus and Zenmine are the themes that look most 'modern' to me, but I didn't try them out.
We've been trialling Linear on one of our project teams for the last 3 months (used to use Jira), and it's sped up workflows for product managers drastically. Simple tasks like duplicating and reassigning tickets can take 75% less time.
Day to day I've found myself going from 2+ hours in Jira a day, to <1hr in Linear a day. This makes a huge difference as product management shouldn't be about managing tickets, it should be able launching features the better your product and help users.
Plus I actually love jumping into Linear to catch up on things, whereas Jira genuinely Brough anxiety.
Assuming you're correct, I wonder what caused A to slowly change and become slow like that?
From previously having been a bit innovative?
E.g. the many seconds long load times sounds very unexpected ... How did A change so it now accepts things like that? (Or was it always so -- but we were using Jira 5-6 years ago, don't remember having thought of it as slow)
I found the app to be gorgeous and well designed. Very smooth. I would go as far as considering this over JIRA.
Only thing I’m not really keen on is the sign in with the google account. I’d rather pay to have an account than have to sign up with google.
Sign in with regular email doesn’t really work either, because it never gives you a way to create a password, it just sends a code to your email. If I want to login from a different computer with same email, I can’t unless I sign in with a google account.
We've been a paying customer for a month and enjoy linear a lot.
I tried a ton of other trackers, my second favorite being Notion. Reason we left Notion was lack of an API.
Even though it lacks some basic features, a graphQL API that means I'll never be missing an endpoint and webhooks keep me happy.
For example, I have a step in CI to move issues from staged to deployed. Also then moves associated hubspot to tickets to a queue for CS to inform the customer.
Wow, multiple mentions of open source in the comments, even a mention of Trac, but no mentions of Phabricator yet? It's the most modern and effective open source issue tracker I've seen so far, definitely worth a look if you value FOSS.
I've been interested in using Linear but I don't understand the workflow. Do branches have to use the linear issue slug, for example? Is that the keystone of the workflow? I've looked all over for examples of usage to no avail and the Linear website mentions nothing in the way of docs or onboarding.
I still miss Bugzilla - which was relatively fast. Thought modern js libraries make parallel API calls and make it look fast. But JIRA is too slow and becomes slower with number of tickets and users. Any day, I would prefer speed over nice user interface.
25+ years of working in software engineering has taught me that "issue tracker" presents the wrong metaphor. This product looks like it's not providing any novel improvements on what has failed for everyone so far, other than a slightly shinier surface.
Clearly there's utility to issue tracking: Projects have problems of various kinds (bugs, mostly) that need to be fixed. Sometimes these are conflated with tasks, which are things that people need to do, but those are not the same. Sometimes these are also conflated with "support tickets" from consumers/customers.
The problem isn't having a "database of problems". Clearly that's useful: If I use a program, and it doesn't work in some way, being able to look this information up somewhere is useful, both as a way to confirm that the problem exists for other people, and to follow up on it, and as a way to potentially find an existing solution.
But issue trackers aren't mostly used for that. They're used to drive development, and in that sense, this model doesn't accurately represent the fundamental relationships and power dynamics between people and technology. Issue trackers rot and become unusable piles of cruft very quickly because they're just "databases", and not a process. Databases must be maintained; they model real-life information that becomes out of date almost the moment it's entered. Of course, an organization can use issue trackers successfully, but it requires a very rigid process that constantly follows up, and you end up with a top-heavy social process that mostly (ab)uses a database to keep notes about progress.
I'm a fan of action-oriented task management, based on the principle that if something isn't painful (poses a roadblock to development, for example) or risky (may cause a customer to leave, for example), then it's not worth entering into a centralized database. Project-level task management should be oriented around stakeholders: Whoever an issue is important to should own it and keep it alive.
For example, a project manager can keep a spreadsheet or whatever of what people are working on, and their job is assigning work and making sure things get done, that the work follows some development timeline, and that the upstream stakeholders are satisfied. Nobody downstream needs to see this spreadsheet, but the project manager may need to present it upstream. By doing this, you're essentially rate-limiting your issue/task flow, and ensuring that someone keeps what's important alive. If something slips through the cracks and nobody complains, it wasn't important enough to remember.
A simple document (Google Docs, a wiki, markdown files on Github, etc.) of "known issues" can be used by developers and certain customers/clients to understand deficiencies. It's going to grow stale fast anyway, so prepare for it. Keep it loose and let it rot, and use it as a springboard for ideas in the future (if you bother to ever look at it again). Whenever possible, describe known issues in code so that you can look for TODO comments; that way, they won't go out of sync so easily.
For clients of your project/product, have a support channel ("ticket system"). This is not a database, but a communication tool. Open tickets mean there's a stakeholder waiting at the other end that may not be serviced fully (even if your project doesn't have a formal SLA). Making it public allows people to discover existing problems and find solutions to problems people had in the past. Support channels shouldn't just be for external clients. I think a lot of companies could improve their communications by having internal ones, too.
I think a lot of people understand this, yet it feels liberating to put their backlog in a database, because it seems like something that's ideal for a database. Developers love building task systems; it's such a simple data model that seems to neatly organize real-life concerns. But it's also a model that doesn't scale to more than a handful of issues, and doesn't really match how people work and communicate.
At the same time, it may feel risky to forego an issue tracker. But there are plenty of large projects that are managed without one. PostgreSQL, for example, doesn't have an issue tracker, and bugs are managed entirely through mailing list discussions, and they're doing great.
I'd personally argue that the only thing that really demands dedicated, centralized software here is the support system.
That said, I also think that you could build a turnkey system catering to this type of workflow. It just shouldn't be "database"-oriented. For example, I'm a bigger believer in process (than issue trackers and so on), and I think there are better ways to support the processes.
For example, why does a program have bugs? Whenever a bug comes around, try to systematize it. Was it because tests didn't exist? Was the bug caused by an vendor API and not your own? Sloppy programming? Etc. Collecting and measuring can uncover systemic issues. For example, you may eventually realize that 80% of bugs could have been avoided with tests. The only way to get better is to measure and record. But issue trackers like Github and Bugzilla don't help you with that.
Same thing with support systems. If you collate data about support tickets you can start to understand why you're getting support tickets in the first place. It's not rocket science, yet it appears rare.
At the risk of making the same mistake everyone else makes, I wonder whether the support system and the task queue can be the same system.
They're both distinct from issues because they are made for communication with the rest of the world. (Tasks are one-way until the description turns out to be incomplete.)
Of course they're also distinct from each other in other qualities. Most importantly, having more tickets is generally bad.
Maybe! My point about the support system is that it represents the "outside state". You don't have that person inside your organization, so that's they need a channel into your process. A support ticket needs to be triaged, prioritized, and executed, but that belongs in project management land.
I guess the overarching idea of my philosophy is that all pieces of a company's workings need to be owned by someone. Software like issue trackers don't work because you can't replace ownership with software. You may pretend that all issues going into the system are important, but they aren't, which is how we have ended up with Github bots that go around closing "stale" issues.
Thanks for reminding me about Bors. It's something we've been thinking of using.
Not yet but we had few people hacking on our GraphQL API already so hopefully we'll get there soon. Integrating into your existing workflow is one of the design cornerstones for us, we don't want to waste anyone's time.
Trac was great 15 years ago, but now Trac is a dinosaur. It would be somewhat redeeming if it was at least fast, but it's mind numbingly slow. Before we eventually ditched Trac we had to buy ever faster hardware but requests could still take 20 seconds. Git support in Trac is an afterthought (It started as svn-trac after all!) so pull request management etc is either missing or handled by plugins (and most trac plugins seem inactive or defunct by now). Trying to get a good mobile experience, slack integration I haven't even tried but I assume it's no picnic.
I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems.
New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!
But I don't think it really solves the problem. For most organizations, tracking tickets is a solved (by many products) problem. Starting with a new tool has the appearance of making things better, but leads to the same place. The problem is not the tool, it's the structure of the organization.