Fork the Law | Hacker News Reader

Fork the Law

forkthelaw.org

7 pointsPyrrhuloxia12 comments

This needs a discussion medium more sophisticated than inline highlight comments.

For example: It is my contention that criminalizing noncommercial DOS attempts is highly inappropriate. They are a very good analogue for protected speech in the form of traditional protest picketing, trying to temporarily drown out and deny painless access. So long as an individual is only committing their own bandwidth to a pingstorm, this seems to me like something that should be handled as a tort. Torts have Constitutionally-limited punitive damages of ~9x demonstrated damages, fractionally allocated to the participants. A hundred thousand 4channers should damn well be able to pingstorm the Westboro Baptist Church's closet server into temporary unavailability.

Botnet-driven DDOS ordered by one person are very different beasts because they can have such a disproportionate impact, because they can be utilized for commercial goals, because they're operating from hijacked hardware, and because rent-a-botnet is common & thus more likely to ask for returns rather than be an expression of speech.

How would I go about making this change based upon consensus though?

It would also be useful, at least for me, to present the indentations implied by the outline-style lettering of bill-writing.

That's a high-priority forthcoming CSS fix, you just bumped it higher. Thanks.

I agree it's not the ideal UI. It's similar to what Darrell Issa's keepthewebopen.com was using with Madison, and to the marked-up texts that the EFF has produced as PDFs, but there's a cognitive jump (for me, at least) between "make a comment" and "propose a change".

Fundamentally, I want a user to be able to propose one or more changes by selecting a section of text and annotating it with a replacement. So there's a semantic difference between "comment" and "change". Furthermore, I also want to be able to easily select a changeset, then produce a draft output that integrates all changes from the changeset.

I think we can do this with co-ment's existing features and maybe a little bit of extra Django hackery, but before I go haring off into the internals, is this more like what you're thinking of?

Whole-heartedly agree with what they are trying to do, but I wish they were using a git repo rather than a text control that requires you to be online.

forkthelaw.org dev here. What you're seeing now is a weekend prototype using banged-together open-source projects, focused on a UI experience for people more on the tech-law end of the spectrum (the Jennifer Granicks and Cathy Elliott Joneses of the world -- in fact, Cathy's helping us out with alpha testing). It's also specifically focused on the CFAA for timing reasons: in just under three weeks, I and a whole bunch of my infosec colleagues will be in DC for ShmooCon, so we can all go visit our representatives while we're in the area anyway.

Over the next few days we'll be building out the site with more information about the upcoming ShmooCon lobbying trip as well as our feature roadmap. The short version is that we'll be pulling the entire United States Code into darcs, updating it via GovTrack's APIs, and providing a UI to select and fork specific sections of the law for people to collaboratively work on.

The site's going to change quickly in the coming weeks as we add more functionality. Maybe we shouldn't have launched quite this early, but there is a bit of a time crunch.

Edit: IAC, if you're interested in more DVCS-like, offline/command-line functionality, I'm totally down to support that. Tell me more about how you'd expect to interact with that?

How are paragraph references handled? I guess that whenever a paragraph is removed, other paragraphs linking to this paragraph need to be updated also.

Totally understandable if it makes the most sense for the people you see as your primary customers for this.

Out of curiosity, did this come out of the aaronsw Hackathon at Noisebridge this weekend?

[wish i had been able to make it there, but was unable]

Basically the way I view it is like this: we know that lawyers and hackers only have some overlapping domain expertise, but we'll need to work together in order to achieve good tech law reform and everyone's going to have to get out of their comfort zone to some extent. Whatever markup tool we deliver, a wide range of lawyers should be able to find it not too hard to use; hackers will be more unforgiving about a UI that has, say, latency issues (guilty look), but a good UI shouldn't have those anyway. Finding the right balance of user needs to satisfy with the resources we have available is of course going to be an ongoing process, so we're just gonna have to keep an active ear out for what people are asking for.

It sort of dovetailed with the aaronsw Noisebridge hackathon, but we started hacking on it independently about a day before. Christie, who's a Noisebridge member, realised the hackathon would be a good place to present it, and did. Via that, we met the http://hypothes.is/ guys, and things have continued to snowball from there :)

God no, don't do it in git. Otherwise no one outside of developers will ever look at it, and the whole point (as I understand it) is to bridge the tech, law, and politics worlds. So some of the primary users aren't developers and have probably never seen a command line.

Right. The current annotation UI, co-ment, does all of its versioning in a database. Distributed version control provides certain advantages over this, ones that we'd like to bring in quickly, but it's vital that we convey our goals to both non-technical and technical audiences.

We're actually partial to darcs for this particular use case (the patch model is closer to how laws are actually amended), which ironically may decrease traction on the command-line since everyone has such a hard-on for git these days. IIRC you can use darcs via git, though.

There's no conflict here. You can build it on Git/Mercurial/DARCS/whatever and make it easy for those who are capable to use the command-line or their favorite Git GUI, and at the same time have a visual interface that hides all of that under the cover (e.g. creates a branch when you begin editing). The hard part of this would be conflict resolution, but that's already a hard problem for an online editing system like this (and I didn't look at it long enough to see what the solution here is).

Reply on news.ycombinator.com