b-screeds
These days, people are sticking legislation into GitHub at a furious pace. It is all the rage among the legal-information smart set. The whole thing seems to have started about fifteen months ago with a quote from a toiler in the vineyards of the New York State Senate, written up in Wired, the Boy’s Life of the technorati. Said he: “I’m just in love with the idea of a constituent being able to send their state senator a pull request”.
I could speculate hilariously as to what some of our scandal-ridden New York State Senators might think a “pull request” is, but that’s neither here nor there. A lot more people appear to be just in love with this idea, too, because in the last year there has been a rising tide of legislative gittification here and elsewhere around the globe. I myself am just in love with the name of the German “BundesGit” project, which the smart money is putting at 5 to 1 to win the Greatest Cognitive Dissonance Packaged in a Compound Word category at this year’s Noamy Awards.
Trouble is, I’m not so just in love with gittification as everybody else seems to be. Here’s why:
Git and GitHub are, collectively, a fine revision-control system, and a good system for distributing and managing open-source coding efforts like the ones at https://github.com/unitedstates. Unfortunately, straightforward revision and versioning are not really what happens with most legislation hereabouts. American Federal legislation is not a straightforward revision process at all. That is especially so when post-hoc codification results in an issue-centric bill being splattered all over the topical map of the US Code. Other jurisdictions — notably civil-law countries — at least pretend to have a more rational process for legislative revision, though I am told that in practice it is not so pretty as all that. They are, by and large, having some success with FRBR-based models which closely resemble revisions control, but for a number of reasons those don’t work as well as they might for Federal legislation. Simple processes in which a single version of text is successively modified and the modifications absorbed into a series of versions and branches are not quite enough to map the eddies and backwaters of our process, in which multiple competing drafts of a bill can exist at the same time, bills can be reintroduced in later sessions, and so on.
I am far from the first person to make this point. Others have done so very effectively right along, but the story does not end there. The beauties of revision management do not explain why we are hearing so much git-love. There must be more to be just in love with than the idea that you might keep track of changes in the language of a bill.
I think there are three pieces to it, really. One is the idea that somehow the gittification paradigm describes what the system *ought* to be, and represents the aspirations of its proponents; one is the idea that putting law in github somehow magically puts ownership of the law where it belongs; and one is the idea that gittification is somehow democratizing.
As to the first, everybody would like a simpler system. Belief that putting the text into a particular instrument could or would bring that about is a species of wistful, wishful thinking that is the unique province of technicians. Technical people of all stripes believe that about a lot of things — the idea that somehow just having the right tool changes both the materials and the quality of the workmanship are an understandable and appealing part of the romance of geekdom. And sometimes a change in tooling brings about an unmistakable and positive change in way things really are. I am thinking, for some reason, of the invention of interchangeable parts, which obviously brought about vast changes in manufacturing and ultimately in everyone’s standard of living — and also gave rise to a crop of industrial utopias founded in the belief that virtue would flow from industrial organization: the Ephrata Cloisters and New Harmonies of more a century-and-half back.
I’m OK with certain amount of techno-utopianism; a lot of good ideas got their start in those cloisters. But the romance of gittification is part of a more expansive intellectual conceit — the idea of law as code. Lessig brilliantly described idea of code (and technology generally) shaping behavior and potential in ways traditionally reserved for law. But code-is-law is not reversible into law-is-code. There are lots of reasons why not; some are facets of the process by which law is created, and some have to do with how the language works and what it is expected to do. Law is nowhere near as deterministic or precise as code and the process that creates it is a lot messier. There is often carefully calculated imprecision in statutes and regulations. Geeks don’t like that, because they want law to be more computationally tractable, and they often say so loudly in the same forums where legislative gittification gets a big round of high-+1s. Imprecision has a very valuable purpose in law, where flexibility of interpretation is often desirable, and not so much in code. If you want to know what “law is code” looks like, consider the rigidly precise algorithms of the Federal sentencing guidelines, or the “three strikes” law, and tell me if it looks like Utopia to you.
But I’m just being cranky, sorta. There’s nothing wrong with romance, even if it is unlikely to produce meaningful change, so long as we avoid confusing it with having actually caught the unicorn. There is also a lot that is admirable about a community wanting ownership of the law that it is expected to live by. The slogan of SwaziLII — an open-access legal publisher in Swaziland — is “kwetfu” . It means “it is ours”. In South Africa, visitors to Johannesburg are shown, with great pride, the public monument to the 1994 Constitution. It’s important that people feel ownership of the law. Postcolonial societies feel it strongly, and they celebrate it and they build monuments to it. Geeks stick things in github as a way of claiming it for their culture. In that respect gittification is a symbolic act that says a lot about where we are in 2013 and why. I respect the symbolism, and think it’s a shame that we have been collectively driven to such a need to reassert ownership. I just don’t want to confuse the symbolism with something that improves the substance.
But what about democratization? We may be just in love with the citizenry submitting pull requests, but that doesn’t mean the citizens have any idea how. And it is a little disturbing to think that we might be subconsciously restricting our definition of citizenship to those who can submit pull requests. I say that mostly for effect — I don’t think that anyone is being consciously elitist here. But I do think that many of the same people who celebrate gittification also routinely (and loudly) condemn government behavior that is unwittingly exclusionary in exactly the same way that GitHub is. It’s natural for technicians of all stripes — whether they are legislative, political, and policy wonks, or people who frequent hackathons, or all of the above — to become so acclimatized to their own technical knowledge and environment that they forget that others just don’t have a clue about any of that stuff, and are effectively shut out. The biggest problem with legal information has always been that the people who create it have no reason to realize that there is a problem with access, because they themselves have it. And in that respect the Gitterati are no different.
Once upon a time, regulations.gov was useless if you didn’t know a lot about what agency regulates what. Today, you can’t be a citizen of New GitHarmony if you don’t know how to turn the knobs of GitHub. That’s not an argument against making systems that permit citizen participation in the legislative process. I’ve never liked the sort of don’t-bring-gum-to-school-unless-you-bring-enough-for-everyone, digital-divide arguments that some use to bludgeon Internet projects. You have to start somewhere, and maybe it’s worth remembering that we haven’t shut down the libraries because the basic literacy rate in the US is under 100%. But don’t imagine for one moment that an average constituent is going to submit a pull request. And think about who you’re really speaking to. As of January, 2013, the population of the United States was estimated at 315,968,000. GitHub claims 3 million users, not all of whom are in the US. Sounds an awful lot like the 1 percent to me.
A great article–however,
“…in which multiple competing drafts of a bill can exist at the same time…”
This is precisely one of the (many) things git does well: http://git-scm.com/book/ch3-3.html
If millions of barely sentient corporate/government drones can use Microsoft Sharepoint everyday to manage revisions, it’s hard to believe an average person couldn’t submit a pull request using github, especially when github has already implemented the ability to edit files on the website and transparently submit a pull request on the editor’s behalf.
I can’t seriously dispute the idea that our legislative process is too obfuscated to take gittification out of the realm of pie in the sky, but the idea that it’s precluded by technical challenges? Questionable.
Thom:
Point taken, but unfortunately you catch me in an airport which has installed the greatest proof ever that technology is more difficult than we think: auto flush mechanisms in the rest rooms.
As it stands now, Github is daunting, and highly optimized for the technically minded. But this is clearly and steadily changing – Github has made it possible to do nearly everything inside the browser, their Windows and Mac apps are high quality, and they’re constantly reinventing their UX.
Then you have efforts like Prose.io that make it possible to edit and propose a change to a White House document in a very nice editor, without ever hearing the word “pull request”. Something like half the closed PRs for Project Open Data are generated by Prose.
Everyone’s new at this. What people have clearly identified is that the collaboration model behind Github is powerful, in a way that transcends code. Now both Github staff and users have to figure out how to make the barrier lower and lower, and the process more inclusive.
From my experience, a big part of this is just convincing people to give it a shot. (I used to have friends tell me “Isn’t Android only for developers?”) I’ve been evangelizing Github to the non-technical parts of Sunlight, and all it really takes is getting past the “Are you sure I’ll be able to do this?” hump.
Tom,
Great thought-provoking post. I think that the best two sentences were:
I think that this is an argument for getting the technology right (usable) rather than an argument against the notion that any technology can make the process of legislative drafting better. I’m trying an experiment over at openpacer.org. (As you can see, I quite literally turn the “Law is Code” phrase around, and I don’t apologize for it!). I’ve got bill drafts and paragraph-by-paragraph commenting. This is theoretically simple, straightforward, and much more accessible than git pull requests. I then try to take the feedback in those comments and manually convert this into changes to the bill text. I have the code (written in Legislative XML) checked into github, so these changes are transparent. My current paragraph-by-paragraph commenting system has some UI quirks that are unfortunate, but I think that the principle makes good sense.
I’ve considered moving over to to the Github Pages approach used by Project Open Data. In that case, there is a WYSIWYG approach to submitting proposed changes, but it’s still not optimally usable (and I’d need to do some kind of markdown-to-LegXML conversion if I want to have LegXML).
So, yeah, you’re being cranky. But making good points. My takeaway is that the technology needs to be more accessible, and that people working on this need to share best practices.
I don’t know why you talked about the codification process in the beginning. Who cares that bills get spewed all over the US Code once they’re passed? We want to write the initial bill. What LRC does with it after the fact is mostly a non-issue.
Tom,
I wonder if the gittification of legislative processes isn’t a classic example of a solution in search of a problem.
The problem is that there is no problem (in the most general sense) with the legislative process in most cases. The problem is our political environment. When political imperatives (or, perhaps, fetishes) forbid the give & take that is required to make sound legislative decisions, no amount of gittification is going to change the outcome (or lack thereof). If only the process, as opposed to the participants, were the problem; solutions would be “git” easy.
Best practices? A better UI? How about we just dump politics as we know it and randomly draft citizens to participate in a legislative term. Then process could trump politics.
Until that imaginary event happens, you are absolutely right: this smells like another bit of elitist perfume that can hardly cover the stench of real politics and real legislative failures.
Plus 1 for the phrase “stench of real politics.”
Let’s not confuse Git with GitHub. Git is wholly capable of handling the technological requirements behind the storage of drafts of bills and versions of laws. GitHub’s UI is inappropriate for most users, but that’s because GitHub is for programmers, not for lawyers or activists or legislators. There’s no reason why Git couldn’t back any number of interfaces or programs (e.g. Microsoft Word’s “Track Changes” feature) in a manner invisible to the user, but facilitating some powerful and useful tasks.
[…] as Bruce Thomas points out in a recent B-Screeds post over on Cornell’s Legal Information Institute, “people are sticking legislation into GitHub […]
Tom: This morning I realized that you were channeling Jamie Zawinski on the CADT Model in this post. 🙂