JIRA is the only support tool for Atlassian Confluence users
October 24, 2017

JIRA is the only support tool for Atlassian Confluence users

Anonymous | TrustRadius Reviewer
Score 4 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with JIRA Software

JIRA was used to document differences between a desired specification and a delivered prototype. The organization being small, it was used by everyone. It was intended to be a single tool to characterize issue reports, compile bugs, author work orders & track progress for a web-based application tracking various aspects of building management & efficiencies.
  • Integrates well with Atlassian's other products including Confluence wiki - this is essential since there are always reports, research & knowledge outside the scope of the bug reporting or support tool, and a general purpose wiki is absolutely necessary to compile this effectively.
  • Produces reports about a particular release's deficiencies, when those can be characterized well enough by reporting users - essentially serving as a link between support people & developers, which is central to support-driven development, and necessary for DevOps integration between developers and sysops (where those are different people, which in a successful org, they would be)..
  • Exports data well enough to standard output formats & notification systems.
  • JIRA is part of a silo with Atlassian's other tools, like Confluence wiki. Just as Microsoft tools integrate tightly with its Sharepoint knowledge base (it's not a "wiki" in my opinion), Atlassian's form a stack that essentially requires one to use Confluence. Meanwhile if you are using the far more common & supported MediaWiki, you will find that for various reasons it is wiser to use Phabricator, the Facebook/WikiMediaFoundation bug reporting tool (competitor to JIRA) since the largest users of PHP-based mediawiki are also using that, and integrate them more over time. If JIRA wishes to compete for users who are relying on SharePoint & MediaWiki, who very much outnumber Confluence users, it will have to support those knowledge management / CMS / wiki systems as peers, and will have to restrict the degree to which it favors Confluence else it will be too great a business risk to rely on JIRA when using a non-Atlassian CMS or wiki.
  • JIRA does not provide much direct support for support-driven development (SDD); that is, when one is specifying a new product entirely, with desired (not real yet) fictional features, JIRA would have some trouble characterizing this correctly. Yet for SDD it's critical to be able to represent a specification of desired behavior even when there is no running code that attempts to implement it, else there will always be a gap between a specifying tool and a support tool. JIRA developers would have to make a conscious decision to support "revision 0" of software; that is, its specification without any working artifact, and with only proposed URIs or command verbs, keeping these mutable so that potential support problems were found in the specification stage, and there was NO gap between tools used for revision 0 versus revision 0.1 to 0.9 to 1.0, only a difference in audience.
  • Mobile & responsive support is weak - when a problem is reported it should be relatively easy to filter who gets which reports, and those should be sent through confidential means like XMPP or Signal, rather than relying on proprietary services such as social media (major security problem).
  • JIRA was not the appropriate software for us as we required a support-driven development style of tool that could be used to specify or propose MVP (minimum viable product) before actually specifying in depth. We were also using MediaWiki as our CMS so ultimately shifted to Phabricator, for which we could find vast support for use with MediaWiki & PHP-based apps like WordPress (our delivery platform). However, JIRA did discipline the collection of feedback about an early prototype, sufficient to convince us to change our direction, so was useful there.
  • Any support tool is only as useful as the next release that it helps to specify. A moderate effort applied in JIRA was enough to identify the most useful development goals for the next release, and it was probably helpful to have a very disciplined framework to characterize the problems. We found however we could use that structure without the restrictions applied by JIRA itself, i.e. adopt its terms for things where appropriate, within the more flexible Semantic Bundle extension framework of MediaWiki, which is far more capable of "web 3.0" sorts of integration.
  • It was useful to identify that stacks or silos were essentially so interdependent vertically that we did not want to depart from what other PHP-based open source platforms were using, while we were delivering within that world. We avoided making any investment in SharePoint as a result, and focused clearly on Phabricator, and that was beneficial.
Phabricator is the only comparable tool I have used recently. It was designed to integrate with PHP-based projects specifically (Facebook, MediaWiki, WordPress) which are today the most diverse (WordPress) & highest volume (Facebook) & flexible (MediaWiki) online services in the world. It was relatively unpolished compared to JIRA when we selected JIRA. This was influenced by recommendation of another development manager who was already using it.

JIRA is the best tool for supporting an already-deployed application where the specification & support & business knowledge surrounding it is already managed in Atlassian Confluence.

If another CMS is in use, JIRA should be questioned as the choice. If Sharepoint is used, there are Microsoft tools that are probably more appropriate. If MediaWiki is used, open source Phabricator, the support tool used by Facebook (who wrote it) and WikiMedia Foundation (who maintains MediaWiki) would definitely be more appropriate.

Using JIRA Software

4 - CEO, CTO, senior user interface developer, project manager. Essentially everyone involved in quality control & user experience & support for a pre-released product for real estate / building data management.
1 - Anyone familiar with Atlassian Confluence wiki & its underlying toolset can support JIRA. These tools should be used together though there are lesser functional CMS available that support JIRA.
  • Extend Atlassian Confluence wiki to provide support services to end users with expert backup & escalation, including users of Confluence implementations themselves or potentially other CMS.
  • Characterize prototypes' issues & flaws for purposes of redesign, negotiation or MVP definition.
  • Provide a common vocabulary to discuss support problems.
  • Identify a weak business case for an initial product that led to discovering a more appropriate MVP.
  • Train developers & executives who would have to double as support staff in support priorities & problems.
  • Adapt a vocabulary of support & issue management for more flexible use within semantic web based CMS.
  • Report analyses of already-delivered products to clients & customers already using Confluence or other Atlassian tools, in the form most integrated with it.
  • Recommend it to entities with no CMS to determine if they need minimal, open or proprietary CMS capabilities, and to determine if they can discipline their proposed specification in JIRA form.
  • Hopefully, when it has better support for proposed (not released) product problems, use as initial specification tool, so that support can use exactly the same tool used to specify a release.
While there are no fundamental problems with JIRA, I'm unsure that I will be working myself very closely with users of Atlassian Confluence. The client base I am concerned with tend to be more integrated with Amazon, IBM BlueMix / Watson, open source LAMP/PHP (WordPress, MediaWiki) & those that rely on more proprietary CMS would tend to use Sharepoint not Confluence. JIRA seems to me to stand or fall with the rest of the Atlassian silo or suite, as it is not closely integrated with Sharepoint or mediawiki based reporting or knowledge management. Data interchange standards in this area are weak so Microsoft, open source LAMP projects using Phabricator, and Atlassian JIRA seem to be three distinct silos, with Amazon, Google & IBM offering their own tools for similar needs.

Evaluating JIRA Software and Competitors

Yes - We were using MediaWiki for reporting bugs & managing specifications. At a certain point its lack of specific discipline for issue reporting become a seeming problem so we compiled our issue reports in JIRA in an independent process. This was not due to any deficiency in our CMS but rather a lack of experience in characterizing releases, issues & bugs in that free form. JIRA's discipline was helpful though we eventually returned to using a combination of MediaWiki and a more PHP-focused tool, Phabricator, for this need.
  • Product Reputation
  • Third-party Reviews
A development manager was familiar with JIRA and Phabricator was very new and had not been closely integrated with MediaWiki. We were considering Confluence or another CMS & if JIRA had provided any extreme advantage we might have considered doing projects in it, leaving MediaWiki in its general research role, which it had for a decade prior to this project.
A development and issue support tool like JIRA must be extremely closely integrated with a CMS. There is no point explaining things inside JIRA, they absolutely must be linked to CMS pages. Not being able to use [[mediawiki link notation]] within JIRA was crippling to us.

JIRA's integration with Confluence is better, but we didn't realize it really has to be implemented as Confluence first, JIRA second, in order to get any integration advantage. To have to rewrite every scrap of text in every field in JIRA manually to refer to the linked pages that specify the desired behavior in the wiki, really isn't a practical approach at all.