I store a lot of code in Git-based systems, and I read through parts of my state’s Revised Code on occasion. But it never occurred to me to store the Revised Code in a Git-based system. Washington, DC has started doing exactly that.

First, some basic terminology from GitHub — a “commit” is a change. In this case, a change to the revised code text. An “Issue” is where someone points out a problem with the existing code or proposes an enhancement — in this case, someone either pointing out a typo or suggesting a new law. And a “Pull Request” (aka a “PR”) is used to accept a commit into the code — in this case, applying the change to the revised code text.

Imagine being able to comment on a pull request and have your commentary considered during the public hearings for the proposed change. Sure, there’s elitism to assuming everyone’s got a computer and time to peruse proposed changes. But not more than assuming everyone’s got an hour to head over to Town Hall and attend the public hearing. And resident-initiated changes could be proxied through a third party — city government staff, for instance.

The process could increase transparency — GitHub users can subscribe to get notifications when issues and PRs are entered into the system. An issue could be created when discussion over a proposed change begins. Links to public meetings and even discussion about the proposed changes could be available online. A pull request created by government officials finalizes the changes and commits them into the online revised code.

The git storage system retains history — a resident who is convinced an auxiliary building was totally in compliance of zoning regs when it was built could run through the history and identify exactly when the setback requirements changed.

Clicking into a specific “commit” will show you what changed — the left-hand column is the old version and the right-hand column is the new version. Something that was removed is highlighted in red; something added is highlighted in green.

From a procedural standpoint, there are some challenges. Their code is now maintained in XML, which isn’t necessarily something that will edit well in your favorite word processing program (Word, as an example, has some limitations when it comes to editing XML and, in my experience, generates really sloppy code — multiple style elements that all cancel each other out). Build automation is now a requirement of legal documents — a process that ingests changes to the XML and spits out an HTML web site or a PDF file. These challenges require someone with technical knowledge to maintain the revised code. 

Logistically, it might be challenging to convince residents — especially those who don’t work as software developers — to use what is a software development tool to interact with local government. Even without citizen interactions, I think having a change history is an incredible advantage to using GitHub to store the revised code. It would be interesting to chat with the people who implemented this in DC and determine if (1) they get a lot of malicious submissions and (2) actually see citizens propose changes through GitHub.

Document retention implications would need to be considered as well — user comments, maliciously entered issues or PRs, etc may be undesired. It’s possible to restrict “interactions” (comments, issue creation, PR creation) to an approved list of individuals. But there’s an advantage to allowing residents to copy edit the code and to propose changes to code.