Scott came across a video where some cop in Florida rips into this lady who drive for about a mile after he put his lights on — along a dark, uninhabited road — to stop at what looked like a petrol station. It was odd because I had an uncle who worked in law enforcement and I distinctly remember him saying to get somewhere well lit and around people before pulling over. Put on your hazard lights, drive slower … but get somewhere in public. And visibility helps the cop too — they can see that the blob in your hand is just your purse.
The video had some text at the bottom that said the deputy involved had resigned … but that could mean he resigned before the department was able to investigate the incident, got a job elsewhere, and is out there right now hassling some other person who simply made the prudent decision to stop their car in a safer spot.
Which made me think about some of the Township meeting — when someone from the fire department or police department resigns? They don’t just say “hey, I’m not gonna be working after Friday” and that’s it. They submit a resignation. The resignation is then submitted at the Trustee meeting — and the Trustees vote to accept the resignation. It seems like we could better unsure officers are held accountable for their actions by not accepting resignations if there is any outstanding complaint against the individual tendering their resignation. Wait for the complaint to be resolved — maybe it was nothing and they can resign. Maybe it bears an investigation. But there’s no leaving to avoid accountability.
I had downloaded some PDF files of the county survey books after we first bought our house. We wanted a little more info, but were completely unable to find where I’d gotten the survey book pages. Fortunately, a very helpful individual at the County Recorders office knew what I had and exactly how to get there. Figured I’d write it down for the next time we want to pull up survey information. The trick is to not use the new Medina County GIS website.
From the drop-down menu hidden between the red bar and an text input and select a search type (Parcel Number, Address, Owner Last Name)
Click Query/Refresh
You will now see information about the searched parcel and a map. Scroll down.
From here, you can access a bunch of different information – for the survey books, select “Scans”.
There’s a lot of information available. In the Surveys, there’s a cool feature — the top part of the page contains a portion of the document and a light gray outline showing the searched parcel — when you cannot figure out why a particular page shows up when your parcel isn’t involved — look for a tiny portion of your parcel that’s technically on the page. In this example, a few feet of our lot appear under the information block. There are a few pages where the little section of land on the public right-of-way appear somewhere along the bottom portion of a scan. I expect they’ve got the corners of each page tagged with geographic information & your scan query retrieves anything where any of your lot falls within those bounds. Survey and tax map go back over a hundred years, and it’s neat to see how the property lines have changed (and not changed). Plus, I now know Bellus Rd was named after the family that owned the farm across the street from us.
Since I’m writing down where I’ve found important documentation … I’ll add:
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.
