[quacked]

Completely agree. Jira theoretically could be used to be good, but it's an absolute nightmare to use. Totally inconsistent and muddled UX. Awful graphic design. Worst of all, completely bugged-out word processing, which is the entire point of Jira

[gjvc]

the fact that the wysiswyg text editors are not the same between Atlassian products was the giveaway sign to me. They are clearly shipping the org chart, like everyone else.

[dbbk]

The editors are not even the same between screens in the same product. The task description field uses one editor for the Create Task screen, and a different editor for the Edit Task screen.

[quacked]

I hate them, but I almost can't blame the devs. It's extremely difficult to ship anything today at scale without justifying it to extreme growth-focused investors. I bet every single time someone has the chance to say "no, let's slow down and refine this", someone else points to the revenue and contract targets and hits "deploy".

[digitalsushi]

I'm not defending Jira but I heard someone once say that Jira is ugly cause it's a mirror and you're a corporate process

[quacked]

That is extremely true, but I think it's ugly on a screen-to-screen basis. Random text justification, no distinction between editable and non-editable text, various shades of boring/corporate off-white to distinguish sections of the screen, and literal bugs in the software, like you make a table and then when you save the ticket it changes your lower 5 rows to columns in a single row.

[axlee]

What's your preferred alternative for medium to large teams?

[quacked]

That is a good question. It depends on the circumstances and whether or not you're doing highly-regulated and auditable work (medical software, spaceflight databases) or more improvisational free-market stuff (video games, non-essential chat platforms).

Overall, I think my preferred method is to deliberately choose to implement about 15% of Jira's possible functionality but also rigorously define how that functionality can be used used so it's consistent across your entire organization. For instance, Jira has release versions, fix versions, labels, ticket types, summaries, custom fields, etc. However, most of those are really just "other ways to slice the data"., and total freedom allows people to create non-set-complete ways to slice data.

As an example, let's say that I have a list of 400 things--bicycle, pear, jar, cassette tape, ennui, Aristotle, 2. Our Chief Philosophy Officer wants to be notified on any tickets pertaining to philosophy, so he tells our division to tag all philosophy-related tickets as "philosophy" and then starts assigning his own grad students to analyze them.

Well, we just added the "philosophy" tag, implying "a type of label that discusses the academic content of the ticket". Do we have other tags that fit into that label type, like "history" and "science"? Where's the list of possible entries of that tag type? Where's the list of all tag types? Where's the list of all possible tags? What do they mean? Where are they defined? When do I use them? No one knows, because no one has the authority to know, we just keep growing and shipping or else we get the hose again.

By solving a momentary problem--Chief Philosophy Officer wants a set of tickets to look at--we have invented yet another fractious method for looking at an incomplete set of tickets that doesn't actually apply to every ticket, and our Jira ecosystem gets more unwieldy and less complete.

I would instead prefer to either turn the ticket tagging feature off entirely, or I would prefer that the Chief Philosophy Officer not get to dictate what tags are created and instead go through the Tagging Authority Team, which dictates what tags exist, how they can be used, and ensures that all tickets are sortable and categorizable, and well-defined, and self-consistent, and set-complete, and also they version their definitions so you know if a ticket was created under v1.0 of the Jira best-use architecture or under v3.6.

That's why I mentioned earlier that it depends whether or not your team is doing something highly regulated. Anyone who's gone through a detailed software audit from a governing body is thinking either "yeah, we had to deal with this problem" or "man, I should fix our tags". Anyone who can just bang out release versions on any schedule serving any customer would think "that is a ridiculously stupid waste of time, I love tagging anything and forgetting about it, because I only need to worry about the feature for X weeks before we're on to the next thing".