>In a legal document negotiated between parties you don't want to keep track of every version of the file, just the latest version of the offered terms and counteroffered terms.

Not true, at least from the point of view of a litigator.

The changes to an agreement can be crucial, especially in the absence of an entire agreement clause. There are, of course, rules about using evidence outside the agreement to construe its meaning, but many exceptions to this rule exist - eg, mistake. The biggest exception is ambiguity, where previous additions/deletions serve to highlight what the parties' intentions were at the time of agreement.

That would be awfully difficult to have accepted by a judge.

Even if it was, proving intent would be very difficult - after all just because you introduced a change doesn't mean I agreed to it.

Often contract clauses start off in a "no way I would sign that" state, and may get carried along for a while as you are focused on different things. The fact it existed in the history is, by itself, pretty meaningless.

As a former litigator, I have never found a judge willing to accept such evidence into the record.

i’d argue that it’s not “designed to fit our workflow” so much as designed around a subpar, but flexible tool that everyone was using. that don’t make it good; that just makes it ingrained

Track Changes tracks changes. By multiple authors. And allows comments outside of the substantive content of the document. It works across multiple versions of itself, and is even compatible with competing software. And best of all, it requires no additional software to learn or maintain.

That makes it superior for legal documents to all version tracking systems that I'm aware of that are used in the programming field.

Well yes, if you constrain the solution set to satisfy "requires no additional software to learn" then you'll end up with the status quo solution.

One thing I've always been concerned about when negotiating a legal agreement is how I verify that the tracked changes actually track every change. Because Word lets the user decide which changes to track, I'm always reading the untracked sections as well to confirm that no other changes were sneakily introduced. That's something that git addresses well. Does Word have a solution there? If not, does that ever concern you?

As a former attorney, I'd just do a diff. Save a copy, reject all changes, then do a diff and compare side by side. As a current software engineer, Word is definitely sufficient (and understood, which sf good) for two small adversarial teams. Key words being small (two huge firms negotiating a huge deal should not be using Word) and adversarial: I think a lot of times when tech-people suggest lawyers could do a better job they forget the other side isn't trying to be helpful.

Two huge firms negotiating a huge deal probably are in fact using Word, right?

Things like that probably have multiple outside counsel involved, and various versions of Word. :)

This is why you always do a diff.

In my limited experience, Word is used for the early back and forth, but final stages are done and reviewed in PDFs, and PDF diff tools used to identify any changes. No reason you couldn't do the same thing all in Word.

It does have such a tool, you would have rev A (old one) then collapse all the tracked changes in rev B and diff with A.

There is a Compare feature in Word exactly for use in these cases.

You say "requires no additional software", I say "doesn't allow me to use whatever software I want". For example, I can't edit a legal document while SSH'd into a host computer on my firms network.

Also, Track Changes doesn't allow two people to work on a document asynchronously, while git does.

I have seen a ridiculous number of errors in legal documents given the fact that a huge part of the legal profession is to produce solid/error-free documents.

But while the law profession's response to this seems to be just "be a better lawyer", the software industry's response is "build better tools that don't allow me to make errors". I'm sure I don't need to tell you which method I think is preferable in the long term.

I do not particularly agree with the some of the arguments made in this thread for and against the status quo, but some of your statements are factually incorrect.

>For example, I can't edit a legal document while SSH'd into a host computer on my firms network.

Track changes is supported by LibreOffice and its kin, so certainly possible to ssh into a computer on your firms network and edit it. Might require an X server on your local machine, I am not sure if libreoffice works in terminal (but its open source, so if you really wanted to you could add support!) That said, the recommended way to do what you are asking is to run an "Online Office Server", which gives you a online version of word (think google docs, but looks like MS word) that you can access through you VPN or company portal with ssl/tls. Different workflow for different folks I suppose.

>Also, Track Changes doesn't allow two people to work on a document asynchronously, while git does.

Office 2019 has added 'source control like' simultaneous/asynchronous editing when integrated with a Sharepoint server. Multiple people can have the file open, and the save button both commits your changes and pulls whatever other changes have been committed since, with options to resolve conflicts.

Furthermore, with the office 365 version of the office suite (or Online Office Server, which is nearly the same thing but self hosted) it is possible do live editing, whereby multiple people edit the same document simultaneously (google docs style). Not sure why you would want to do that, but it eliminates merge conflicts at least and seems to be pretty popular at my workplace. Especially useful when someone is presenting slides and there is something you don't like in them ;-)

Of course, as long as your document is on a sharepoint server, you get version control built in and can roll back to see the document at any save point, do diffs, etc.

It is true that the FOSS world is more civilized, but Microsoft isn't sitting by idly. They spent $8B on github for a reason, and it wasn't to get their business model.

Sorry, with the first point I wasn't very clear, but what I meant was editing a document from a SSH'd shell, using a CLI text editor like vim, emacs, nano, or any of the plethora of existing tools that work out of the box to edit documents. Editing which can then be checked into version control like git. That is obviously very different from "you can build a CLI for LibreOffice which is currently compatible with the Track Changes implemented by MS Office but might not always be".

Having to use MS Word in the cloud doesn't really scratch the itch I'm talking about either.

That's cool about Office 2019, I did indeed not know about that. Can I perform these Sharepoint-enabled changes while offline? It seems like all of the things you are talking about require a centralized online server in order to do. Regardless, I do not think there is a conflict between the statements "you need Sharepoint to do these things" and "Track Changes cannot do these things".

> a CLI text editor like vim, emacs, nano, or any of the plethora of existing tools that work out of the box to edit documents.

Asking a world that is used to what came out of Xerox PARC to switch back to 1970's technology on teletype emulators is...the only word I can think of is Quixotic.

The point is not that I want people to switch, it's that software developers have choice and lawyers / etc don't.

To write software, I can use a CLI text editor, a basic GUI text editor, an advanced text editor like Sublime or Atom or VS Code, or a full on IDE like the JetBrains products. I have so much choice, and all of these are interoperable with each other and have different places where they shine. All work with git. I just don't think the same thing can be said for the document-creation workflows around law and such.

A hammer is pretty much an ancient technology. A battery-powered plastic toy hammer, with buttons that play melodies, is a modern take. Yet serious people use the (modern implementations of) ancient-style hammer to drive nails.

That's my general response to "why use 1970s tech?", though I guess I'm being a bit unfair here. Word is, in some ways, a marvelous piece of engineering. The whole Office suite is. Unfortunately, thanks to path dependence and business strategies, it's also locked in a place where it's not interoperable with anything outside the Office ecosystem by default.

I guess I have an answer to the age-old question: in sci-fi shows, how come nobody in-universe notices their computing technology is, in many areas, ridiculously inefficient and ineffective compared to the old XX/early-XXI-century tech? The answer may be, the sci-fi future tech is built on so many layers of lowest-common-denominator, walled garden, non-interoperable tech that people no longer know how interoperability or efficient computing looks like.

I don't disagree a hammer is still a useful too, a lot like how a pencil and paper can still be a useful tool for architecting software, or when we need to sketch something out. However when it comes time to build a new construction, no, people are not out there hammering every individual nail. They're using nail guns and all manner of power tools to complete the job because it's more consistent and less time consuming.

Lol, claiming that using text files is somehow a regression is a pretty lame misdirection. You know what else came out of xerox parc? The GUI, the mouse, etc. You know what else is 1970s tech? The internet, databases, etc.

“Being old” is probably the lamest way to claim something shouldn’t be used.

You're asking for trouble if you are relying on track changes. Anyone can disable track changes, make changes without highlighting them and send it back with track changes reenabled. You need to compare any received file against what you last sent to see the real diff.

There's got to be a better way.

The better way is using the Compare feature that has been in Word for years, if not decades.

The problem with that is that it gives a change tracking tool that doesn't work, giving people a false sense of safety, relying on users to remember to manually diff every change sounds like a security issue in itself, that diffing should be either an automatic process instead of track changes or track changes should track everything by default.

If the other party attempts to sneak in such a change, usually you extract a concession from them when you catch them as many bar associations now regard that as unethical behavior warranting discipline.

Yes, but you still have to catch them, and the fact it's possible gives them the leeway to try, when the point of business is to do business, not to catch people out.

That's an imperfect solution for a problem that didn't need to exist in the first place that might even produce its own list of problems.

So if you have a set of documents that are all being negotiated at the same time between parties. How do you show what changed in DocumentA at the same time as the concessions in DocumentB? By comparing timestamps?

It feels like the CVS way of versioning (Every document has a history) rather than the modern way of versioning (A set of documents has a history).

Perhaps this is a smaller problem for these kinds of documents because while my changes are often a dozen changed documents in a set of a hundred thousand documents, these word processor changes are typically across one or two documents in a set of one to ten?

You don't have a set of documents. You just have the one document...

It's almost like you guys are deliberately ignoring all the lawyers with actual transactional experience to create hypothetical problems that don't exist in the real world so you can suggest version control as a solution.

No I realize the circumstances are different (like fewer documents in a process) but some times you don’t notice how your tools actually change your processes.

E.g: if you are in a process when there would naturally be two separate documents it may be that you are creating a single document becuse with the single document the change process works with the tooling.

Or is there something else inherent to the process that says a process/negotiation always includes one document?

I’m not sold on version control either - especially as structured text like word processors have such poor support - but it seems even change tracking in word documents should be able to track and show the differences in a set of documents such as a directory. I’m not arguing those tracking 3 word docs should use git.

Git has all those things, except yes it is a different tool.

Track changes in Word works pretty well for turns of a contract. What features do you think are provided by "version control" that aren't handled by Track Changes for contracts?

The ability to keep track of many, potentially thousands of individual changes and assign labels to significant versions. Track Changes is basically like Git if every file write triggered an automatic commit with no commit message and anyone could rewrite history at any time. SharePoint major versions are better but they’re not free, standard, portable or popular.

If you have a legal agreement with many thousands of changes at any point, someone is getting fired for royally fucking up...

Legal agreements are basically a war over each party's choice of standardized language followed by battles over customized terms.

That may be accurate for commercial contracts but lawyers write lots of other documents too, some of which are subject to thousands of edits. Think about judicial opinions, advices, written arguments, continuously updated legal commentary services, public reports, or indeed statutes. These documents are often carefully drafted over months and complex manual protocols get set up to manage it, due to the limitations of Track Changes and the lack of familiarity with the tools used by software engineers.

I agree. Most legal docs could probably be better captured in markdown or asciidoc rather than MS Word (and all the bloat it brings with it).

That’s the entire point of pull requests though? Or am I missing something