GitHub Workflow and Legal Drafting

There are a few posts on Slaw about Git/GitHub and the law, including several posts by Tim Knight. In most cases, the discussion centers on using GitHub to publish legislation and track legislative changes. I promise this column isn’t merely a regurgitation of previous content.

On Slaw, and in any post on the Internet that talks about Git and legal content, the fact that some legal document has been posted on GitHub is seen as an indication that somebody is trying to make things more transparent or collaborative, or just trying to bring the law closer to technology.

I think we have yet to see the real impact of software-like version control and collaboration in the actual practice of law and in the legal publishing world.

Git, GitHub and Version Control

Git and GitHub (or similar software and repositories[i]) are fundamental tools for computer programmers.

Git is a software programmed by Linus Torvalds (of Linux fame). It is used by programmers as a version control system (VCS). I have rarely heard it called this way in the legal world (except on Slaw, which is a world in itself) but lawyers use version control as well, of course.

In its most primitive form it consists of saving all versions of a document as a separate file instead of overwriting (while changing the file name to add v.1, v.2 and so on and so forth). In the more sophisticated end of the range, software (the classic being that good old Hummingbird DM) is used to assign a document number and attach all different versions of the same document to it.

GitHub is one of several online applications that allow programmers, using Git, to send (“push”, in Git parlance) their code to a repository (think of it as a DropBox for code) where it can be accessed by other team members or, if it’s a public “repo”, to the public.

One of the main ideas of the GitHub workflow is that collaborators don’t usually work directly on the “master” version of the code. They create a copy (a “branch”) where they make their edits, and then submit the edits for review by the rest of the team by opening a “pull request”. If the edits are approved, they are then merged with the master, often after having been tested “in production”. I admit it is not significantly different than lawyers circulating a document by email to multiple parties and consolidating all comments received in a master, but it doesn’t feel as archaic as, say, playing the gittern.

Lawyers as coders

Programmers and lawyers are just different types of “coders”. It would almost be flagitious to pretend that I’m the first one to suggest this. In fact, “law as code” is an idea that was already floating around in Roman times and Lawrence Lessig made the more direct parallel between software and law in his classic “code is law” of the early 2000s.

More practically perhaps, I found that drafting a contract is very much like “programming” the relationship between the parties… to a point where I grew jealous of programmers for two things:

• They have compilers who basically act like the most excellent (and intolerable at times) proofreader who refuses to compile (i.e. convert from human readable code to binary digits) the code when it containes syntax errors, among other things.
• They can easily generate tests that tell them right away how the computer will interpret the code. This is the equivalent of both being able to fast forward and see how the parties will behave under the agreement, and asking the Supreme Court to cogitate and interpret the contract while you are drafting it (and to be able to do it every time a change is made in the document).

Programmers, more often than lawyers, work in large teams on a single project with different pieces of code that are meshed together to create a stand-alone product. They also frequently collaborate on projects in non-hierarchical teams of people working outside a central organization. As such, there’s a reason why programmers are used to working with more sophisticated VCS than what lawyers use. That said, it doesn’t mean we shouldn’t try to level up our skills by taking a page from the software development playbook.

GitHub in the legal world

There is legal content on GitHub here and there (See these posts from Tim Knight. GitHub itself is doing it.), but I’m not aware of any large-scale collaboration on a legal document that is being done openly using Git/GitHub, or of any firm or legal team who has adopted GitHub as a VCS (don’t laugh, GitHub Enterprise can be used in a secure private cloud). I think it’s inevitable that we’ll get there (or something similar):

First, blockchain will alter the way we think about contracts and several types of legal documents will effectively be software-like. At that point I won’t need to argue that “legal code” is similar to “software code”, since the two will have merged, at least to some extent. GitHub-like workflows will be a mainstay of at least some types of legal practices (whatever the actual training of the people doing it).

Second, I remain convinced that crowdsourcing’s relatively unfulfilled promises (in other areas than encyclopedic content and software development that is) will one day be met and that GitHub-type workflow can be key in that process.

I think one of the reasons that wikis all but failed to have a transformative impact in the legal sphere is that the “allow changes first, let the community correct later” approach of wikis creates too much uncertainty about the quality of the current version of the document. If the community behind a wiki is not sufficiently large or extremely dynamic in reviewing changes and cleaning up after potential acts of vandalism (users who change the text to insert errors before leaving the site like fugitives), errors and misleading information can stay in the text undetected and delegitimize the text in the eyes of the readers. Of course, you can use a closed wiki to work on a text, but the workflow isn’t then so different than having multiple people edit a document in, say, Google Drive.

The GitHub workflow, more than just being a potentially powerful VCS for more traditional legal work, could make sense as a more organized and “top-down” approach to crowdsourcing the work on “open” legal content, including model documents and commentary.

I admit that for all my talk of legal content being similar to software, commentary looks more like documentation than actual code, but note that the “doc as code” approach exists in software development. On this note, I plan on working on a project that involves creating an intellectual property resource using Git/GitHub, so nudge me if you’re interested.

There are examples, outside the legal or software world, of “documentation” being developed collaboratively using Git and GitHub. See for example this report on the collaborative drafting of a book on “Homotopy type theory” (which is some kind of bleeding edge math theory, if you’re curious).[ii]

There seems to be a way to make Microsoft Word work with Git, but the easiest way to start working with GitHub is to draft documents using the Markdown language, which is basically a dumbed-down version of html.

To sum up, I’m willing to take the risk that this post will read like tech agitprop by predicting that Git/GitHub-like workflows and tools are inevitably coming to the legal world, and there are very good reasons to start using them right away to future-proof our skills set while potentially improving online collaboration on the drafting of legal content.

(As a belated Easter egg, I went out of my way to insert 10 completely unnecessary words in this post just because they contained the string “git”. My sincerest congratulations will be extended to the first person to list them all in the comments below. Using CTRL-F is considered cheating.)

________________________

[i] Of course, this is only the tip of the iceberg as there are many other version control software (see this) and repositories in the software development world. Mercurial is a popular alternative, or should I say competitor, to Git (and the difference between the two has been an agitated debate) and Bitbucket a frequently used repository. Also, while I talk in this post about the GitHub workflow – and the concept of “branching” – like something that absolutely everybody uses in the software development world, there are exceptions. Google, for instance, seems to operate some kind of prestidigitation to manage the work on their billions of lines of codes. I guess Google is always a different beast.

[ii] In the report, while unrelated to the present post, don’t miss the comments on the drafting of open scientific literature. See also this page where the book, and the general idea of version control for writers (as opposed to coders) is discussed.