Hello everyone,,
I've been comparing different systems for a few months in order to build a project management system. Jira core stuck out to me for a) the ease of customisation and b) cost. Their use of Java is the only big red flag for me
[Spam content removed]
thank you to all. I knew I could find healthy discussions/responses here.
my original reply was misplaced when this issue was moved making it appear that I agreed with this post. which I don't FWIW.
here is my original response - Agree. It would be interesting to see an objective statistical analysis comparing all of the top issue tracking and project management SW.
At the risk of getting my atlassian card revoked...
Native Jira is less "Full Featured" then a lot of competing products. It has a limited set of core features. They make up for this be having a rich 3rd party marketplace of apps/addons etc that you can use to add additional features or customization to make it do a whole lot more. (and a framework that makes it easy to create and use these addons.)
But for some people who have just bought Jira, finding out they have to then buy an add-on to make it do X is a source of frustration. Never mind that it was half the cost of the competitors product (which should leave extra funds for add-on purchases), it still more money then was probably initially allocated.
Experienced jira admins know that you will need to purchase addons, so they include that in the costs.
JIRA also has a number of bugs/feature requests that have been outstanding for many years, which leads people to feel like they don't care about their customers. Its probably no different then their competitors, but because Jira is so transparent with their public Jira instance it is very easy to see these issues vs others that may not make thier bug trackers/development roadmaps as easy to view.
Why are there two such similar posts in such a short time?
Could be spam.
given you have opened the discussion maybe you could chime back in here as to your goal, your thoughts, etc. if you are no longer interested in this discussion please convey that.
Disliked by who, for what?
Often people get bugged when something isn't optimized for their personal constitiency. Or, "it's not natively exactly what I'm used to."
For example lots of statuses; lots of characteristics; lots of promotion transitions, all good for informing people looking to resolve in detail. In oversight in contrast, I like no more than:
That and a unique, stable name is all I need for status tracking. Indeed, more is in the way vs. helpful. (You do want to complement with definitions, stored somewhere else, like Confluence. So, in "Backlog" no telling when it will be done; no estimates. "Know it's done" also means "available for consumption" like, in your release-candidate build or branch.
In contrast, if I'm looking to do audit or process refinement, I want each time it's touched or changed somewhere I can find, plus aggregates in those terms. If I'm doing the resolving, I want all the context I can get.
The key is a common domain entity model of what's in your world: issues, states, things you wrangle (hardware components), roll-ups of collected work (projects, releases, epics). On top of that: