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

151–160 of 230 posts

Re: Linear – A fast issue tracker

#151

Post by bachmeier »

jorde wrote: post #19
bachmeier wrote: post #13

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 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.

Re: Linear – A fast issue tracker

#152

Post by Kinrany »

atombender wrote: post #146
Kinrany wrote: post #144

Earlier quoted context omitted.

So: - a stream of tasks, prioritized by the project manager - WIP tasks, as few as possible - a ticket system for communicating with clients; tickets should be resolved eventually - a heap/knowledge base of unresolved issues that may never be fixed

Pretty much! 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 exam…

> support system

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.

Re: Linear – A fast issue tracker

#153

Post by ulisesrmzroche »

I don’t see the value add. I work at a place with 1000+people using Jira. No one complains about the performance.

There’s really nothing here I can make a case to the managers about. It does look nice but thats not enough.

I think there’s room for an opinionated issue tracker, Jira is like everything and the kitchen sink and people make their own rules.

Re: Linear – A fast issue tracker

#154

Post by ulkesh »

dsr_ wrote: post #22
ggambetta wrote: post #16

What a strange state of affairs that in 2020 an USP for an issue tracker is that it is fast. An issue tracker. How did we get here?

By ignoring RequestTracker.

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.

Re: Linear – A fast issue tracker

#155

Post by tommoor »

humanfromearth wrote: post #61
olingern wrote: post #51

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.

Same here, I tried Linear, but the fact that it doesn't use github as the source of truth is a deal breaker for us. I would love something like Reviewable - it uses github as the "DB" and provides a nicer interface for doing code reviews.

> the fact that it doesn't use github as the source of truth is a deal breaker for us.

Why is that important? You'd be completely hamstrung by the available GitHub API's and speed.

Re: Linear – A fast issue tracker

#156

Post by p_l »

magicalhippo wrote: post #125
ithkuil wrote: post #54

Earlier quoted context omitted.

Cloud or self-hosted?

Self-hosted, as mentioned.

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.

Re: Linear – A fast issue tracker

#157

Post by iamjaredwalters »

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.

Re: Linear – A fast issue tracker

#158

Post by mikepurvis »

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 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.

Re: Linear – A fast issue tracker

#159

Post by atombender »

Kinrany wrote: post #152
atombender wrote: post #146

Earlier quoted context omitted.

Pretty much! 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 exam…

> support system 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…

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.

Re: Linear – A fast issue tracker

#160

Post by sequoia »

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…

> 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.

Post reply on HN