Ask HN: How would you manage the law using version control?
4 comments
This is a strange question because, more or less, it is already the case that the law is version controlled. In fact, version control predates the invention of computers and is found in the practice of legislative bodies going back hundreds of years. At the end of this I'll make a suggestion about how version control computing technology can contribute more, though.
Bodies of law (e.g., the Berkeley municipal code, the CA state code, or the federal code) are organized into various titles, divisions, chapters, sections, subsections, subsubsections and so forth. Each body of law is a kind of multi-volume publication, structured that way.
Legislation - the acts passed by legislative bodies to modify the law -- are expressed as patches (diffs). Legislation says things like "In title X, division Y, chapter Z, section M, subsection N, strike the words "blah blah blah" and insert the words "blather blather blather". That's a patch. Each act of the legislature (that changes law in this way) is a patch. The law is version controlled. (In fact, there's an important role in government for the archivists who receive these patches, apply them, and keep the official record of the "trunk" branch of law up-to-date.)
Beyond that: records of these patches are kept meticulously. If you have the record at hand, and you are reading some sentence somewhere in the law -- the record can show you all the past "diffs" that led up to the sentence as it currently stands.
It gets even better. Legislative bodies keep archived records of their discussions and proceedings in the course of passing law. Think of these as "comments on a commit". When you are looking at a passage in the law, and want to study its commit record -- it's all there for you. In court, this is called the "legislative history". The legislative history is not itself part of the law but, as with commit comments, courts sometimes find that commentary helpful for understanding "the code".
Fancy (mostly but not always for-pay) interfaces to law on-line actually let you explore these diffs and comments pretty directly as you read the (legal) code.
I'm not sure what the state of the art is for software in support of legislators and lobbyists -- that is to say, for the "programmers" that write and submit "patches" to law.
So my suggestion is that you do competitive research on all the on-line viewing and authoring tools, look at what capabilities they offer that seem important, develop free software alternatives that use version control concepts to help expose and make a nice interface to the version controlled structure that is already there -- and then (if you are trying to build a business) -- work on a plan to populate your software with data (not easy or cheap) and sell services atop that.
In addition to the moral reasons you should make it a free software project, a good business reason is because the market is already crowded with expensive proprietary solutions. So you can make a killing by shrinking an N-billion dollar market to be much smaller -- but much more owned by you (the shrink-the-market "Red Hat trick" for unix-on-the-server that, per the mythology, largely killed Sun and raised Red Hat).
Bodies of law (e.g., the Berkeley municipal code, the CA state code, or the federal code) are organized into various titles, divisions, chapters, sections, subsections, subsubsections and so forth. Each body of law is a kind of multi-volume publication, structured that way.
Legislation - the acts passed by legislative bodies to modify the law -- are expressed as patches (diffs). Legislation says things like "In title X, division Y, chapter Z, section M, subsection N, strike the words "blah blah blah" and insert the words "blather blather blather". That's a patch. Each act of the legislature (that changes law in this way) is a patch. The law is version controlled. (In fact, there's an important role in government for the archivists who receive these patches, apply them, and keep the official record of the "trunk" branch of law up-to-date.)
Beyond that: records of these patches are kept meticulously. If you have the record at hand, and you are reading some sentence somewhere in the law -- the record can show you all the past "diffs" that led up to the sentence as it currently stands.
It gets even better. Legislative bodies keep archived records of their discussions and proceedings in the course of passing law. Think of these as "comments on a commit". When you are looking at a passage in the law, and want to study its commit record -- it's all there for you. In court, this is called the "legislative history". The legislative history is not itself part of the law but, as with commit comments, courts sometimes find that commentary helpful for understanding "the code".
Fancy (mostly but not always for-pay) interfaces to law on-line actually let you explore these diffs and comments pretty directly as you read the (legal) code.
I'm not sure what the state of the art is for software in support of legislators and lobbyists -- that is to say, for the "programmers" that write and submit "patches" to law.
So my suggestion is that you do competitive research on all the on-line viewing and authoring tools, look at what capabilities they offer that seem important, develop free software alternatives that use version control concepts to help expose and make a nice interface to the version controlled structure that is already there -- and then (if you are trying to build a business) -- work on a plan to populate your software with data (not easy or cheap) and sell services atop that.
In addition to the moral reasons you should make it a free software project, a good business reason is because the market is already crowded with expensive proprietary solutions. So you can make a killing by shrinking an N-billion dollar market to be much smaller -- but much more owned by you (the shrink-the-market "Red Hat trick" for unix-on-the-server that, per the mythology, largely killed Sun and raised Red Hat).
This will never happen, but...
1. Rewrite all the laws in Prolog/a dedicated expert system. The interesting part is defining all the input variables, hence creating a new way of "legal structuring" data that would be reused in nearly all software and eg terms of services.
2. Because laws are somewhat deeply correlated, I would not try to version control parts of the law. One law change/batch of laws changes (1 per day ?) = one new global revision (you can diff, and with the law there is normally no reverting involved)
That would be fun for jurists and lawyers, playing the "what if" game with instant proved results :)
1. Rewrite all the laws in Prolog/a dedicated expert system. The interesting part is defining all the input variables, hence creating a new way of "legal structuring" data that would be reused in nearly all software and eg terms of services.
2. Because laws are somewhat deeply correlated, I would not try to version control parts of the law. One law change/batch of laws changes (1 per day ?) = one new global revision (you can diff, and with the law there is normally no reverting involved)
That would be fun for jurists and lawyers, playing the "what if" game with instant proved results :)
That prolog idea was fashionable around the late 1970s or early to mid 1980s, briefly. It was one of the real-world case studies that helped people figure out, back then, that it could never even begin to work at all well and, in fact, the thinking of AI researchers at the time was correspondingly not specifically good.
That's part of why you don't program in Common Lisp all the time.
That's part of why you don't program in Common Lisp all the time.
Well, first of all, I wouldn't, because Congress would insist on using Microsoft Source Safe, backed up to Zip drives. Talk about a corrupt Congress ...
Particularly with respect to these things:
- file and directory structure
- the role of submodules
- forks vs. branches
- user interfaces