United States Code (federal laws) in Git(github.com)
github.com
United States Code (federal laws) in Git
https://github.com/nickvido/us-code
15 comments
In the 14 hours since that flagged post, the OP has changed _nothing_ in that repo to address the feedback people gave him, and instead decided to just resubmit his proj to HN.
A few years ago I was thinking about how one might do the same for Danish laws, but those are written by idiots (lawyers).
Rather than revising a law, a new one seems to be written using text like: The word "is" replaces the word "was" in line 5 and 6 in "Law on X,Y,Z, paragraf 8, section 5". Or "section 9 in Law on Q,V,W is removed, in favour of the following text".
Why the hell you not just rewrite the old law and bump the revision? After just two revision it's basically impossible to read the actual law. I think that's on purpose.
Rather than revising a law, a new one seems to be written using text like: The word "is" replaces the word "was" in line 5 and 6 in "Law on X,Y,Z, paragraf 8, section 5". Or "section 9 in Law on Q,V,W is removed, in favour of the following text".
Why the hell you not just rewrite the old law and bump the revision? After just two revision it's basically impossible to read the actual law. I think that's on purpose.
Isn't it just a lawmakers' version of diff? :) You just can't conveniently apply it automatically to compile the resulting text.
>Why the hell you not just rewrite the old law and bump the revision?
Because it's aimed at lawyers and judges who have to be up-to-date with all changes and its easier for them to remember "section 123 was amended in 2026", than to recall a whole new revision and mentally compute the difference.
It's also why you often can see skipped items (e.g. 1, 2, 4, 8, 9, 10). Because humans often think in terms of "<..> code, section 123", not "<..> code, revision 24, section 123, which was section 130 in revision 20", so when you remove a part, it's more efficient to leave an empty space and to not reuse it later.
>Why the hell you not just rewrite the old law and bump the revision?
Because it's aimed at lawyers and judges who have to be up-to-date with all changes and its easier for them to remember "section 123 was amended in 2026", than to recall a whole new revision and mentally compute the difference.
It's also why you often can see skipped items (e.g. 1, 2, 4, 8, 9, 10). Because humans often think in terms of "<..> code, section 123", not "<..> code, revision 24, section 123, which was section 130 in revision 20", so when you remove a part, it's more efficient to leave an empty space and to not reuse it later.
> Isn't it just a lawmakers' version of diff?
It probably is, and they are just stuck in the past not wanting to adopt new tools. You have people in tech reading chancelogs, or follow something like the openbsd-cvs mailing list. It feels like it would be easier if you did have have to look up a law, the search for amendments, which may or may not exist.
It probably is, and they are just stuck in the past not wanting to adopt new tools. You have people in tech reading chancelogs, or follow something like the openbsd-cvs mailing list. It feels like it would be easier if you did have have to look up a law, the search for amendments, which may or may not exist.
There's an interesting side effect to the current state of the non-technical world.
We have some new tools that increase productivity, and these same tools both lower the barrier to entry to understanding software concepts and building software.
I think the result is more people who would've been traditionally considered non-technical are going to be onboarding to concepts that wouldve been traditionally ring fenced in the developer world.
Granular version control and diffs being one of them.
If this trend is real, and relatively large, I think it will be a good thing.
We have some new tools that increase productivity, and these same tools both lower the barrier to entry to understanding software concepts and building software.
I think the result is more people who would've been traditionally considered non-technical are going to be onboarding to concepts that wouldve been traditionally ring fenced in the developer world.
Granular version control and diffs being one of them.
If this trend is real, and relatively large, I think it will be a good thing.
Yeah in the legal world they’ve had the concept of “track changes” forever but there simply isn’t something like branching and merging.
Like branching a document for a particular negotiation. Or branch it when adapting it to a new jurisdiction’s laws, etc.
It would benefit so much from that workflow or mindset.
Like branching a document for a particular negotiation. Or branch it when adapting it to a new jurisdiction’s laws, etc.
It would benefit so much from that workflow or mindset.
This would be more interesting if the commits would list everyone who voted "yes" as authors.
Is there one for the Statutes at Large?
hot take: this is how legislation should work
open comments, accepting pull requests, use AI tooling to weed out the ragebait and trolling for things that might actually be useful
open comments, accepting pull requests, use AI tooling to weed out the ragebait and trolling for things that might actually be useful
The level-headedness of direct democracy meets the accountability of anonymous internet commenting!
The vocabulary of this sentence is inconsistent with section 204 [0]. It is the positively enacted titles which are "legal evidence of the laws". The other titles merely "establish prima facie" what the law is, subordinate to a closer examination of the bills actually passed, which control. In other words, "evidence of law" is the stronger of the two, not the weaker, as the readme suggests.
[0] https://www.law.cornell.edu/uscode/text/1/204