5 ms·
OK, so what don't I like about Jira? 1. It's extremely slow. 2. It's difficult to predict the effect of making any kind of change. 3. The permissions system
by blowski 4y ago
OK, so what don't I like about Jira?
1. It's extremely slow.
2. It's difficult to predict the effect of making any kind of change.
3. The permissions system is so convoluted, I can be the admin of a board, and yet not have permission to see a ticket on it.
4. It relegates the conversation to a second-class UI element, when this is the most important part of any project management system.
5. Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time.
6. Every Jira setup is so different, trying to compare a piece of work from one area of the organisation to a similar piece of work elsewhere is useless.
7. The UI is extremely buggy. I can add a mandatory field to a ticket, then when I try to use a shortcut to create a new ticket, it won't work because I can't fill out that mandatory field.
8. There are random side-effects when one person does something on one bit of the system, and VOILA everybody's workflow is broken, with no obvious warning that would happen.
- devoutsalsa 4y agoI still can’t figure out how to search it
- sophacles 4y agoThis is a solved problem. The most efficient way to search Jira is to type random characters into the search bar until you find the ticket you were looking for on page 3 of the results.
- exyi 4y agoI just wrote the search query to our PM, since I was unable to find anything myself... I don't understand why just couldn't use, IDK, a shared spreadsheet, even that would be more productive (from my perspective)
- cuteboy19 4y agoFind the person in your organization who knows JIRA. After he doesn't manage to find it, open outlook and search for it in the notifications@jira folder, where you would most likely find it
- meibo 4y ago9. The text editor is still busted and I just don't understand why. It's one of the most important parts of the UX, please please fix it. Writing any kind of nicely formatted long form posts is a lost cause.
- macintux 4y agoAt the very least, use the same markup language for both Confluence and Jira.
- yamadapc 4y agoJira/Confluence Cloud use the same markup and editor.
- eikenberry 4y agoBut neither supports a markup language AFAIK. They used to support Markdown but they dropped that long ago and never replaced it. Now the only choice is their garbage WYSIWYG editor.
- VectorLock 4y agoJira isn't great but the Confluence editor causes me more frustration than anything. And good luck getting anything in or out of Confluence with their document model.
- eikenberry 4y agoConfluence is definitely their worst product. It's like they took the idea of a Wiki, but removed all it's good aspects and then combined it with a terrible CMS system. A competitor could just use an ancient WikiWikiWeb installation and be better.
- jedberg 4y agoAmusingly, it used to be great! When I first started using JIRA, it was just markdown. Then they introduced their WYSIWYG editor, but at least they still had the button to see the raw markdown and you could still edit the raw markdown (but the GUI made terrible markdown so if you wanted to use markdown you better start with that and never touch the GUI). And then I guess at some point they just removed the markdown part?
- slaymaker1907 4y agoIn defense of complex permissions, this often ends up being necessary to avoid single points of failure. For example, if someone can turn off the setting preventing force push to the master/main branch, that person should not be able to commit code thereby requiring more than one person for a commit to be force pushed in practice. Even better would be to require a config change like that to be approved by more than one person, but that can be difficult to implement compared to adding in narrow permissions. Even if you just prevent force pushing in general, another common bypass would be disabling CI for certain commits (such as in cases where the CI infrastructure is down and the commit is necessary to fix some ongoing incident). Yes trusting developers is always going to be necessary to some degree, but that doesn't mean absolute trust is required all the time. For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).
- blowski 4y agoThat's the thing about Jira. I don't understand why I can't see a ticket on my board because some team in another company once requested a seemingly unrelated feature. It's trying to be too many things to too many companies all at the same time, and thus ends up as an unusable mess of complex settings.
- rsanek 4y ago> Trying to operate on a bunch of tickets all at the same time (e.g. move all tickets in this status into some other status) requires a lot of time. Have you used the bulk issue change tool? The UI isn't necessarily very user-friendly but I would not label it as requiring a lot of time, I actually feel it works quite well for this use case.
- bamboozled 4y agoAwesome list and objective. I'd like to add another point: #. There are too many "views" or ways of visualizing the work that needs to be done, ie the plan view and the kanban view, my issues etc. If I'm not looking at the 'right' view I'll miss something and maybe get in trouble from project management.