With a 2,000 page bill, it would make it easier to keep up with the changes, even if you don't yet know what is in every page at the start.
In College, I did spend some time wondering if a good Robert's Rules meeting running software might be a generally useful project, after being in a few society meetings where branches got long and twisty (amendment to an amendment to a proposal type things). Never did build anything more than a prototype though.
Seek out Thomas Jefferson's Manual for those clubs you'd like to see thrive. It promotes fraternity. https://en.wikipedia.org/wiki/Jefferson%27s_Manual
It would be an interesting project. Particularly if you could also wrap up the git in an interface that's accessible to non-programmers.
As far as the US goes, the Federal Register is a good place to start to see things as they happen.
What I think is missing is a concept of document: commits (laws) just accumulate on top of each other without producing named, organized documents (files, in proper source control systems) with clear responsibilities, that can be easily referred to from other documents, and of which the latest version is the only one that counts.
Instead, when you want to read a computer program, you don't look at individual commits to the code base, you look at its files. Commits are more or less irrelevant, what counts is the most recent version of a set of documents, and each commit might create, modify or delete more than one document.
It seems only a change in perspective, the end result is the same; but reasoning in terms of documents with well-organised names and responsibilities, describing processes and data and designed for reusability, is much easier and more compact.
It's still full of references to bills and such, but it is the consolidated text of the law.
has lots of intersting proposals and attempts
I guess the main blocker for this would probably be the formatting used to produce the documents. It would have to be a human readable markup language of some kind. Does anyone know what the standards are for, for instance, contract generation, in the legal industry? Are markup languages etc used or is it mostly just MS Word -> pdf?
On the flip side, DMS have far better tools for file preview, search, tagging, etc., and better integration with Microsoft Word and Outlook. These features are very important to lawyers.
Word and Outlook are defacto business tools for sharing legal documentation but oftentimes they are blunt instruments. I see mistakes or delays due to poor tooling all the time. E.g. the wrong versions are emailed, or each party's attorney makes their changes into a different copy of the document, the document becomes corrupted and needs to be copy-typed (I've never gotten to the bottom of what corrupts a document, other than to note it seems to be related to heavy commenting and track changes), or even just unproductive time needing to make simple updates across tens of files.
A github equivalent for lawyers would be fantastic. In fact I think it could be a killer app for the legal industry if it were possible to convince a quorum of big firms to move to it. Think: issue logging per substantive issue; pull requests for changes linked to each issue; full history of each lawyer's changes etc. Roll in some IDE for contact drafting with syntax highlighting, hinting, automated refractoring etc. All these technologies would be just as useful for lawyers as they are for developers.
If a small team of developers were to build a simple web app the way lawyers draft legal documents, it would look like this:
1. Developer 1 writes up the initial JS, CSS, and HTML files and emails them as an attachment to Developer 2.
2. Developer 2 prints out the files, edits them via hand markups, sends the printouts to his secretary to mark up electronically, and then emails the files to Developer 3.
3. Developer 3 repeats step 2 but emails the files back to Developer 1.
4. During this whole process, while one developer is working on the app, the other developers are waiting idly - even if they could be working on a separate part of the app with no risk of conflict.
This is a simplified explanation and lawyers will have some degree of version control internally through software like i-manage, but I find it hard to believe this process couldn't be improved significantly. I’ve been seriously considering starting a company in this space.
Often it becomes unclear who has edited what and when, and its exacerbated by the fact that many lawyers still prefer to mark-up documents with pen and paper and have them updated later by their secretary (while in the meantime the document will have gone through another round of markups from other lawyers in the team).
I don’t know if an automatic merge is the right solution either, but I can absolutely see the value in software that helps manage this mess. I realise it might be different in litigation, because in this case we’re not trying to draft a coherent legal argument but tick off a series of regulatory checkboxes that are semi-independent from each other.
A specialist contract markup language with a nice lawyer-friendly IDE would be ideal, but would need serious marketing $$$ and lots of patience to achieve broad adoption.