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
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.
“Being old” is probably the lamest way to claim something shouldn’t be used.
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.
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.