[confluence_perf]

followup questions: what level of support are you looking for, and what would be sufficient?

1) markdown macro (limits markdown to the body content, and not interacting with other macros or styling)

2) copy/paste markdown -> autoconvert to WYSIWYG (limits markdown to copy/pasting, so no editing Markdown inside)

3) "markdown pages" (something like 'this page is Markdown only, no WYSIWYG)

I make no comments/promises on any of these becoming real but looking for what's most valuable

[epage]

Not who you are respondin to but some thoughts

1. Don't be Slack / Teams :)

What I mean by this is if you support it, support it correctly rather than "markdown as keyboard shortcuts" that some products do where if you make the simplest of editing changes, your "markdown" isn't recognized.

2. Devs want to consistently use Markdown across their entire suite

At my last job, we were switching to Azure DevOps. They support Markdown in the developer workflow (PRs) but rich-text-only for Tasks (to be non-dev friendly?).

At my current job, I'm involved in developer productivity and have been interviewing people to collect input for where we want to take development. We currently use Phabricator which uses Remarkup. This is a source of frustration because its not quite the markdown they use everywhere else.

From these, I'm thinking Markdown Pages would be the top choice since it allows developer-only interactions and marketing-only interactions to stay within what they are comfortable with,

[confluence_perf]

Thanks for the detail! Point (1) is very interesting

on (2) -> it sounded like you're saying (a) 'across entire suite identically is good', but that also (b) 'if there's a clear separation of Dev vs nonDev apps/docs, having different support is okay', did I read that right? please correct me if wrong.

[nickdonnelly]

The correct answer here: use the same editor in the entire suite, everywhere. Give the user a setting to decide if they want that editor to be WYSIWYG, or markdown.

In my personal opinion, Atlassian's rich text editor (or, seemingly, the 4-6 different one's you guys have built) is unforgivably terrible, so true markdown is the way to go if having both isn't an option.

[saagarjha]

As a programmer, being able to have something like what GitHub does (Markdown text, you can preview what the rendered version looks like) would be great. I assume that people who are less technical would like a more WYSIWYG editor but as long as the ability to write straight Markdown is there I am sure that I wouldn’t care. Oh, and make sure it’s actually a reasonable subset of Markdown, not like Discord or Slack where you support bold and italics but mot much else.

[confluence_perf]

Thanks! I'm not sure this is the most doable thing (I'm not familiar with the technical aspects of the editor storage format) but can definitely discuss with that team.

The "reasonable subset of Markdown" is also a very useful specific detail, exactly the kind of specificity that helps us do our jobs.

[Kinrany]

There's CommonMark, a standard for Markdown. You could make that your goal, instead of feature parity with any of the proprietary implementations like Github.

[TeMPOraL]

FWIW, check out the new Reddit interface. For all the well-deserved hate it's getting (some of which for the same reasons Jira is), it showcases that you can have a dual WYSIWYG/Markdown editor that works, and allows switching back and forth between modes during editing.

[chrisseaton]

Just normal Markdown for all edit fields! GitHub manages to have a single (almost) Markdown format everywhere. Could we have that in all Atlassian products. There’s no need for your own format.

[SaladFork]

The biggest request I have of JIRA aside from performance is that whatever markdown/markup language you choose, that it be consistent across the entire product.

It is so frustrating to have to remember to use double-curlies for inline code/pre sometimes, and backticks other times. In each case, the other doesn't work. More than once using one has resulted it rendering correctly on the immediate page but not on the next.

This is one I encounter regularly but is far from the only inconsistency in support.