How the Law is Represented in Brooklyn Community Board 1

What the hell are bylaws, anyway?

Bylaws are rules made by a group to govern the group’s operations. Basically, it is a group’s constitution, it is the law that binds that group, and its members, officers, and functions. Bylaws often cover topics such as the composition of the board of directors, the process for electing officers, how meetings are conducted, and the rights and responsibilities of members. Bylaws are often legally binding (they must be followed, at risk of legal consequence). They are, literally, the law.

Bylaws govern a group, after it is established

The law has interesting properties that make it very much like a computer program. And like computer programs, there are better and worse ways to represent them. There are better and worse [languages for drafting and editing them, ways to store them, ways to compile them, ways to implement them, ways to execute them, etc.]

Let’s look at some similarities between the law and a computer program and some questions they might bring up:

• The law has a more or less formal syntax (though it is sometimes undefined, or even contradictory, a bit like Javascript)

  • So does this mean we can construct an abstract syntax tree for the law?

    • Perhaps the DC-Law project is a good place to start on this question, or BLawX, a visual language built as part of the “Rules as Code” initiative

  • Unlike computer programs, the law is frequently ambiguous (e.g. there is no correct interpretation, or there are many possible correct interpretations).

    • It seems that in many cases this is a feature, and in many cases it is a bug. Perhaps we should be more intentional about when/where we use ambiguity in the law, and computer programs CAN help us model that.

• The law is a set of compiled documents, and has changesets (aka. Bills)

• The law is written and amended by humans who can introduce bugs (e.g. unintended bad consequences of amending a complex system)

  • Can we create Unit Tests and Regression Tests for changes to the law by “mocking” the actual implementations using simple simulations?

  • Can we create better tools for catching bugs before they go to production (continuous integration, responsive editors, or even just good version control?)

I live in Brooklyn CB1, which has Bylaws. Here they are (below). On the left you’ll find the copy that is available to the public, neatly hosted on the Brooklyn CB1 landing page. On the right is a copy that

Daniel Golliher

, a friend and fellow resident of Brooklyn CB1, edited to be more readable.

Left: City's Format | Right: Daniel Golliher's Format

Already we can see that there is room for improvement on formatting. This is a common problem for document type data — style and structure should be separated. The way this is solved on the web is by keeping HTML (document structure) separate from CSS (document style), so any custom stylesheet can be used to render the document more accessibly or more beautifully.

I also want to point out that “the law” doesn’t need to be stored as a document at all. It is, at its core, structured logic and rules. In other words, it is a program, and storing that program as a PDF without any open file-type destroys our ability to interpret those rules with a computer. If we represented the law in an open, computer-readable way, then passionate citizens could build any number of applications on top — making the law more accessible, flagging contradictions in the law, or running simulations of proposed changes to see what effect they might have before they are passed, to name just a few, and that would make me very happy.

My goal is to show how this might be possible using my own Community Board’s bylaws as an example.

But more on that next time. Stay tuned.