bmamlin838901670 - Please see my response here: https://jira.atlassian.com/browse/CONF-35903?focusedCommentId=868168&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-868168, but just to be clear on how we use this system (jira.atlassian.com): Things raised here are not a backlog. It's simply a pool of suggestions and bug reports from customers. We don't have our backlog in this JIRA project, but rather use it as a way to capture customer feedback. So if an issue is closed here it doesn't mean it will never be done, in this scenario it's something we can't see ourselves doing in a long time and we're closing just to set expectations. It is something we've talked about but is extremely costly in terms of time and at this stage we don't feel that would tump the priority many of the other of the 6,000+ other feature requests many customers are asking for... hope that gives you some insights into how we use this.

I was bummed to get notified via CONF-35903 that live editing in Confluence has been taken off the foreseeable road map.

Great to hear! Thanks!

1. How do you use Confluence today? What types of pages are being created? Which departments are using it.

Meeting notes, project plans, design plans, documentation, FAQs, release notes, road maps, and conventions/policies. Most of these are being created by developers and project managers. While any of these could benefit from the ability to collaborate, project & design plans will likely benefit more from inline comments and the biggest use case for collaborative editing for us, by far, will be the meeting notes, which we often try to take as a group (that's why we tend to use etherpad for note taking and, when we can remember, transfer those back to Confluence when the meeting is over so the content will be searchable).

2. I'd like to get your feedback on the following scenarios:
a. As users are editing, changes are being saved "live" and pushed publicly. So users viewing a page can see the changes as they are happening. There is no step to "publish".
b. As users are editing, changes are not "live", but saved in a draft. At any time a any of the authors can choose to "publish" the changes, or save their draft and come back to it later to publish. This would mean that there would be "pending" changes which aren't published yet, but we would let the author(s) decide when they want to publish.
Out of scenarios 2(a) and 2(b), which one fits your organisation the best if you had to choose one? Why? What are some examples where (a) or (b) would work best for you?

I could see benefits to both approaches; however, if forced to choose one, it would be 2(a).

We've found collaborative editing in tools like etherpad and Google Docs to be most useful for shared note-taking in group meetings and they function as you describe in 2(a), without a separate publish step. This is true for a handful of people in a team meeting and even more so for OpenMRS community meetings, where we can have several dozen people around the world sharing notes during a pubic forum. Pushing changes publicly, especially for meeting notes, has the benefit of allowing some users to follow along passively (e.g., lurkers or people who might be commuting during the call and using a tablet to follow along).

In cases like documentation, policies, road maps, etc. where there may already be a "published" (saved) version of the page and people are collaborating on a new version, I could see 2(b) as a useful option.

Perhaps both approaches could be accommodated by having a publish button similar to etherpad's "save revision" button, except it could be locked (via checkbox or whatever) into a pressed state for "continuous publish" mode.
 

• Anytime the publish button is pressed by anyone, the current state of the document is published.
   
• If someone locks the publish button in a pressed state, then publishing is continuous and all changes are instantly viewable.

That would allow for both 2(a) and 2(b) without separate workflows. Instead of choosing "publishing mode vs. not publishing mode," it becomes a simpler choice for users between "publish manually or continuously."

Hi Burke,
Don't worry, that will be the plan! What you saw was just one of several jounries we demoed to get to live editing. Multiple users will be able to edit the same page without having to invite. Thanks for the feedback.

While I've got you here and thinking about collaborative editing, I'm curious to hear a couple of things from you. We're working on the feature right now and would be interested to hear some feedback (if any) on the following topics:

1. How do you use Confluence today? What types of pages are being created? Which departments are using it.

2. I'd like to get your feedback on the following scenarios:
a. As users are editing, changes are being saved "live" and pushed publicly. So users viewing a page can see the changes as they are happening. There is no step to "publish".
b. As users are editing, changes are not "live", but saved in a draft. At any time a any of the authors can choose to "publish" the changes, or save their draft and come back to it later to publish. This would mean that there would be "pending" changes which aren't published yet, but we would let the author(s) decide when they want to publish.

Out of scenarios 2(a) and 2(b), which one fits your organisation the best if you had to choose one? Why? What are some examples where (a) or (b) would work best for you?

Again, thanks for the feedback, we've got a long way to go with this feature - but we will get there!
Sherif