231–240 of 530 posts
Co-founder of Zepel.io [0] here. Thank you for giving Zepel a shoutout in the Jira alternatives section of the landing page. Would love to get feedback from the community regarding our App. [0]: https://zepel.io/
There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…
My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management.
How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.
There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone , but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all ? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, b…
> Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products
https://www.atlassian.com/legal/cloud-terms-of-service
JIRA sucks
I am reading this comment thread and honestly I don't know that I agree. I think JIRA, like most tools, is as good or bad as you make it. I've been at numerous companies using JIRA that don't seem to have most of the issues referenced here. The only thing I've ever felt like JIRA really lacked in was in a good UX for embedding code snippets or other technical details into issue comments. Native support for Markdown i…
There are three problems I notice with JIRA, of which two are entirely the product's fault. The first one you already mentioned: abysmal speed. The second is how JIRA forces certain ways of working which are clunky or intuitive (or by extension, out-of-the-box workflows are difficult to change). The biggest problem I have, by far, is just how easy it is to create bureaucracy-intense workflows in JIRA and make managem…
that's mostly down to the current JIRA configuration, same with the workflows used. One thing that I found great at my current office was letting the team configure their Jira projects as they wanted
Earlier quoted context omitted.
> Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. Sorry but what? You might need to expand on this. As far as I'm concerned, when a bug is fixed then the value of that fix is realised by the users. I don't see how this is not valuable just because you manager didn't get to eye…
Elaborating on your point. When has JIRA actually been effective as the documentation for a bugfix? JIRA in its most effective will just tell you whether we agreed to do this work and the state the work is in. It is not "documentation."
It's a shitty documentation system because it's extremely hard to find that organically, but people do use Jira as documentation.
Completely misses the point. The reasons why JIRA sucks are: 1. It is slow
I remember 10+ years ago jira had straightforward tables, it was much quicker to add, remove, close issues. I’d open a bookmark to a page with a simple table listing of all issues assigned to me.
I don’t know what the heck is going on, now the ui is this awful "modern clean" style with popups everywhere, sidebars, everytime i look at an issue it’s cramped in a tiny column, or i have to open in a new page. The whole ui is so slow and clunky, you have to expand/collapse content all 5he time. All in the name of what? Is scrolling down a page so difficult for a user? How does Amazon make money?
To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with technical details, I probably spam the whole team with lots of "Ticket was edited" notifications because there is no logic to Atlassian's markup systems.
I feel that Jira's configurability makes it like desktop Linux 20 years ago. Everybody swears it's rock-solid, beautiful, and easy to configure. Then when you ask anyone to have a look at their specific setup, they'll cover the screen with their bodies and panic, "ah no, I kind of messed everything up recently, haha, but you can't really blame the software for that, can you? Everyone else's installation is super clean though". After working with ~10 different Jira installations, I'm still looking for one where that's true.
And as someone who enjoys documenting their own work for fellow developers and other roles, I don't even think Jira helps. Most discussions will still happen offline and without documentation, especially from non-technical roles who hate typing.
Earlier quoted context omitted.
It depends on your organisation size and structure, but probably you want to run the bug fix through some triage first (meh management overhead, but needed if you have many bugs to make sure the "important" ones are fixed), then code review (well, that doesn't happen in jira, but probably should be (automatically) reflected there to have one place to look later) and after fixing probably should be routed to the docum…
I think you might be missing another dimension, in that it depends on the size and type of bug. "See a problem fix a problem" is a common mantra in physical work type environments I've been in. You don't wait for a manager to tell you to pick up a debris that's fallen in a forklift path. You clean it up. This doesn't quite translate as well to software, you certainly don't just want to make production code changes wi…
Of course a typo fix in a comment (to find something even more trivial than your VM example) doesn't need a process. But that's also not what I'd call a bug.
Earlier quoted context omitted.
> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it. Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to revi…
I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket. With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug…
I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now.
> I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets).
In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it.
But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.