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.
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.
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.
> 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?
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.
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
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.
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.
And they are replacing it with JIRA Cloud that cannot be configured at all, and is unbearably slow.
I am not normally a "less features is more" kind of person. But with issue tracking, I am.
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.
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?
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".
* 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)
To me this is the main point of storing issues in git!
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?
(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.)
It's a losing battle between tool functionality and reporting abilities.
- 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.
* 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.
I'll check out Linear. Been looking at Clubhouse too.
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.
We tried dozens and I've put it down as an unsolved problem.
The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
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.
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.
Has the "Sprint" link always been on the bottom of the rightmost column?
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.
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.
It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
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.
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.
A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.
The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value.
But, in either case, not having that realization is management issue, not a tool vendor issue.
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.
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.
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.
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.
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).