[madeofpalk]

> JIRA was replaced by GitHub issues

This is absolutely... not the case.

Sure, for some kinds of projects Github Issues might do, but for anything "real" Github's issue and project management is a serious regression.

---

These tools are not replacing anything, but addressing broader and broader markets. They lower the barrier to entry and bring more people into the fold (perhaps at the expense at having a lower ceiling of functionality).

[moksly]

I’m not sure I agree, I think things like GitHub issues are actually replacing Jira for a lot of companies who either aren’t yet, or not too heavily invested in the atlassian approach.

We did a comparison program with a sister city who uses Jira for their entire process because it had been a good time-tracking system at the time, and we found that their project managers and developers spend around 5 hours a week on something that ours spend on average 35 minutes on. This is anecdotal and we’re not exactly real “software development” cases as we are small helper functions in major enter organisations, but it does speak volumes as to why using Jira in our little anecdotal setting seems terrible. This doesn’t mean our sister city will change their ways though, they won’t. So in a sense you’re right that jira isn’t getting replaced at their place, but it does mean we won’t consider it and will instead look to other tools.

[kwertyoowiyop]

Jira is so horrid that I actually might turn down a job offer from a company that used it.

[madeofpalk]

I work on a large open source commercially funded project, where we more or less have to use Github Issues in one way or another, because that's where community report issues, and I find it very difficult to plan projects on Github.

Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting.

What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.

[steveklabnik]

I mean, it’s all very opinionated. I think at this point I am borderline “I would rather have no bug tracker than Jira.” Issues isn’t perfect but it’s the best I’ve ever used.

[greatgoat420]

I have never used Jira, could you say more about your feelings towards it? Currently we use an old in-house solution and are thinking of shifting.

[AlotOfReading]

The biggest issue by far is how slow it is. I don't mean bubble sort slow, I mean deliberately engineered quantum bogosort. A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful. That leads to all sorts of avoidance because using it for anything takes long enough to be worth documenting as a ticket in its own right.

Compounding this issue is how many clicks even "simple" tasks take because of their bizarre choices. Basic necessities like changing ticket status can't be done without opening separate pages, etc.

One you've actually managed to create a ticket and assign status, good luck finding it later. Backlogs inevitably evolve into infinite swamps that no one knows the full contents of. Not helping is the fact that the search is terrible. I often vaguely recollect some detail or test procedure that someone helpfully mentioned/documented in a ticket somewhere before closing. I successfully find maybe a third or less of those.

Also it's highly customizable, so any skills or knowledge from one company don't apply to the installation at any other.

[allset_]

I don't like Jira that much, but this is just blatantly false.

> A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful

I use Jira daily, it's nowhere near this bad. It's not fast, but pages load in about 5 seconds.

> changing ticket status can't be done without opening separate pages

You select the new state from the drop-down and set it. This is available through a few different routes/views.

> good luck finding it later

Their search looks through title and description, what else do you want?

> Backlogs inevitably evolve into infinite swamps that no one knows the full contents of.

If you let them, of course. If you don't close the tickets, what did you expect to happen?

[Kinrany]

They probably meant seconds. A website that takes seconds to open is unusable.

[AlotOfReading]

I wish I was mistaken, but I do literally mean minutes. I've measured it with a stopwatch before.

[Jolter]

I assume your workplace is using the cloud solution? Our huge-enterprise in-house install is blazing fast, as long as nobody misconfigures some automation tool to overload the database.

Edit: I did have the bad luck to discover it performs pretty horribly if you’re on a high-latency connection to the office. I think it makes a lot of round-trip requests.

[dmitriid]

Yes, JIRA Cloud is unusably slow and their "nextgen" rewrite only compounds problems by adding workflows no one asked for and by removing workflows everyone depends on.

Properly configured on-premise installations are usually quite fast.

> I think it makes a lot of round-trip requests.

It does, and that's the main issue

[watwut]

I don't know how you have it configured, but I have to say, we dont have these problems.

[AlotOfReading]

The configurations can supposedly make a huge difference. However, I've yet to see a company where these weren't serious issues and I can only speak to my experience. If you're lucky enough to have a decent installation I'd recommend buying IT a nice lunch or something. A bad Jira setup is truly awful.

[girvo]

Cloud JIRA itself is slow, for what it’s worth. Seconds long RTTs — which make using a CLI to bypass the web UI pointless in my experience

[greatgoat420]

Thanks for replying, I think I get it now. We use SharePoint which has very similar issues.

[bradknowles]

Jira is very sensitive to the configuration you build for it, and the hardware it is running on. The full configuration for Jira would make an Encyclopedia look small. Get that wrong (as many places do), and it is hard to use and dead-dog slow, at the best of times. But if you have a real Jira wizard who can configure things correctly, then it can easily be the fastest and easiest way to organize your development and operational support tasks.

I’ve seen both good and bad Jira configurations. And I’ve seen them run on both good and bad hardware solutions.

There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly.

I submit that anyone who hates Jira probably has not seen a good Jira configuration. And anyone who loves Jira probably has seen a good configuration and doesn’t understand what everyone else is complaining about.

Jira is a real Jekyll vs. Hyde type of tool. In my experience, how you feel about Jira says much more about the type of configuration you’ve seen than anything else.

[pjerem]

> There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly.

This has been done wrong by Atlassian.

I’m sometimes really jealous when I see fast self hosted public JIRAs and by the meantime, the instance I have to work everyday on atlassian cloud is both snail-slow and airplane-heavy.

[yjftsjthsd-h]

On the one hand, I actually do agree with you. On the other hand, if nobody can use the tool right, then it's not the user at fault.

[CRConrad]

The GP's point was precisely that some can use the tool right.

[dmitriid]

> There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly

And they are replacing it with JIRA Cloud that cannot be configured at all, and is unbearably slow.

[greatgoat420]

Thanks! I hadn't heard about this before!

[nzmsv]

Even when JIRA isn't slow: it has an absolutely horrid implementation of search that basically gives you a bunch of random issues in addition to what you are looking for (your search term appears nowhere in them). The exact set will randomly change. And it'll keep insisting on being helpful and turning your search into "smart" query and then failing because it is not valid.

[steveklabnik]

I agree with both of the others who replied. Jira has infinite knobs, and they all get turned, and you build this massive, complex system when what you really need is a textbox and some tags.

I am not normally a "less features is more" kind of person. But with issue tracking, I am.

[rhizome]

Maybe the thing to do is what Slack did with IRC and slap a (better, as the case may be) GUI on rt or Trac.

[thrower123]

I desperately just want something like Trello boards in Azure Devops...

There are boards, but they are so unwieldy. Just put all the work items on a board and let me drag them around and see everything at a glance.

Everything else with the source control and build pipelines and wikis is so good, this weakness is glaring.

[selfhoster11]

Github issues work well for simple needs and for issues that don't cross the boundaries of a single repo/don't refer to non-code activities. If even one of those is violated, you're much better off with Jira.

[breakfastduck]

I'm lost now when it comes to project / dev / story etc management tools.

No idea what the best option is, any recommendations for tools developers will actually use or do you just need to do a custom integration with github issues?

[danielheath]

I've long wished for a tool that (for git) what fossil has built in: issues stored in the repository, where developers can use their full range of tools to work on them locally.

A few additional things would be required to make this work for less-technical team members, and you end up building some of your own workflow, but it means that E.G. you have options like "update the description of a ticket as part of the pull request that implements it".

[Izkata]

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them:

* Some of them make a mess of some part of git; one of them put its info in separate git branches you couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.

* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.

* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.

* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.

Sibling mentions git-bug, a few others I recalled/quickly found:

https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)

https://github.com/dspinellis/git-issue

https://github.com/neithernut/git-dit

https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)

[morelisp]

> a single issue could be in different statuses depending on which branch you were on

To me this is the main point of storing issues in git!

[michaelmure]

It seems to be a polarizing idea. Many people can't stand it, but also I suspect that very few actually worked with something like that.

In any case, I believe that it's better to build a data model/storage without that concept (read: don't store the data in the same branch as the code) to have the freedom to built it with less constraint and make it right. Once that work you can add this "branch sensitivity" concept on top and again make it exactly how you want it.

An example of problem you get when storing the bug data in normal code branch: cool, you got the bugs state deeply stick with the code so you know exactly when a bug is resolved and in which branch. But now you are stuck with git only to deal with merge conflict, which means you might need to have the user fix it when it goes wrong. Will you push that to a non-technical person as well? Also, what happen when you rebase or cherry-pick?

[Izkata]

Consider the "no overarching view" part: if you just cloned the repo, you'll see a bunch of open issues and no hint that they're already being worked on, because you have to check out each branch to see if that issue has updates.

[mikepurvis]

I want that too, but I think it only really works with a monorepo, or else you end up with having to aggregate issues from all over your different repos as well as dealing with bridging that automation so that an issue in repo X can be resolved by PRs in repos Y and Z.

(I'm in a many-repo company that used to use the per-repo bugtracker built into Bitbucket and switched many years to Jira. Jira has its warts, but it's miles better for the project management level task of burning down to a release.)

[breakfastduck]

Worst requirement we have - old school board who want roadmaps, timelines or more honestly numbers that illustrate performance.

It's a losing battle between tool functionality and reporting abilities.

[froh]

git-bug looks promising to me:

https://github.com/MichaelMure/git-bug

[eyelidlessness]

- Still my preferred solution: real cards on a real board. Physical space limits prevent overload in a lot of ways.

- Very seriously discussed prototyping a remote robotically operated version of a real physical board with a friend when the pandemic started, but we both got too busy.

- Trello, with most optional things not turned on, is still the closest thing to a real kanban board. Do go ahead and enable GH integration, but don’t turn on the zillion things that turn it into yet another Jira.

- AirTable’s kanban view is surprisingly good, but it’s fundamentally a shared spreadsheet and a lot of UI/UX confusion comes from that because any filtering or sorting you do is global to others using the same view.

[burlesona]

I switched from Jira to Linear and am very happy with it. Just the right mix of power, completeness, and customization, without any fussy fiddling. It’s also blazing fast.

[jschwartzi]

Linear.app is way faster and tighter than JIRA, but lacks a lot of features that I actually really need in my job:

* Advanced Roadmapping - JIRA will, given a pile of issues, sort them and fake-assign them to individuals on your team to determine how long it will take you to complete a project. This is way more powerful than burndown charts and cycles when you're planning a hardware project with a tightly-defined deadline. Without it I have to drop back to spreadsheets to provide any insight into when a project will be completed. It's especially important when the business peels engineers off the project.

* Time-based estimating - JIRA lets me plug hours in for estimates instead of railroading me into T-shirt sizes, which means I can actually use the tool to give an accurate estimate of when we'll be done. Linear requires you to calibrate your expectations by running a few cycles first, which makes it a really bad fit for projects that have a defined end date.

I think Linear has a lot of potential for teams that don't work to fixed deadlines, but for my purposes it's just a very fast spreadsheet.

[breakfastduck]

We're running Monday. Has to be used by approx 60-80 users mix of dev / old school projects & support.

I'll check out Linear. Been looking at Clubhouse too.

[prennert]

We are using clubhouse after looking at a lot of solutions. We all like it as it is quick, low complexity and does not introduce artificial barriers between the teams.

[porker]

Linear looks like a clone of ClickUp (which we settled on) and I'd recommend checking it out too.

[design-material]

What's wrong with Monday?

[breakfastduck]

Honest truth - our developers don't like it.

Very DIY. You can build great workflows if you put the effort in. Brilliant reporting, main reason we adopted.

Clubhouse for example gives the agile structure (epics, stories etc) by default and you conform to it. Minimal setup effort. From a 'management' perspective I actually like monday, by the actual end users don't seem to like it.

Getting a true hierarchy and relationships requires similar thought to setting up a SQL DB. Powerful, but I don't think we have the resource to really build upon and support stuff.

[porker]

I've never found a solution that both developers and management like.

We tried dozens and I've put it down as an unsolved problem.

[typeofnandev]

If only it _was_ the case!

[madeofpalk]

Sliding in here with the hot take, but Jira can actually be pretty good! Github is terrible at project management.

The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.

[eyelidlessness]

I hate that I agree with this but...

I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance.

Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle.

My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello.

The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.

In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.

[CRConrad]

> The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.

FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.

[eyelidlessness]

We must have missed each other on passing trains. My experience was that sprints are not just built in but required. I set up my last project with a catch all “active” sprint that never ends, and a catch-all “later” sprint that also doesn’t end for stuff that’s not being actively worked on or considered.

[CRConrad]

Hm... Maybe that's what we had at my old job too, then. Perhaps someone had set all that up before the rest of us in the team ever got to see it, so we never noticed.

Has the "Sprint" link always been on the bottom of the rightmost column?

[typeofnandev]

>The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.

I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.

[gregmac]

I was previously a JIRA admin, and what I very quickly found was making the workflows the least restrictive possible was the most effective. JIRA itself is quite feature rich and that can be abused, but using it to make your configuration relatively "dumb" makes the actual user experience a lot better.

I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together.

I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it.

The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced).

Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it.

If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.

[madeofpalk]

To be clear - you have to go in and actively make Jira worse to make it bad. If you stick to the modern defaults and don't add in additional workflows you'll be fine.

It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.

[aunty_helen]

I worked at a company that created a team of people to go in and actively make jira worse. Of course that's not what it was envisioned as, their actual job was to make jira fit the stakeholders requirements and buiness processes we had.

However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.

[dragonwriter]

> If jira didn't have the ability to make it crap

Then your managers would buy a tool that did instead.

> maybe just try not to smush existing ms CRM workflows into a tool for devs.

If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get.

Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.

[steveklabnik]

This is why I prefer Issues. The lack of features is a feature.

[dleslie]

I happen to agree.

I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth.

Since last using Jira I've never felt nearly as aware of the state of a project as when I did.

[porker]

Yes, dashboards are underrated by those who haven't used them.

The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals.

The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track.

Management never spotted.

[dleslie]

Ha! I was a team lead at a company where something similar happened. Management was obsessed with the burn down chart and equated total completed with productivity.

So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks.

I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.

[Talanes]

For some reason, plenty of people in management don't seem to realize that raking people over the coals over individual data-points just incentives your workers to avoid giving up data.

[plorkyeran]

Jira is an amazing argument for the idea that having too many features is itself an anti-feature, and github issues' second biggest strength compared to it (behind the integration with github) is specifically that it doesn't try to do everything.

[cryptonector]

Or an argument for doing it right. It's got a query language that looks a bit like SQL, just... not SQL. It's got an ugly but responsive UI. It's easy to over-customize.

The real problem is that it gets over-customized, and as with all databases, schema is forever, so after enough years of using it you have: ugly remnants of how you used to do things mixed with the ugly new things you're doing, and a devops team dedicated to maintaining and further over-over-customizing your JIRA instance.