4 ms·

.doc files also allow one to make edits and make comments and email back and forth between lawyers & stake holders during the negotiation phase.

by diziet 12y ago

MichaelGG 12y ago
I wonder how often this is abused. Are people relying on change tracking, or actually using the diff functionality? I've seen at least one where people just used change tracking. It would have been easy to change something and accept changes and could have slipped by or changed negotiations.
- HarveyKandola 12y ago
  You tend to get legal "assistants" that end up taking multiple documents from different people and manually consolidating changes. Terrible state of affairs!
- kemitchell 12y ago
  Great question. This actually rises to the level of a professional responsibility rules issue in many jurisdictions. Take, for example, this recent-ish opinion from the California Bar's ethics committee: http://ethics.calbar.ca.gov/Portals/9/documents/Opinions/CAL%202013-189%20%5B11-0002%5D.pdf http://ethics.calbar.ca.gov/Portals/9/documents/Opinions/CAL... The best practice is clearly to run the diff from your own last revision, but that may not be available to the attorney. Sometimes clients forward opposing markups of drafts that were prepared without an attorney, perhaps based on a form. Business people may tweak a draft between attorney revisions, as they closed on deal points. It might be worthwhile to go over and attribute each unrecognized change, but not always. Clients may vouch that all changes needing review are in Track Changes. Sometimes speed matters more. Between repeat-player attorneys, or when reputations for ethics and rigor otherwise precede each side, the risk of this kind of thing approaches zero, and everybody saves money. I have seen things "slipped in", often inadvertently (turned Track Changes off, diffed the wrong files), but sometimes maliciously. I have also done very long days of nothing but verifying execution copies of documents as they were closed out in the run up to big-dollar closings and low-dollar slug-fests. When the transaction is large or important enough, attorneys will handle exchanging drafts across sides and enforce more rigorous change control.
mark212 12y ago
I spend half my working day in Word's review feature wrangling redlines so, yeah, Github is a non-starter for something like this.
- joewadcan 12y ago
  I'd suggest this tool (http://ben.balter.com/2015/02/06/word-diff/ http://ben.balter.com/2015/02/06/word-diff/) my colleague (@benbalter) made to collaborate on Word docs using GitHub.
derefr 12y ago
Wouldn't that be done better with a live-updating shared document, ala Google Docs?
- kemitchell 12y ago
  A draft agreement often goes through internal revisions and edits before it's packaged up as a single "redline" (akin to a diff) that's presented as a package to the other side. The order and scope not only of edits presented, but other alternatives drafted and dropped, or drafted and tweaked, is potentially revealing, as is the timing of edits and the fact of who made them. A live editing environment doesn't let you hide these details when necessary. It also fails to prevent the other side mucking about in the draft as you're reading, reviewing, or editing it. Sometimes everyone will play nice and wait their turns to use the pen, but often they won't. Similar concerns make it difficult to adapt Git for use with opposing parties, since many of Git's features flow from the way it addresses its tamper-evidence design goal. The only notion of a commit with two ancestors in Git is a merge commit, which nonetheless preserves the complete history of both parents. So one side can't manage internal revisions with in-house commits (bearing author name, timing, exact content, etc.) and then issue a PR, while keeping the history of internal revisions secret. They have to edit history and make a squashed commit available for pull. At that point the incremental benefit of Git is just SSH or HTTP instead of e-mail. It's just managed patchfiles.
  - eterm 12y ago
    Forgive my ignorance (I've mostly used svn before) but doesn't rebasing result in squashed commits in the way you'd want?
    - kemitchell 12y ago
      Squash commits it does, but I don't think we really want squashed commits. Squashing works to hide edit history from the opposing side, but it also pulls history out of your own history. You can create a branch at your local head before squashing to save those commits, but when you get an edit back, its new commit will reference your squashed commit. If you rebase onto the branch with your local changes, you can reconstruct "your history", but you'll have to be careful not to push commits from that branch to opposing next round, since it now contains your private edit history again.

.doc files also allow one to make edits and make comments and email back and forth between lawyers & stake holders during the negotiation phase.

by diziet 12y ago

.doc files also allow one to make edits and make comments and email back and forth between lawyers & stake holders during the negotiation phase.

MichaelGG 12y ago

I wonder how often this is abused. Are people relying on change tracking, or actually using the diff functionality? I've seen at least one where people just used change tracking. It would have been easy to change something and accept changes and could have slipped by or changed negotiations.

HarveyKandola 12y ago
You tend to get legal "assistants" that end up taking multiple documents from different people and manually consolidating changes. Terrible state of affairs!
kemitchell 12y ago
Great question. This actually rises to the level of a professional responsibility rules issue in many jurisdictions. Take, for example, this recent-ish opinion from the California Bar's ethics committee: http://ethics.calbar.ca.gov/Portals/9/documents/Opinions/CAL%202013-189%20%5B11-0002%5D.pdf http://ethics.calbar.ca.gov/Portals/9/documents/Opinions/CAL... The best practice is clearly to run the diff from your own last revision, but that may not be available to the attorney. Sometimes clients forward opposing markups of drafts that were prepared without an attorney, perhaps based on a form. Business people may tweak a draft between attorney revisions, as they closed on deal points. It might be worthwhile to go over and attribute each unrecognized change, but not always. Clients may vouch that all changes needing review are in Track Changes. Sometimes speed matters more. Between repeat-player attorneys, or when reputations for ethics and rigor otherwise precede each side, the risk of this kind of thing approaches zero, and everybody saves money. I have seen things "slipped in", often inadvertently (turned Track Changes off, diffed the wrong files), but sometimes maliciously. I have also done very long days of nothing but verifying execution copies of documents as they were closed out in the run up to big-dollar closings and low-dollar slug-fests. When the transaction is large or important enough, attorneys will handle exchanging drafts across sides and enforce more rigorous change control.

mark212 12y ago

I spend half my working day in Word's review feature wrangling redlines so, yeah, Github is a non-starter for something like this.

joewadcan 12y ago
I'd suggest this tool (http://ben.balter.com/2015/02/06/word-diff/ http://ben.balter.com/2015/02/06/word-diff/) my colleague (@benbalter) made to collaborate on Word docs using GitHub.

derefr 12y ago

Wouldn't that be done better with a live-updating shared document, ala Google Docs?

kemitchell 12y ago
A draft agreement often goes through internal revisions and edits before it's packaged up as a single "redline" (akin to a diff) that's presented as a package to the other side. The order and scope not only of edits presented, but other alternatives drafted and dropped, or drafted and tweaked, is potentially revealing, as is the timing of edits and the fact of who made them. A live editing environment doesn't let you hide these details when necessary. It also fails to prevent the other side mucking about in the draft as you're reading, reviewing, or editing it. Sometimes everyone will play nice and wait their turns to use the pen, but often they won't. Similar concerns make it difficult to adapt Git for use with opposing parties, since many of Git's features flow from the way it addresses its tamper-evidence design goal. The only notion of a commit with two ancestors in Git is a merge commit, which nonetheless preserves the complete history of both parents. So one side can't manage internal revisions with in-house commits (bearing author name, timing, exact content, etc.) and then issue a PR, while keeping the history of internal revisions secret. They have to edit history and make a squashed commit available for pull. At that point the incremental benefit of Git is just SSH or HTTP instead of e-mail. It's just managed patchfiles.
- eterm 12y ago
  Forgive my ignorance (I've mostly used svn before) but doesn't rebasing result in squashed commits in the way you'd want?
  - kemitchell 12y ago
    Squash commits it does, but I don't think we really want squashed commits. Squashing works to hide edit history from the opposing side, but it also pulls history out of your own history. You can create a branch at your local head before squashing to save those commits, but when you get an edit back, its new commit will reference your squashed commit. If you rebase onto the branch with your local changes, you can reconstruct "your history", but you'll have to be careful not to push commits from that branch to opposing next round, since it now contains your private edit history again.