Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A Tools for multiple creators/writers documentation without clouds

The main challenge of having multiple writers is dealing with conflicts -- either you have to lock files to prevent concurrent edits (as Word does), or you need a way to compare and merge changes. ...

posted 10y ago by Monica Cellio‭  ·  last activity 5y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T03:47:22Z (about 5 years ago)
Source: https://writers.stackexchange.com/a/12997
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by (deleted user) · 2019-12-08T03:47:22Z (about 5 years ago)
The main challenge of having multiple writers is dealing with conflicts -- either you have to lock files to prevent concurrent edits (as Word does), or you need a way to compare and merge changes. Locking files can be pretty limiting (especially as your group grows), but source-control systems give you the latter if you don't use a binary file format.

I wrote a lot elsewhere about [the advantages of using source control for documentation](https://writers.stackexchange.com/a/10443/1993). The key factors for you are the support for comparison (diff), merging, and branching. In my previous position I spent many years using Perforce (for source control) and XML (DocBook) source for documentation with a small documentation team. We had _very_ few problems with conflicts -- only if two people made differently-drastic changes to the same section without talking with each other first. We learned to talk with each other first -- coordination for things like wholesale restructurings is still important, but we could just fix bugs and make minor updates without worrying. In my current position my team of about a dozen uses svn with HTML files; I haven't done an svn merge yet but I know it's possible. (I've been told it's not quite as nice as Perforce's, but it works.)

Comparison and merge tools depend on having meaningful source to compare, so that means you need to use some text source, not binary blobs. Regardless of what WYSIWYG editor you might use to edit your files, you want the stored format to be XML or HTML or LaTeX or some other text format.

As for generating PDF, there are lots of ways to attack this. I explained elsewhere [how to generate PDF from DocBook source](https://writers.stackexchange.com/a/10051/1993). Flare projects can be built to produce PDF (and HTML), which you can invoke from within the tool or externally. (We have a nightly build that builds from our Flare source in svn.) LaTeX's natural habitat is the command line and, again, it can produce PDF. (This is a placeholder for Scrivener, which I haven't used but I've heard great things about.)

Bottom line: use source control and use a comparison-friendly source format to allow multiple writers to work in the same doc set, and there are many ways to generate PDF depending on what you're doing.

#1: Imported from external source by user avatar System‭ · 2014-09-30T16:19:59Z (about 10 years ago)
Original score: 2