Changes by you are highlighted in one color.
Changes by other parties are highlighted in other colors.
If you need a diff between versions Word can generate one for you in seconds.
So yes, this is exactly how we work. Because it was designed to fit our workflow.
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.
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.
That makes it superior for legal documents to all version tracking systems that I'm aware of that are used in the programming field.
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?
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.
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.
>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.
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".
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.
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.
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.
“Being old” is probably the lamest way to claim something shouldn’t be used.
There's got to be a better way.
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?
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.
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.
Legal agreements are basically a war over each party's choice of standardized language followed by battles over customized terms.
- Laws are passed by Congress and signed by the President.
- The actual formal text of the law is printed in the “US Statues at Large”. Think of this like a commit log— it’s written as a series of add/modify/remove operations to the United States Code (USC), which represents the “master” branch of the repo; our current laws.
- Sometimes the add/edit/remove operations have implications in many parts of the code. There is a manually-intensive process that actually determines which parts of the USC must be modified and how. This is like code review on a PR.
- Periodically, after many laws are passed and many mods to the USC, it is “republished” (tag/release).
Why we couldn’t do this with our laws is beyond me. Institutional inertia I suppose.
But Executive's do get up to "naughty shit!" as a Uk Party Whip said to me once in a bar.
Word's "track changes" feature is good enough that an MVP for such a VCS product would need to have a very good UI.
(Source: talking about version control with a lawyer in the family.)
Why are legal documents recorded in a format that requires expensive software to access?
Why are LaTeX, Markdown, or HTML not sufficient formats? What makes plaintext not "human-readable"? I don't think anyone has trouble reading/writing their Facebook and Twitter posts in plaintext.
Why can't our government afford to develop a lawmaker-specific format and an editor (or plugin for an existing editor) to make it easy for lawmakers to work with?
Why can't our government afford to fund the creation of a VCS solution with a lawmaker-friendly interface and a public server to host the repository on?
Why can't all of our legal documents at least be hosted on a public server in their current state?
I'm guessing the answer to all of these is "because the public doesn't care enough, so it doesn't help anyone get re-elected and, therefore, there is no available funding". I have a hard enough time getting engineers to understand the value of good VCS, much less an average US citizen.
Because lawyers can afford it, and don't really feel like expending effort evaluating software alternatives instead of just doing their work. And because of legacy/network effects. And because no one has pitched an alternative right for that audience.
Lawyers can afford free software too.
I have seen that MS Office suite has become a hammer used to drive many non-nails in various businesses, and would like to see people using more open standards. But I totally understand that for many use cases it's good enough and that people consider the cost to be not particularly significant
Do you think having access to a tool with the least communication friction saves you 2 minutes/month of your lawyers time? 30 min of your junior marketing person? This isn't a hard call to make usually.
As for lawyers, just because they can afford to use expensive software doesn't mean they should. I can afford to write software in Word, but I don't plan to try that any time soon.
Also, I think people seriously overstate how "easy" it is to use Word. I have spent litteral days of my life in classes that taught me how to use Word. I have spent hours relearning MS Office interfaces as they've changed over the years. I'm pretty sure I picked up GitHub-flavored Markdown in less than 15 minutes.
My point about the cost is that the network effects of the tool here are more important than the tool itself. You might be able to have a better local workflow using other tools, but if everyone you collaborate/work with doesn't use them then the cost of communication is far higher than any savings.
Realistically, legal work isn't much like coding. Although lawyers do spend time editing documents that isn't where the real time is. For that reason I'm not convinced that changing to a putative VCS workflow would have enough efficiency impact to pay for the training etc. except on a very long term. This sort of thing makes it very difficult to win out against network effects.
This is much the same reason that excel is used for a lot of things where better tools exist. The combination of network effects and having better things to do than learn a new approach and toolchain are hard to shift.
Because the cost of the software is trivial compared to the cost of incompatibility or friction in communication.
So your real problem here is with the access to said laws, which is not a software problem.
I'd bet a tool like lyx (https://www.lyx.org/Screenshots) would go along way to being a better solution. It's a great document writer (as opposed to a word processor) and apparently has some VCS support (although I haven't tried this) and diff viewing and is a lot more reliable for annotations and all that stuff than word.
I've done some legal automation work before, it would have been so much easier (and get better results) to have a plaintext format we could manipulate with shell scripts than working with docx and word.
- But doesn't plain text suck for difs?
+ But doesn't plain text suck for diffs?
- Especially when you have a really long, multi-line
- paragraph that has bmore than one change? And if we
- relied on word wrap, then the scope of change would
- be the paragraph and all hope is lost. At least
- this way we might eventually regain some
+ Especially when you have an exceptionally long,
+ multi-line paragraph that has more than one change?
+ But if we relied on word wrap, then the scope of
+ change would be the paragraph and all hope is lost.
+ At least this way we might eventually regain some
equivalency by chance and it's clear that nothing
after that point has changed.
(For clarity, I think probably a sentence-by-sentence diff would work well. But then it's not plain text; you're relying on some processor to collect sentences into paragraphs.)
https://github.com/dart-lang/language/blob/master/specificat...
Markdown or Asciidoc has the same benefit as far as paragraphs.
But again, all those tools are built for developers, and especially the ones used by git for internal purposes like for conflict resolution make some strong assumptions that don't hold for prose.
https://www.springcm.com/products/contract-management/negoti...
For a start they’re using Word, which doesn’t work well with version control.
And asking most people to stop using MS Office is like asking them to go and live on the Moon, they look at you like you’re some kind of crazy person.
It's basically the same as using Word's own history features.
First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Microsoft Word documents. Everyone knows that Word is the most horrific editor around, but oddly, everyone still uses it.
...Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in .docx, it should run those files through the “word” filter, which is defined as the docx2txt program. This effectively makes nice text-based versions of your Word files before attempting to diff them.
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
But it's terminology is really confusing.
But yeah some layer of abstraction would be handy.
I always think of introducing it to my wife when she looses a document or something but god damn the terminology.
The lack of continuous versioning is a problem for most document like workflows.
So why do you expect the git hash to encode the timeline?
Git encodes the timeline in the parent/child relationship of commits (and/or the date stamps). Trying to look for the timeline information in the hashes is going to be futile, that's not where it's supposed to be found.
For documents that get send back and forth via email, amongst more than 2 participants, git's DAG is actually a better representation than a linear timeline.
(But yes, if you don't like that, you can set up git to reject commits with more than one parent to enforce a linear history.)
You get 30 days of history for every file in Dropbox (120 days for Business users). Earlier you could pay a bit extra to get a full year of history -- but that feature, called Extended Version History, is no longer available.
OneDrive unfortunately offers only 30 days, I believe Google Drive is similar.
Every once in a while, they update Developer License Agreement or Paid Application Agreement (updated over 100 times so far), and every time they just show a wall of text. I save it as a file and take a diff to the previous version.
They must be using a VCS internally but they make us repeat the same effort again and again. It's stupid.
Beyond technical hurdles that could be solved with a set of FLOSS components and plugins to popular CMSes, I don't see any reason not to do this if one runs a honest company.
Consider yourself lucky. There are still legions of legal documents in WordPerfect.
B.t.w since it’s about the US Constitution it is customary for me to share a link to its book form on the web:
https://bubblin.io/cover/the-united-states-constitution-by-u...
In software, you need to track versions because you keep everything in multiple files, and you're making changes to multiple files, and you can have regressions with each new version.
In a negotiated legal document, you have just the one authoritative version: the offer you've sent to the other party (or the counter-offer they've sent back to you). For lawyers, this takes the form of edits to the document as highlighted by the Track Changes feature. (Prior versions are basically irrelevant except for historical interest.) And even then, the document going back and forth isn't even the executed (aka "production") document, it's just the development version. Once the document is executed, the development versions get deleted because the executed document is the only truth legally and so prior versions absolutely do not matter.
No, you literally can't. They're separate files. A legal agreement is just one document. It makes a world of difference for version tracking.
Also, software has versions. If you have an issue, you can just rollback to a working version. Legal agreements don't have multiple working versions. They just have the one, and you don't get to update it, because if you change it, you have a different agreement that supersedes all old copies, which are now longer worth the paper they're printed or or the bytes that store them.
Sure, you could have needlessly more complicated version tracking for legal documents. But Track Changes in Word works fine, because the legal field doesn't need anything more complicated.
In the same way, i can literally think of my legal documents as a single document (say, a visa application) with multiple files (say, a petition, a copy of my wedding certificate and a reference from a friend). [Ironically, this language is precisely the reverse of what you would say with the printed copies.]
When they're printed out you can't tell what the boundaries are. Don't get confused by the implementation and the abstract concepts. If there's a distinction that doesn't work well, you can change it. Maybe version 2035 of Word stores every paragraph in a separate file inside a zip archive. There's no reason Generic Version Control System 2038 couldn't be written to peak inside those archives.
Ideally, settled issues should remain settled as remaining outstanding issues are resolved during the deal-making process.
But, this is a western tradition/convention, Asian deal-makers seem to be more than happy to look back and re-open settled issues, driving American lawyers insane.
Something like this already exists in multiple forms because it is very useful. It's so useful that the owners of those sites can charge lawyers a lot of money for access... Hundreds of $ per month.
That's not true. Many a times I needed to comb through old commits for debugging purposes.
Also, with multi-branch development, you often have many non-release branches that are relevant at a specific point in time.