Reading this, I cannot help but think the response to this pandemic is playing out according to a fundamental tenant of Republican philosophy. Push power down closer to ‘the people’. Each school district, city/township, county, and state gets to decide how to respond to this virus. In other words, it’s a feature not a bug.
Personally, I think it’s important to have a strong federal government to coordinate things that impact everyone — environmental regulations, educational concerns, energy efficiency, public health. I hope people who push for decentralized government think about how chaotic our response is and extrapolate to how their preferred form of governance can react to other important situations, whatever those may be.
I always wanted to run for federal office on the platform of direct representation — more a technology than a platform. Develop a system that allows constituents to log in and vote for any legislation — basically like proxy voting for shareholders. I’d deliver summary and full text content of anything in advance of the vote, and I’d cast my vote as dictated by my constituents. And constituents could see the vote totals for each piece of legislation to prove that I am voting based on real input. Obviously, this platform suffers an immense privilege problem — it’s great for a demographic with free time to read through legislation and convenient Internet access. It also suffers a civic disengagement problem — does anyone actually want to read through the text of everything that’s coming up in my committees and to floor votes? It’s quite possible that I’d be voting against the National Law Enforcement Museum Commemorative Coin Act (H.R. 1865) because five people bothered to lodge an opinion … and only to troll the entire idea behind direct representation. And none of that considers the threat of malicious actors.
Once there is a platform available for one legislator, expending it to others in the same chamber is trivial. Adding the other chamber or state legislatures is an undertaking from a content-development standpoint (what *is* on schedule for the Oregon Senate today?), but the underlying development effort is the same. Somewhat like the National Popular Vote compact is an end-run around formalizing the eradication of the Electoral College, this would be an end-run around indirect representation.
But I’ve thought, of late, that starting at the Federal level is misguided — if for no other reason than the incredible amount of money it takes to run a campaign for federal office. But also because getting the six million or so Ohio voters set up for direct representation by their state Senator would be a logistical nightmare. It seems better to begin implementation at the local level — run for school board or a Township Trustee position where you are concerned about a few thousand voters. Use local offices as small proof-of-concept experiments. Maybe it doesn’t work out — maybe no one cares enough to check what’s being discussed and vote for their position. Maybe running and supporting the platform is too expensive or time consuming. Hell, maybe no one is interested enough in direct representation for a direct representation candidate to win in the first place.
I store a lot of code in Git-based systems, and I read through parts of my state’s Revised Code on occasion. But it never occurred to me to store the Revised Code in a Git-based system. Washington, DC has started doing exactly that.
First, some basic terminology from GitHub — a “commit” is a change. In this case, a change to the revised code text. An “Issue” is where someone points out a problem with the existing code or proposes an enhancement — in this case, someone either pointing out a typo or suggesting a new law. And a “Pull Request” (aka a “PR”) is used to accept a commit into the code — in this case, applying the change to the revised code text.
Imagine being able to comment on a pull request and have your commentary considered during the public hearings for the proposed change. Sure, there’s elitism to assuming everyone’s got a computer and time to peruse proposed changes. But not more than assuming everyone’s got an hour to head over to Town Hall and attend the public hearing. And resident-initiated changes could be proxied through a third party — city government staff, for instance.
The process could increase transparency — GitHub users can subscribe to get notifications when issues and PRs are entered into the system. An issue could be created when discussion over a proposed change begins. Links to public meetings and even discussion about the proposed changes could be available online. A pull request created by government officials finalizes the changes and commits them into the online revised code.
The git storage system retains history — a resident who is convinced an auxiliary building was totally in compliance of zoning regs when it was built could run through the history and identify exactly when the setback requirements changed.
Clicking into a specific “commit” will show you what changed — the left-hand column is the old version and the right-hand column is the new version. Something that was removed is highlighted in red; something added is highlighted in green.
From a procedural standpoint, there are some challenges. Their code is now maintained in XML, which isn’t necessarily something that will edit well in your favorite word processing program (Word, as an example, has some limitations when it comes to editing XML and, in my experience, generates really sloppy code — multiple style elements that all cancel each other out). Build automation is now a requirement of legal documents — a process that ingests changes to the XML and spits out an HTML web site or a PDF file. These challenges require someone with technical knowledge to maintain the revised code.
Logistically, it might be challenging to convince residents — especially those who don’t work as software developers — to use what is a software development tool to interact with local government. Even without citizen interactions, I think having a change history is an incredible advantage to using GitHub to store the revised code. It would be interesting to chat with the people who implemented this in DC and determine if (1) they get a lot of malicious submissions and (2) actually see citizens propose changes through GitHub.
Document retention implications would need to be considered as well — user comments, maliciously entered issues or PRs, etc may be undesired. It’s possible to restrict “interactions” (comments, issue creation, PR creation) to an approved list of individuals. But there’s an advantage to allowing residents to copy edit the code and to propose changes to code.
