Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear – A fast issue tracker

linear.app

Post reply on HN
Print view View original

211–220 of 230 posts

Re: Linear – A fast issue tracker

#213

Post by trabant00 »

_jal wrote: post #15

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 con…

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 :(

Re: Linear – A fast issue tracker

#214

Post by aidenn0 »

mumblemumble wrote: post #98
Benjammer wrote: post #48

Earlier quoted context omitted.

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…

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 thinki…

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?

Re: Linear – A fast issue tracker

#216

Post by k_bx »

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.

Re: Linear – A fast issue tracker

#218

Post by kschrader »

divbzero wrote: post #184
tyre wrote: post #3

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 pil…

> 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 architectur…

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.

Post reply on HN