
Linear – A fast issue tracker - tommoor
http://linear.app/
======
tyre
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.

~~~
Benjammer
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?

~~~
jiveturkey
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?

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

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

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.

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

Maybe fix this, Linear?

~~~
fwip
I'm pretty sure that's bog-standard EULA for "We need to show the tickets you
made to other users on your team."

~~~
dsr_
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."

You should always say what you mean in contracts.

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

Our announcement post: [https://medium.com/linear-app/practices-for-building-
linear-...](https://medium.com/linear-app/practices-for-building-linear-is-
now-open-for-all-234f7cf9a3d0)

~~~
mdeeks
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?

~~~
enra
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](https://github.com/linearapp/linear/blob/master/docs/API.md)

------
_jal
I was ruined for bug trackers by RT
([https://bestpractical.com](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.

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

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

I wish I’d see more sites like this.

~~~
jacob_rezi
How was it built? Any clue?

~~~
prvnsmpth
They've used Next.js

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

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

~~~
gnud
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?

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

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

~~~
fredfjohnsen
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?

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

Last, hot circle of garbage:
[https://m.youtube.com/watch?v=S70lQwc0FDs](https://m.youtube.com/watch?v=S70lQwc0FDs)

To get specific:

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

Now that’s a mixed metaphor for you.

~~~
fredfjohnsen
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?

I don't know that this is the way to fix what you believe to be an open issue.
It probably is: [https://community.atlassian.com/t5/Jira-Questions/Hide-
Close...](https://community.atlassian.com/t5/Jira-Questions/Hide-Closed-Epics-
from-backlog-view/qaq-p/625966)

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

All generalizations are false...

~~~
Hnrobert42
[https://jira.atlassian.com/browse/JSWCLOUD-17996](https://jira.atlassian.com/browse/JSWCLOUD-17996)

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

------
ggambetta
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?

~~~
dsr_
By ignoring RequestTracker.

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

------
amelius
Reminds me of Joel Spolsky and his FogBugz tool (and who later started
StackOverflow & co).

[https://www.joelonsoftware.com/2000/11/08/painless-bug-
track...](https://www.joelonsoftware.com/2000/11/08/painless-bug-tracking/)

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.

~~~
macspoofing
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).

------
dylanpyle
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!

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

~~~
the_duke
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](https://github.com/MichaelMure/git-bug)

~~~
rudolph9
This looks very promising. Thank you!

------
tadruj
This is a `vi` of issue trackers. It's the kind of software which, after you
use it, you desire whole web would use the same design philosophy.

~~~
jcoustaury
very true

------
knes
been using Linear for 3 months at my new company.

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.

~~~
enra
Thanks for the feedback! We want to add quicker ways to add multiple issues,
which can be useful for example when creating a new project.

Also you should be able to create issues through slack with /linear or right
click the message and hit the "..." menu to create an issue.

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

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

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

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

------
gorgoiler
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?

------
madrox
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?

~~~
novok
Ironic thing to say, since for many, their IDE is visual studio code, an
electron app.

------
saagarjha
Let me ask the inevitable question: Electron?

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

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

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

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

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

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

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

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

~~~
erichurkman
There are already a number of opinionated issue trackers, like Clubhouse and
Pivotal Tracker.

~~~
ulisesrmzroche
Yeah you’re right. Well then there’s no more room for issue trackers.
Definitely not at the higher levels

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

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

------
Lightbody
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!

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

~~~
pfista
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?

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

------
fizixer
Oh I'm creating an even better, faster issue tracker. I'm naming it 'deep
learning'.

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

~~~
tyteen4a03
What skins do you use? I've found Redmine's default skin to be too stuck in
2010 for me.

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

[1]:
[https://www.redmineup.com/pages/themes/circle](https://www.redmineup.com/pages/themes/circle)

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

Happy to answer any questions people may have.

------
stunt
Atlassian seems to be one of the slowest software companies. They haven't done
much to improve their products in all these years.

Everything they have is ready to be overtaken by a disruptive product.

~~~
cutemonster
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)

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

------
qwerty456127
All I ever wanted of an issue tracker is a HN-like comments tree.

------
jayp
Been using Linear everyday for the past few months and love it.

For many that may find it interesting, here is a recent conversation I had
with Linear co-founder Tuomas Artman about how they iterated by listening to
their users: [https://www.heraldhq.com/userstand/how-linear-leverages-
thei...](https://www.heraldhq.com/userstand/how-linear-leverages-their-user-
community-to-dig-into-customer-problems)

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

------
cw
Linear brings me joy every day.

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

[https://www.phacility.com/](https://www.phacility.com/)

------
neop1x
Product name Linear doesn't seem to be the best choice to me. Google search
(correctly) gives linear algebra results.

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

------
ussrlongbow
No self-hosted option? Passing this one.

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

------
stunt
I saw many successful examples of teams with super simple boards. Most of them
only with built-in Gitlab/Github issue trackers.

When the tooling provides too many options, you will start adding complexity
to your workflow without considering real benefits.

------
hknd
Finally a simple issue tracker - I was waiting for something like this for
ages.

------
jbaber
Still alpha, but I've been enjoying [git-
bug]([https://github.com/MichaelMure/git-
bug](https://github.com/MichaelMure/git-bug)).

------
einpoklum
It may be fast, but it's not free software. Too bad.

... also, the UI seems to be a lot of white-space and faded colors. That's
another negative sign for me.

------
ing33k
I just signed up and started using it. Cannot really give a review about
it,but the UI is really good. Would like to know the tech stack behind it.

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

~~~
Kinrany
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

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

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

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

------
tomaskafka
App? Okay ... wait, does that mean no tabs (= instantly accessible working
set)? Nononononono! :)

------
NetOpWibby
I have an invite to this finally but haven’t been able to delve into it much.
Will do so this week.

------
smcleod
Just seems to load an empty blank black page in Safari on iOS 13.5.1.

------
xwdv
Is there any CLI interface?

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

[https://docs.linear.app/API-
Webhooks-d7b411ffab7b4a91853d04a...](https://docs.linear.app/API-
Webhooks-d7b411ffab7b4a91853d04ad12725e47)

------
pandesal
Wow. What a very diverse set of founders

------
beshrkayali
Looks a bit broken on Firefox.

~~~
jayp
What parts? Been using it for months on Firefox.

------
imdsm
Tip: show a demo or screenshots. I'm busy. I looked for 3 seconds and bounced.

~~~
Lightbody
The page is full of screenshots (5+) and there is a clear call to action to
sign up and try it out. _shrug_

------
njn
It's closed source.
[Trac]([https://trac.edgewall.org/](https://trac.edgewall.org/)) is better.

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

