Confluence integration

[Matt Jones]

It would be really good if the same Confluence integration that exists in JIRA was reflected in JIRA Product Discovery. 

At the moment we just add URLs to comments or insights but would be better if all the supporting docs were visible against the ticket itself like Linked Issues.

[Ian Sperry]

I second this. I appreciate that functionality in Jira Software Projects

[Rohan Swami]

Thanks for the feedback @Matt Jones @Ian Sperry !

How would this help you? What's the problem with putting the URLs in comments, custom fields or in the idea description?

[Matt Jones]

Visibility - having them surfaced directly on the top level of the ticket makes them more accessible and visible to anyone viewing the ticket rather than having them embedded in comments/insights. 

Allows for adding multiple confluence docs easily and having them stacked neatly in the ticket. Using custom fields would be unwieldy. We have multiple Confluence templates that get populated as part of Discovery (System Design, RACI etc.) and so being able to stack them in the ticket provides a clear view of these docs.

Status updates - get the benefit of seeing when the linked doc was last updated etc.

Consistency - making it consistent with JIRA makes it more likely to be used consistently.

[Ian Sperry]

I agree with everything Matt said. But to add my two cents.

Confluence pages can provide necessary context or additional content. Jira cards are great but they are not great for lengthy content. 

As for "What's the problem with putting the URLs in comments, custom fields, or in the idea description?" 

1. All of these require one to remember to navigate to the idea and manually paste the link. This is not only a burden but in larger teams, it is increasingly difficult to get each person to follow through on best practices. Especially if they are already familiar with such behavior from using JS. As a manager, I don't want to spend my time chasing down people to add their links. The JS backlinking is automatic
2. As for comments. Those can get buried under other comments.
3. Custom fields, the Link type at least, only allow for one link at a time. It becomes "unwieldy" as Matt said.
   
4. As for the description. sure that doesn't have the same issues that comment or custom fields have. But it is still manual as my first point explains and it is less visible and less standardized than the functionality we are requesting.

On a separate note, I have sensed resistance in some of the JP team's responses to porting over Jira Software functionality into JP when users post in this community about these issues. I don't know if that is due to technical effort or if it is strategic or just personal ideology.

Frankly, I found it troubling to learn that the JP team doesn't even use Jira Software to manage delivery and development. Especially since I am sure Atlassian's goal is for customers to use all of their products together and to maximize the value of doing so. It would be a bit like learning that the entire org actually uses Github or Gitlab instead of Bitbucket or the entire Microsoft Teams unit works out of Gsuite and slack - it would not inspire a lot of confidence in us as customers. (Who knows maybe you don't use your own products for fear of eschewing discovery and being tempted to build a product entirely based on your orgs needs and not customers.)

Okay now i need to go back to my regular job

[Rohan Swami]

Thanks for the context and detail, folks!

For context, we ask questions like this so that we can deeply understand what the underlying pain point is for you. With our limited resources, we need to work out what's causing the most pain and prioritise accordingly. We could spend all our time copying over Jira Software functionality but then we wouldn't build anything Discovery-specific and you'd be even more unhappy!

And for reference, our teams do use Jira Software for delivery and development ... with a lot of Jira Product Discovery sprinkled in!

[Thorsten Kamann]

Hello,

I started with JPD recently and miss the Confluence integration a lot.

We are using Confluence to specify features and link then Epics and User Stories to observe what is needed to do to deliver the feature.

JPD fits perfectly to discover new features, but we don't want to use the description field of the idea, for some reason:

- limited editing capabilities (we use colored tables, that isn't supported in Jira)

- no collaborative editing

- sometimes it's happened that two people editing the same ticket and overwrite the changes of each other

These are 3 reason why we prefer Confluence to specify features. Additionally we use this specifications document to manage acceptance testing, and it is used for our technical writers to create the user documentation.

[Simon M]

Same problem here in my company. 

We started moving our initial confluence pages into the description fields of JPD, but soon realized all the limitations you mentioned. I would add the page history which is also very important and missing (the "History" section of JPD is almost impossible to read for complex Descriptions).

Our existing workaround is to include the confluence link as Embed

 

Which does not look too bad in reading mode:

But in editing mode, it can get quite confusing. As you could for instance have a situation with double edit bars (the JDP one and the confluence one):

@Rohan Swami , @Tanguy Crusson, could we imagine the option of simply integrating/pointing to a confluence page instead of the description? Like "use a confluence page as description" that could be directly edited from JPD within the embed link?