[HN Gopher] Linear - A fast issue tracker
___________________________________________________________________
Linear - A fast issue tracker
Author : tommoor
Score : 267 points
Date : 2020-06-30 18:16 UTC (4 hours ago)
(HTM) web link (linear.app)
(TXT) w3m dump (linear.app)
| amelius wrote:
| 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...
|
| 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 wrote:
| 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).
| atombender wrote:
| 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.
| bachmeier wrote:
| 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 wrote:
| 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.
| cachestash wrote:
| 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.
| dsr_ wrote:
| 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 wrote:
| 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_ wrote:
| 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.
| jorde wrote:
| 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.
| _jal wrote:
| 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.
| oftenwrong wrote:
| RT was great! Once upon a time, I worked in a Perl shop and we
| had a lot of automation for RT built via scripts that spit out
| emails.
| ggambetta wrote:
| 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_ wrote:
| By ignoring RequestTracker.
| dylanpyle wrote:
| 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!
| beshrkayali wrote:
| Looks a bit broken on Firefox.
| jayp wrote:
| What parts? Been using it for months on Firefox.
| amelius wrote:
| 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.
| tylergetsay wrote:
| 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.
| Hnrobert42 wrote:
| 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 wrote:
| 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?
| grk wrote:
| So cloud hosted Jira is misconfigured?
| heavenlyblue wrote:
| I would assume they mean "you have not set up your JIRA
| workflow according to your needs"
| macspoofing wrote:
| On-prem JIRA is fast. Cloud-hosted JIRA is slow. It's clear
| as day that Atlassian throttles the cloud-hosted version.
| seekingcharlie wrote:
| 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".
| plainOldText wrote:
| 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.
| madrox wrote:
| 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 wrote:
| Ironic thing to say, since for many, their IDE is visual studio
| code, an electron app.
| arcticfox wrote:
| > 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.
| macspoofing wrote:
| There's no advantage to native-based issue trackers.
| haram_masala wrote:
| 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.
| ocdtrekkie wrote:
| 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 wrote:
| 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?
| ocdtrekkie wrote:
| Fair points.
| haram_masala wrote:
| 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.
| robjbye wrote:
| 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.
| xwdv wrote:
| Is there any CLI interface?
| knes wrote:
| we actually build an app to help with our sprint planning on
| top of their API.
|
| You can read about it here >>
| https://blog.getcensus.com/building-spatial-interface-for-sp...
| jorde wrote:
| 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...
| PStamatiou wrote:
| 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.
| Andrew_nenakhov wrote:
| 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.
| [deleted]
| [deleted]
| knes wrote:
| 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 wrote:
| 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.
| saagarjha wrote:
| Let me ask the inevitable question: Electron?
| auslegung wrote:
| It appears so. I found it in their careers section
| https://linear.app/readme, under Tech.
| jorde wrote:
| 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.
| tyre wrote:
| 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.
| enra wrote:
| Thanks for the feedback and trying it out!
|
| 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
| SAI_Peregrinus wrote:
| 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.
| flarg wrote:
| This. Jira used to be famous for it's ease of use and
| fantastic cross linking between artifacts, but now it's
| always just very slow.
| zerkten wrote:
| 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.
| mumblemumble wrote:
| 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.
| Benjammer wrote:
| 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?
| lifeisstillgood wrote:
| 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 ?
| LukeShu wrote:
| 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.
| jiveturkey wrote:
| 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?
| golemiprague wrote:
| You say it as if it is a fact, what are you basing it on?
| There are so many examples of start up companies where most
| of the team were engineers and they created very popular
| and successful products. It might be even the opposite,
| many times product people are not necessary really, a
| middle man between customer facing people and engineering
| that nobody really needs.
| mumblemumble wrote:
| 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.
| coliveira wrote:
| 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.
| sriram_sun wrote:
| > The problem is not the tool, it's the structure of the
| organization.
|
| Nicely put! Also, it's probably more like how the organization
| ended up evolving - something no one knew beforehand!
| [deleted]
| sriram_sun wrote:
| > The problem is not the tool, it's the structure of the
| organization.
|
| Nicely put! Also, it's probably more like how the organization
| ended up evolving - something no one knew beforehand!
|
| Newer products should start their sales pitch addressing that
| last sentence in OP's post.
| tbrock wrote:
| 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".
| ryanisnan wrote:
| > 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".
|
| - every JIRA customer ever
| magicalhippo wrote:
| We're a JIRA customer and we're quite happy. It's not slow,
| at least to any degree that matters.
|
| We're not a huge team, nor do use much more than tickets
| with FishEye integration though. We also have a self-hosted
| instance.
|
| But for us it has worked quite well, and I have better
| memories of JIRA than say MantisBT which I used before.
| munchkinship wrote:
| you are self-hosted, which is different from cloud.
| magicalhippo wrote:
| But we're still JIRA customers, which was the point I was
| trying to make.
| ithkuil wrote:
| Cloud or self-hosted?
| magicalhippo wrote:
| Self-hosted, as mentioned.
| ahnick wrote:
| 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.
| icegreentea2 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| jnwatson wrote:
| 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.
| _Qeomash_ wrote:
| 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.
| Twirrim wrote:
| All the extra plugins etc. that people bolt in to get
| those extra features really slow it down too.
| ghshephard wrote:
| 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.
| tbrock wrote:
| 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.
| CraigJPerry wrote:
| 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
| tbrock wrote:
| We must have been using it incorrectly then, oh well.
| Good riddance Atlassian.
| immy wrote:
| 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.
| kevmo314 wrote:
| 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.
| robotresearcher wrote:
| 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.
| elithrar wrote:
| 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.
| jayparth wrote:
| 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.
| robotresearcher wrote:
| 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.
| jayparth wrote:
| 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.
| robotresearcher wrote:
| Here's the quote:
|
| "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 guess it can be read either way.
| fredfjohnsen wrote:
| No, it is not really true. It is completely false & you are
| correct to question it.
| m0xte wrote:
| Nailed it.
|
| 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.
| the_arun wrote:
| 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.
| hknd wrote:
| Finally a simple issue tracker - I was waiting for something like
| this for ages.
| fizixer wrote:
| Oh I'm creating an even better, faster issue tracker. I'm naming
| it 'deep learning'.
| tadruj wrote:
| 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.
| _jordan wrote:
| 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.
| cw wrote:
| Linear brings me joy every day.
| njn wrote:
| It's closed source. [Trac](https://trac.edgewall.org/) is better.
| saagarjha wrote:
| Because Trac is open source, or because Trac is easier/nicer to
| use?
| randomchars wrote:
| In what way? It definitely appears less user friendly, and has
| the "typical open source look".
| alkonaut wrote:
| 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.
| olingern wrote:
| 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 wrote:
| 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.
| evaneykelen wrote:
| 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).
| enra wrote:
| 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-...
| ghayes wrote:
| 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.
| enra wrote:
| Awesome to hear! We also think that little annoyances really
| hurt the team productivity over time. Especially in tools
| that you use daily.
| tbodt wrote:
| The landing page seems to say that interactions take under
| 100ms. What computer did you measure this on?
| mdeeks wrote:
| 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 wrote:
| 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
| ivanfon wrote:
| Is the desktop app native?
| ComputerGuru wrote:
| No, it's just electron. I don't see the benefit over making
| it a PWA or even just a regular self-hosted web app.
| nurpax wrote:
| 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?
| enra wrote:
| We are working on this. We have some test build, but each
| platform adds bit complexity to the build process so
| looking to automate better first.
|
| All Linear features, including the offline mode works on
| the browser tool.
| jay_kyburz wrote:
| 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.
|
| Good old Fog Bugz used to have that.
| egorfine wrote:
| 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.
| jorde wrote:
| 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).
| nurpax wrote:
| 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.
| enra wrote:
| Sorry about that! It should work now.
|
| 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.
| JaakkoP wrote:
| 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.
| Lightbody wrote:
| 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 wrote:
| 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.
| rudolph9 wrote:
| 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
| NetOpWibby wrote:
| I have an invite to this finally but haven't been able to delve
| into it much. Will do so this week.
| imdsm wrote:
| Tip: show a demo or screenshots. I'm busy. I looked for 3 seconds
| and bounced.
| Lightbody wrote:
| The page is full of screenshots (5+) and there is a clear call
| to action to sign up and try it out. _shrug_
| sangupta wrote:
| 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.
| jayp wrote:
| 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...
___________________________________________________________________
(page generated 2020-06-30 23:00 UTC)