[michihuber]

I agree with this being about workflows, not documents, but isn't branching and merging a workflow and storytelling tool?

It allows multiple people to work in parallel (and in private). When somebody sends a pull-request eventually, they are presenting a story of changes that they want to get into the document and people can discuss them and approve them individually. (Of course, git the tool isn't necessarily suitable for non-technical people, but git-the-workflow seems to be a good foundation.)

Could you elaborate on what such a tool could look like without git style branching?

[Icathian]

I think the issue is that parallel workflow is a bridge too far for the current legal profession. They do sequential and they like it. A tool that makes the sequential workflow better will gain more ground than one that tries to change the process whole hog.

[jimmygrapes]

I have worked on several hundred of these types of contract processes in the last few years, and you are absolutely correct: sequential is where it's at for these situations. I have, however, encountered a few situations where time was an issue so I had two or three different versions out to different parties at the same time, and then merged the proposed changes where possible and sent out alternate versions where the changes differed. That process was... not fun, and could definitely use a more coherent workflow than manual merges or Word's built in merge features.

[fredguth]

The anecdotes told here suggest that most think their work is sequential, while because a lot can happen asynchronously, hell situations happen all the time. Do you agree?

[fredguth]

But the workflow only "looks" sequential, isn't it? In many stories told here a user may have inadvertently revert clauses to old versions and this can be missed. This happens because it is also an asynchronous work.