It would be neat to have Github, Gitlab, etc. mirrored because I've always seen issue software that doesn't directly integrate with repositories to be more work to manage than not. I make heavy use of the `fixes #` feature on Github to auto-close issues. This adds up over one or two years when you're closing multiple issues per week.
Same here, I tried Linear, but the fact that it doesn't use github as the source of truth is a deal breaker for us.
I would love something like Reviewable - it uses github as the "DB" and provides a nicer interface for doing code reviews.
We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker. I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems. New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you pil…
> 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!
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…
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.
We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker. I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems. New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you pil…
> 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.
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
We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker. I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems. New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you pil…
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…
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 ?
We've been using Linear for a couple months. It's kind of like Superhuman in that the primary benefit is hotkeys. Otherwise it is an issue tracker. I think the reason we see a steady stream of new issue trackers is that teams are trying to fix with software what are people problems. New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you pil…
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 re…
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 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.
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…
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 ?
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.