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

171–180 of 230 posts

Re: Linear – A fast issue tracker

#171

Post by rudolph9 »

the_duke wrote: post #137
rudolph9 wrote: post #65

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

Check out git-bug [1]. It's a decentralized issue tracker that stores the data in Git and offers a CLI/TUI/web UI. [1] https://github.com/MichaelMure/git-bug

This looks very promising. Thank you!

Re: Linear – A fast issue tracker

#172

Post by hinkley »

jnwatson wrote: post #75
ChrisMarshallNY wrote: post #46

Earlier quoted context omitted.

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

In my experience, it isn't Jira that people hate, it is the horrible rules and bureaucracy-ridden workflows that Jira allows an admin to implement. My team switched back to Jira after trying several other tools and we're pretty happy.

If you turn bureaucrats into UI designers, you’re gonna have a bad time. We have several classes of tooling that do just that.

Atlassian tools are particularly overt in their belief that the tool belongs to the managers and not the team. Bamboo especially.

Re: Linear – A fast issue tracker

#173

Post by hinkley »

dathinab wrote: post #167
tbrock wrote: post #78

Earlier quoted context omitted.

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.

Might be a problem with customization. THE main problem with JIRA is people breaking it with customization in one way or another. Or put is on very slow, high network latency servers... EDIT: Just to be clear, JIRA is never fast. But can be usable if you are not super sensitive to small latency.

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.

Re: Linear – A fast issue tracker

#174

Post by hinkley »

tbrock wrote: post #128
CraigJPerry wrote: post #104

Earlier quoted context omitted.

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

We must have been using it incorrectly then, oh well. Good riddance Atlassian.

Almost everyone is “using it incorrectly”, but it’s like the aphorism about assholes. (If you meet assholes all day long, you’re the asshole.)

If your software encounters idiots all day long, you’re the idiot.

Re: Linear – A fast issue tracker

#175

Post by hinkley »

icegreentea2 wrote: post #58
ahnick wrote: post #41

Earlier quoted context omitted.

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

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…

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.

Re: Linear – A fast issue tracker

#176

Post by hinkley »

mikepurvis wrote: post #158
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…

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

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.

Re: Linear – A fast issue tracker

#177

Post by lovehavetodo »

Benjammer wrote: post #139
jiveturkey wrote: post #126

Earlier quoted context omitted.

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…

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

Weird.

Re: Linear – A fast issue tracker

#178

Post by pr91 »

Benjammer wrote: post #139
jiveturkey wrote: post #126

Earlier quoted context omitted.

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…

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

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.

Re: Linear – A fast issue tracker

#180

Post by utkarsh_apoorva »

mumblemumble wrote: post #138
Benjammer wrote: post #130

Earlier quoted context omitted.

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…

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

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.

Post reply on HN