I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.
Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I have no doubt you can use Jira in a "KPI led" way. I do doubt you can use Remedy in a responsible way, but even if you can, it relies on the culture of those selling the tools.
Sadly I fear jira and slack will be next -- they already took Zoom and gave us teams instead, after all we "already pay for teams with office" (which aside from cloud-based email, I, and my teammates, never use).
Never has an anti-trust move been so obvious or damaging.
The same with 'agile' that's just forced on us not because it is a great idea but because our idiot CIO loves her buzzwords. It's not even implemented right.
Ps I don't do any development work. The problem is they're trying to shoehorn a methodology that doesn't work for us. I'm not even part of a team that do the same as what I do. But in general i don't like the mental restrictions that having to adhere to methodologies brings.
This explains it a bit better: https://news.ycombinator.com/item?id=39338582
Do you simply not track or communicate at all? Do you store it all in a personal notebook? Do you store everything in emails? Files in dropbox? Or do you rely on memorising everything you do, why you do it, when you do it, for who, etc?
Like I said I'm not a developer at all. I don't use git for work. Nor do I collaborate on my tasks with other people. My brain is enough to keep track of things. Yet the company wants everyone to be "agile" regardless of the role.
I know what to do and how to do it, I don't like the whole unnecessary framework around it. Sure, tools that actually help me to do my job are good. But my job is not one that requires very specific tools. And methodologies I hate because they try to constrain my thinking.
For the same reason I really hate participating in religions, for telling me what to think, to show up in church and pretend I agree and be part of their arbitrary group with its arbitrary rules. I'm more of a free spirit. I'm the opposite of a 'team player'.
But of course people differ and I know some people love the sense of belonging and the guidelines.
It is horrible. I just want to work. It's two lines of a fix in a config file. It does not need such a ceremony but a message on teams.
In my case this is a solution to a problem of fluctuation and growth so described processes can make everyone redundant. I bet the people set this up never even read the agile manifesto.
That doesn't sound real. There's supposed to be some central department(s) that collect ideas from the process framework of the season or requested by customers (especially those items for levels that are not requested), add their own ideas and create a superset of that as configuration with everything set to mandatory. The result is infliced upon everyone, except of course the department that was responsible for the definition.
1) Let a Team channel be a normal-ass chat instead of some weird forum-in-a-chat-interface. Shit gets lost. Creating a new post feels very formal and high friction, because it’ll push everything else out of view (another, minor problem: teams’ padding and whitespace is way out of control). Make it configurable! That’s ok. The weird chat-as-forum thing is fine for a very low-traffic announcements channel (and very bad for anything else) so having it as an option is alright.
2) Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel.
These two problems force conversations away from the “Team” and into meeting-specific chats and DMs. It’s really, really bad. It silos knowledge and makes it hard to tell wtf is going on.
Teams is horrible for distributed or hybrid work because of these two deficiencies.
It’s frustrating because Teams can already do normal chat rooms, and can already schedule meetings. Just not in the most-useful places to have those two features. It’s not brand-new feature development from scratch.
All they goddamn need is a way to permanently attach Chat rooms to a Team, as a channel, basically. The channels are these weird forced-threaded things that are more like… blogging? With comments? In a chat interface? Or a forum but it’s impossible to follow several threads because of the interface? They’re horrid and have a UI so bizarre that I’d buy it as parody.
Just make it like Slack, and Discord, etc. its a solved problem!
* In MS teams, I can create conversations, group chats, organic meetings, and add people (and include history) as I want and desire. I prefer it for quick discussions with my colleagues and to get a rapid problem solving or critical incident conversation where I don't immediately know who I need / what it's about, and it'll scale as I add people. I push a button and talk to people, push a button to add people, push a button to video chat, all seamless.
* Slack is structured and formal and based around enterprise-created channels and workgroups, with way too much noise in each massive channel and way too little content that's even remotely relevant to me. Outside of channels, conversations are horribly gimped: A) I can only have one conversation with each set of people, I cannot simply rename a chat and have three different chats with same people around different topics B) If I add people to an existing conversation, it will create a new chat without history (this may have improved recently as I know we sent a TON of feedback to Slack admins). Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
I'm looking at some of the other comments, and it seems they have some weird gimped version of MS Teams. E.g.:
>>"Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel."
This... is how it works for me. I start a conversation with some people, then I add people, then I click "Call", then we all video call together, then we are done and keep typing in it, repeat as needed.
Weird!
In Slack, you can turn a group DM into a private channel and keep the history.
https://slack.com/help/articles/217555437-Convert-a-group-di...
Individuals can create Slack Channels (often too many channels). You can setup adhoc groups through DM and can add people to that group . You have the choice when adding people to a chat to block the history or give them full access to the history. At any point you can convert a adhoc group into a Channel and decide if it will be private or public. You can click to start a call or to start a zoom with those present in the group or channel. it's pretty seamless, too.
It sounds like the difference is your organization.
A lot of our presumed perspective and experience with tools is actually our experience with organizations and policies.
Conversely, majority of issues I've read here with Ms Teams, are not part of my own experience - Teams I use is way easier and more flexible and user friendly than the slack I use.
Is it the case that more startups used slack vs more enterprises used teams and that sealed in some stereotype?
> Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
> Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I'd say it's the other way round. Everywhere I've seen Jira, the person who can change the tool settings (e.g. make mandatory fields optional, add a transition to allow you to move a card to the column it should be in (because Jira is deny by default, you can only move things in ways that are specifically allowed) is a very distant part of the org chart from the team doing day to day work on it. "not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance" is exactly how I'd describe Jira, given how I've seen it used (across a great many organisations, large and small - indeed I'd say switching to Jira is the most reliable indicator that a previously fun company has grown too big and it's time to leave).
Some stuff is probably just typical managerial bullshit. But the fact that Jira defaults to working as a slow, drag-and-drop interface with no undo is absolutely an unforced error.
> Never has an anti-trust move been so obvious or damaging.
Atlassian buying Trello and gradually ruining it is worse than MS giving away crappy products for free.
My corporate jira gives me full control over the workflows, what fields are shown, etc
That's not a jira problem, it's an organisation problem
There's no way I could extract any usable metrics from my jira, but that's not its purpose. It can however tell me where we are with the new upgrades to Site 95 (waiting on the people running the fibres), or who wanted that new device in Site 5 and crucially why.
I've never read that sentence before!
My feeling is... developers hate Jira, managers love Jira. And that is expected. The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
An example of a very misused metric: In one of my jobs, managers started using Scrum Poker results as a productivity measure. “My team scored 100 points in the last sprint.” Imagine the chaos this generated. Quickly teams began to hate the Scrum poker.
Jira is probably just a scapegoat in corporate theater, something needs to be to blame. Jira is a good culprit.
There's an unfortunate tendency for some people to scoff at the immutable fact that to write software, you have to talk to other human beings. And that if a company is paying you good money to do it, they are going to want to know when it will be done and what ROI they are getting on your salary.
Sure, there are stupid meetings and stupid metrics. But to lump "meetings" and "metrics" into a "hated" category is the mark of an immature dev who doesn't understand why he/she has a job and a salary in the first place.
Of course there are terrible meetings too. I currently have a PM who had 5 meetings with me a week on two minor projects. I don't go to those meetings, I just update the jira when there's an update. I need to do that as I am working on 40 things at a time and I don't have the mental capacity to remember how many plates I'm spinning. That's far more efficient, it's asynchronous, easy to keep on top of.
I see some colleagues struggling to get anything done because they are in meetings 6 hours a day, they go from one meeting to another without even a pause for a break. In those meetings they then try to half-listen and send emails about other subjects. They don't need to be in those meetings.
If I didn't communicate, how else would I know where the problems are, or what other people are working on so I don't duplicate effort.
90% of my week is not in meetings though, and about 0% of my week is in business metrics (plenty of metrics on things like availability from monitoring systems, but nothing out of jira, because what's the point in trying to record metrics which nobody cares about)
To me, these things are normal occurrences in organizational theater. I ignore that. But after sitting in a few 12-hour meetings, participating in some metrics-based programming (MBP) and filling out 100 fields in a deployment request tool, I UNDERSTAND if someone hates this kind of thing, is not only 'immaturity'.
And I'm not try to change anything, my experience is that if we can convince those in charge to stop having unnecessary meetings or using metrics incorrectly, something worse will replace those things, like no meetings, but super micromanagement. ... because the nature of the organization that does these things is to continue doing them, in other ways.
I'm not totally sold on the whole points poker process though, but that could be a criticism of agile as a whole.
If it isn't in the 4 values and 12 principles, it's not required in Agile. If it isn't in the guide, it isn't required in Scrum.
My understanding of agile is give your developers the tools they want, the information they want, and the ability and incentive to communicate widely, quickly, and frequently however they want, and get out of the way. You have to devolve responsibility and accountability for meeting business goals down to the team level though, and that team has to act as one.
None of that has anything to do with "points poker process", or any process. Obviously everyone has a process, even solo developers working on their own hobby, but that process is "what works best".
The reality is that most developers don’t know what degree of organisation / visibility is required for it to even be tenable to do their job in the context of a wider organisation. ICs, and the experience of ICs, should certainly be taken into consideration when picking PM tooling, but it’s not a bad mark against an org to also take into consideration the very real needs of management, PMs, etc.
There are always going to be those people that will categorically associate management with ‘bad’ and I just simply cannot respect that opinion. It’s the equivalent of being mad at your parents for setting a bedtime. Some of the Jira hate definitely comes from people with that mindset.
Jira doesn't require those features. My workflow is "Ready, On Hold, In Progress, Done". It's a glorified task list with assignees, tagging, emails etc, that's corporate-wide -- no need to get random people to get accounts, everyone has one. All over our documentation and configs are references to "TKT-1234", which explains the background to a specific thing far more than an inline comment could.
It does the job just fine, I didn't need to jump through any hoops to get it working like that.
The alternate system engineers in other departments use is email. Tracking things in email is awful.
You can use Jira for far worse things, but that's not a problem with the tool, that's a problem with the culture.
I'm a developer and I like Jira. People who hate it are probably forced to use some bloated setups. We just use Kanban and the backlog and that's it. It's great if you don't turn it into a fully blow project management tool.
Which is absolutely not the fault of Jira. Jira does not make you create 20 boards and per default a Title is all you need to create a Ticket. By the complaints own wording they had 2000 tickets because management refused to delete outdated and irrelevant tickets.
A new tool would not fix this since I would bet that management would insist that all 20 boards with all tickets in the backlog would need to be transitioned to the new tool. The mandatory fields are obviously also highly important to management, those need to be configured in the new tool as well.
Instead of complaining about the obviously bad management they just complain about Jira. That is, I think, very common when complaining about jira.
I've used Jira (last job) and Linear (now). I don't really see any compelling reason that Linear is "better" than Jira. Jira was always pretty easy to use and navigate for me, and we had team-focused views for ourselves.
Even on this site, several opinions I looked at are about the idea of process or the implementation of a process—not really about Jira. And several of the ones about Jira just came off as whiny nitpicking and not actually meaningful.
Management didn't insist on that.
JIRA was a dramatic improvement at one point, however, it is bought and sold to managers, so it is unsurprising it eventually converges to managerial overengineering.
That is the root of the issue.
I've seen many small orgs adopt trello, slack, discord and other tools organically. I've rarely seen a small org willingly choose jira or teams; that is a choice that is almost always imposed by non-users of those tools.
Jira certainly seems to push people towards having a handful of manager users who are the only ones who can create boards/transitions or adjust which fields are mandatory, and this leads to bad behaviour - if only one VIP can create boards, they'll probably create 20 once and then never create another. "Title is all that's required" may be the default in some editions of Jira today but it certainly isn't widely used. And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have - there may be occasional use cases where you need e.g. an action that's impossible to undo, but it's an awful default.
We set up our Board and Workflow fairly minimal. Which is probably why I don't have any problems with Jira.
> And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have
What do you mean by that? The default Workflow in Jira is that all Issues can transition into any status.
The default workflow in some newer editions has a transition that allows that yes. But custom workflows don't have those transitions unless and until an admin manually adds them. If the person who set up the workflow didn't think of some edge case, you're SOL.
Sounds to me like you probably never edited the Jira workflows yourself. If it takes your company more then an hour to change a workflow then that is a decision to artificially limit things.
Also: Custom workflows start with with the "Any" transition on all states and when adding a new status it also has the "Any" transition. If that is different in your workflows then that is a deliberate decision.
I've never been able to edit the workflow, except at one company where I had access to the "beta" Jira but not the "real" one. This is across, like, five or six different companies - again, if it were one company I'd say it's a bad decision by that company, but the fact that it's so consistently done this way tells me it's something about the tool.
> Also: Custom workflows start with with the "Any" transition on all states and when adding a new status it also has the "Any" transition. If that is different in your workflows then that is a deliberate decision.
Wasn't the case as recently as 2020 (the last time I had access to create my own custom workflow, and I'm pretty sure that was a newer version of Jira than many large companies are using). Are you using the cloud version or something?
What I wanted to get across is that Jira makes it very easy to give control to the Team that is using a specific Board or Workflow. If your company don't trust their Teams with that then that is a failure of the company and not a failure of Jira.
The dopamine hit from tweaking charts and organizing digital clutter is probably the same area of the brain where the social media infinite scroll dopamine hit happens. If JIRA the product didn’t offer all these dopamine hits for doing busy-work, aka “features”, and stuck to basics then people wouldn’t be complaining about the tool and how their management/admins have implemented some nonsensical process.
You're kind of missing the problem here - it's both and neither. It's not the tool (it's awful) or the mid-to-large org itself, it's the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
If people just treated it as a "necessary evil" time-tracking type system to make sure people were really working when they said they were, that would be irritating but not damaging. But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
You’re conflating ticketing systems with work estimation.
The background to this is : yes it can. I worked in organizations (long pre-Jira) where we developed the bug/ticketing system specifically to drive our development management process. The two evolved in concert. The result was excellent, and sadly has never been re-achieved with any of the modern tools.
My take on this is that somebody was told that the bug system can be used to drive project management (which it can) but then implemented a bug system without any real understanding of what that means or how to achieve it.
- Airtable
- A giant board on Miro.com with a bunch of notes in frames
Of course the scaling needs are different whether it’s for just a single team or if the data needs to be aggregated into some KPI. In my experience it’s better to keep KPI publishing separate from task tracking, though
The irony here is that those simple trackers scale a lot better. Jira's complexity is part of why it scales poorly - it's really bad when you have 500 people trying to use it.
1. It's too configurable. It's like the company wiki. People come in, set up some random projects, processes, fields, statuses, etc. and then move on. There's rarely someone making it all consistent and sensible. This results in task statuses that can be TODO, BACKLOG, PENDING, WAITING, TO DO, etc. etc. etc. You also end up with waaaay too many fields for tasks. Arbitrary distinctions between "Tasks" and "Stories", etc. You're at the mercy of your Jira admin who will definitely make worse decisions than e.g. the developers of Phabricator or Gitlab. Hiding useful fields, adding pointless ones, etc.
2. Despite being super configurable, it can't do some really basic things you'd expect from something whose sole job is task tracking. For example you can only parent tasks 2 or 3 levels deep. A task can't have two parents. Subtasks can't be in different sprints. You can't reorder tasks by priority in the backlog.
3. Most offensively it is just incredibly slow. The main way you add tasks to a sprint is drag and drop on the backlog, but it performs so badly (100% CPU all the time) that they've had to add context menu options to move tasks to the top/bottom or to a sprint. I believe there's also an option to disable animations. A simple web page should not consume 100% of my CPU.
It's by far the worst issue tracker I've ever used.
Companies still pay for it though because PMs love the pretty burndown charts and being able to add a gazillion fields to tasks. How will they report project status to their bosses if they can't have Jira work out the exact-to-the-second estimated delivery time automatically? And by "automatically" I mean by making someone else do all the work.
"Confluence is where information goes to die"
Even a small drag'n'drop resulted a vast amount of computer power grinding away.
CCM is so bad it’s nearly dysfunctional. Image Jira but 3 times the necessary clicks (this is not hyperbole).
With Jira I can see the good intentions and how they go awry. But CCM is pure madness from top to bottom.
Which were ignored because everyone found it easier to just read and search the comments. So a thick chunk of commenting became de facto mandatory.
The truth is, if someone wants a time estimate, just do that and don’t beat around the bush. It’s too much effort to still be wrong.
Unfortunately in any medium-to-large org, there are a non-zero number of morons.
I used to work in a largish public company (40K+ people). They had a wonderfully functional and flexible bug tracking system.
So no, at least in my experience one can be in a large org and enjoy your bug tracking tool, nothing to do with the overhead of a large org.
But jira, it is beyond awful.
The current era really overestimates the benefit of using third-party cookie cutter tools. Yes they save on development cost of course. But you're stuck with something that has a million complexities you don't need and that is mostly terrible for everyone. So you pay in an infinite stream of small annoyances which add up.
There's a lot of value in building in-house tools targeted to work exactly like your team works with zero extra complexity.
And look at all the years-and-years-and-years-old jira feature requests that atlassian never bothers to implement and you have to suffer with mediocre workarounds. With an in-house tool you change it in an afternoon to do exactly what you need.
It's not for every company but companies of enough size to support building in-house tools should really give it more consideration.
Atlassian desperately needs to pause on new acquisitions and new features for at least two years and rework all of the products they acquired and unify them. Literally every Atlassian product offering has a different way of doing things, no consistency anywhere. Oh, and half of the functionality has no API, and there is no first party Terraform provider so you have to do everything by hand every fucking time.
The abusive workflow bullshit by clueless middle managers is another problem in itself, thankfully I'm in the lucky position to tell people "no, we won't do that".
DC (and formerly Server edition) are pretty good products that do their thing fine and are fast enough for typical use. Unfortunately, Server edition was discontinued and DC is too expensive, so formerly happy developers are forced to switch to Cloud edition, which is horrendously slow. Jira Cloud also lacks some loved features, such as the plaintext comment editor [0].
It seems to me these tools should be optimized for the majority of their users (developers) and if the PMs need pretty graphs and someone else wants it all in a spreadsheet (OMFG) they could use any of a hundred integrations to extract the data and generate those without more effort than wrangling Jira.
Shit, lots of places are already paying for GH or Gitlab (or self-hosting the latter). They just don’t use that part and instead also pay for Jira or Asana or ADO or whatever productivity-murdering junk-drawer-where-information-gets-lost garbage.
If JIRA at least had rational design underlaying poor implementation, it would give some reason to bear and hope. Instead, it is an infinite fractal of nope, the likes of which you hardly encounter outside government contract projects.
We were forced to get off of Phabricator because it was abandoned, but JIRA was still a downgrade in every way. Linear will eat JIRAs lunch and in a decade, it's going to go the way of HipChat as the thing that everyone used but nobody talks about.
That compounds any corporate-inflicted issues.
I was thinking maybe I could help, that some hated software was something I myself had used at some point. But I have never used Jira. When I investigated what Jira was, I had the same thought: I thought that in this case the software is probably only part of the problem.
That’s stupid and a flaw in teams. It’s a bad messaging app. It’s pretty good with meetings though.
that's pretty damning ...
The best work around I’ve found is to have my phone nearby and use it for notifications.
Seems pretty silly for a messaging app to work so poorly.
Something like slack really feels good and intuitive to use. It had to be to make it on its own from nothing. Most alternatives for MS products and services are much better, simply because they have to be, they don't have the installed base to coast on.
With teams it feels like it's mainly chosen because it comes with O365 subscriptions for free anyway and it's not bad enough to justify paying separately for a better product. In fact most Microsoft products have this strong feeling about them. The same with Windows, Office, Yammer, Sharepoint, Edge.. It's not great experiences for the end users, though for the IT guys it's all pretty handy because of the integration. It's that feeling of missed opportunity, that it could actually have been great if someone had cared.
I think part of this is the failure of MS leadership to set a customer-centric vision. There seems to be a lot of infighting within business units. For example, they started out ok with Edge (even though it was just a chrome ripoff) but then some low-level exec had to go and enshittify it with coupon ads and loan schemes to inflate their own department's KPIs, but totally undermining the product and company as a whole. This is really something that a company with a strong vision wouldn't permit.
Teams also have some very nice things going for it with it's Office 365 integration, but as a chat app it's just way more buggy than it should.
I assume they're both doing something unfriendly that Firefox disallows on privacy or security grounds.
Allowing third-party cookies solved my problem (but create others, of course).
That's why it's annoying really, that it isn't just not functional (or some specific feature doesn't work) unless you disable some built-in default safeguard say, it just completely refuses if it identities your browser is Firefox. Which I'm pretty sure is nonsense. Well, Jitsi, Slack, Discord, Zoom don't have a problem implementing chat & video conferencing in FF.
But they pushed out a new version recently. Now you've got Teams Classic and Teams NEW (work or school)... at least on the Mac.
It's sooo much better. Way more stable. Search is a delight (relatively speaking). We get far fewer complaints now.
Worth mentioning: We only use the "Chat" aspect, we don't use the "Teams" aspect. If we want to discuss a project, we just spin up a new chat with relevant parties and rename the channel to the project. Works great. We could never get "buy in" on the Teams aspect, nor threaded discussions. The main reasoning was having to monitor two tabs in the product. Everyone just wanted to stay on the Chat tab, so we made it work.
This part I struggle with, and maybe we're doing it wrong, but to me as a PM, this way is painful.
Search helps. But then I have to remember, "Was discussion about X in the chat with people A + B + C, or was it in A + B + D's chat, or B + D's chat, or..."
We also have significant challenges with knowledge silos (not intentional, and more about a cadre of new devs being brought on) that (not the only solution) I feel that pushing conversations to specific teams when appropriate might help, improving visibility.
So, let's sum up my personal gripes (on a Mac):
1. Teams keeps locking up the dGPU for whatever reason randomly after calls, draining the battery and grilling my legs until I figure out that Teams has gone nuts again.
2. Since the macOS Sonoma update and the switch to the "new" Teams client, every time a call comes in, the ringtone glitches out (and I'm not alone in that)
3. There are three different ways of chatting with other people: Meeting chats and direct/group messages (these are summed up under the "chat" tab) and "teams" with "channels". The latter don't produce instant notifications when someone writes there, I guess because Microsoft doesn't want to deal with "I get an instant notification every time someone posts a kitten photo in the off-topic channel" complaints.
4. There is only one uploaded-files repository which means if you have a "screenshot.jpg" sent to someone, and you try to send a different file with the same name in a different chat, it will say "you already uploaded screenshot.jpg, do you want to replace this?". This is fucking bad UX, likely caused by Teams using OneDrive under the hood to share files.
5. The search is slooooow as molasses and damn useless. You have zero chance of ever finding something again, the larger the org the worse the pain.
6. No window/functionality remembers your context when you switch away. Say you click on a notification from a chat because a colleague needs an urgent answer, while you're scrolling in a team thread... you go back, and your scroll position is lost.
The .deb of the stand-alone package disappeared, so it seemed we were stuck with the pain of the browser-based stuff. Then I remembered archive.org and found the .deb. If anyone else is in a similar situation, it's at https://web.archive.org/web/20221130115842/https://packages.... Thanks, archive.org
Also the ux is pretty bad.
Jira is just the tool management chooses because nobody-got-fired-for-buying-jira.