collaborative quarto editing

[jmbuhr]

What are your thoughts on collaboration with quarto?

For academic writing, I think the main "competitor" to match in terms of features is https://www.overleaf.com/ but quarto has the potential for a way smoother workflow, with preview for html output being much faster than recompiling on overleaf.
The main hurdle so far is collaboration with people who are focused on the content, who don't have to run the code but just want to change a couple of words, add a sentence, remove a section or highlight a piece and add a comment and have these changes tracked without having to know git or manually commit changes.

I assume these things fit in nicely with RStudio's professional products, but when the computations are not at the center, which is often the case when working on a manuscript, the added price would likely make people stick with e.g. overleaf, especially since in academia it is harder to spend money on such tooling compared to industry.

So, tldr. I would be over the moon to eventually see a minimal collaborative editing solution for quarto documents with a super low barrier to entry, like the google docs of scientific writing.

[jjallaire]

Yes, we 100% see these same issues and its definitely on our roadmap to address.

[jmbuhr]

For reference, I'm also the person that posted the original feature request, where I ask for exactly what you descibe ;)

As such, my comment above does not imply that git can replace this collaborative, real-time editing. But what it already replaces is e.g. an R package that would do the same job. Anything that doesn't add the convenience of something like overleaf / google docs and their real-time nature, but still adds it's own barrier to entry is most likely better off simply being git.

[jimjam-slam]

For real-time collaboration, VSCode's Live Share can also be a really nice option. The pros I really love are:

• You can see folks' cursors moving around in real-time
• You can follow someone else's cursor as they navigate a file (or switch files)
• You can optionally grant collaborators the right to run terminal commands if you're exploring
• Conversely, you can make the entire session read-only if you just want to show someone around a codebase
• You can share open web servers with collaborators, so they can test a Shiny app or a read a rendered Quarto doc alongside you (this happens automatically by default, I think, but you can change that if you don't like it)
• VSCode will actually add a "Co-authored by:" message with collaborators' names and email addresses to the end of commit messages when you commit while Live Sharing
• If collaborators don't have VSCode installed, they can connect to the Live Share session through a VSCode browser instance

[jimjam-slam]

One thing missing from Live Share is that someone actively has to start a session and others have to join it—it would be nice if something could alert other collaborators when they open a repo that someone else is also working on it! Maybe there's a VSCode extension in that...

[kinh-nguyen]

@jimjam-slam do you have experience on keeping the session live for a long time? I think normally others won't join right away, and the session has been very short-lived for me.

Another option is write quarto in a Jupyter notebook which has many options to collaborate (e.g., Google Colab). I haven't checked if the trackchange feature is there or not.

[jimjam-slam]

@kklot I'm not sure, tbh! I've had sessions that _lasted _ a long time, but if you're talking about ones where the host has been idle for a long time before anyone joined, I haven't tried that before.
L

[john-h-carson-jr]

That does sound interesting.

[sebastian-gerdes]

Thanks for the feedback! I will continue to think about the project and I might post updates here, so people could test it!

[grasshoppermouse]

Just use google docs. It works great for this purpose.

[harrelfe]

Google docs and (for markdown .md files) the Microsoft Sharepoint in-line text editor have perhaps the lowest barriers to participation of multiple authors of different skill sets.

[jameshowison]

Trouble I run into is that people write in google docs and instantly start using the layout tools, breaking markdown instantly. Care to share anything about the workflow that works for you? I'm googling "constrain google docs to plain text only" but not seeing anything promising :)

[john-h-carson-jr]

Let me suggest the following workflow, which includes downloading to Word and using PanDoc:

GoogleDoc (collaboration, possibly including format) ==> Word (Download as .docx) ==> Markdown (via pandoc) ==> replace generated content with code chunks ==> save as .qmd

[mcanouil]

Or use an add-on such as https://workspace.google.com/marketplace/app/docs_to_markdown/700168918607

[lamurian]

I stumbled on this package by chance, have you ever checked this one? This supports collaborative editing of qmd/rmd/rnw by leveraging Google Docs.

https://claudiozandonella.github.io/trackdown/

[jjallaire]

Yes, that is an excellent approach indeed!

[TS-CUBED]

Hmm, this looks like an interesting approach, but something that doesn't need R would be nice.

[hlageek]

The best solution I have seen so far are the online markdown editors. https://hackmd.io checks many boxes (renders markdown, real-time collab, comments possible on the preview, links for filesharing). Importantly, it can be integrated with GitHub, so changes in the narrative text can be merged back into a project repo and qmd can be subsequently fully re-rendered. There is a self-hosted fork https://github.com/hedgedoc/hedgedoc. The only downside is for the project maintainer who has to push changes from HackMD into remote (and handle conflicts), but there are basically no barriers for the collaborators. Unfortunately, so far no support for critic markup.

IMHO, a version of HackMD with critic markup support and some sort of cache for rendering the latest code chunk outputs would be pretty close to the Holy Grail of collaborative quarto editing.

I am also eyeing https://github.com/typst/webapp-issues, as quarto already supports typst. If their web app somehow supports quarto in turn, it could be an interesting overleaf alternative.

[da5nsy]

Flagging a parallel discussion I just started on the jupyter-book discussion section:

• https://github.com/orgs/jupyter-book/discussions/2161

[Arshiyasan]

Have there been any updates on this? My current workflow is local editting -> pushing to github -> an online markdown editor -> pulling. Would love to know what simple/robust workflows others are using!

[petertanksley]

Linking this here, Quartorium could be an interesting approach!

#12968
https://github.com/andjar/quartorium

[da5nsy]

Very cool! As I understand it - there isn't a hosted version of this anywhere yet, right? (which people could use via the web)

[MichelNivard]

I opnce build something similar: https://github.com/MichelNivard/resolve

Its hosted at resolve.pub, but no one ever uses it. The biggest issue I guess was that I stored the quarto doc in a .ipynb file, which because of its structure I found easier to parse from and too, that might have been too big of a nucance?

THis is a showcase: https://www.youtube.com/watch?v=uBmBZ4xLeys&t=1s

I might re-visist or reach out to the quartorium author to see if I can contribute.

[MichelNivard]

I think across his and my solution I see where the friction arises: quartorium renders the .qmd on the fly, which is an issue for a few reasons 1. code execution opens up security issues 2. data needs to be accesible/travels 3. hard to ensure dependencies are in place and project environment control becomes very hard. I tiried to get around that by editign a rendered document, and coming up with an interim file format which holds the qauarto doc and the wysiwyg, it was very in-enlegant. IMO it will be very hard to "have it both ways" where a document retains its status as pre render quarto file for the technical authors, but also is a WYSIWYG word like with computation/code abstracted out and the computational results previewable (i.e. (pre)rendered).