Githubberment: 10 Years Later

I recently aimed to collect some thoughts related to Commonwealth and perhaps DAO-of-DAOs more generally, and referenced one of my old thought experiments, Githubberment. As I tried to search for a link to it, I found it's nearly been memory holed completely (currently still on this mirror). After realizing my age, and that this idea is now 10 years old, it seemed like I should re-post it here.

TL;DR: imagine digitized legislation that's version controlled on Github, leveraging a branching model paired with Github-like tools for deliberation and acceptance.

Githubberment (Unedited)

I've been toying with an idea and rather than have it die with me I thought I'd share it and see if there are any obvious shortcomings with it or ways to shape it into something more useful. It combines a transparent, versioned repository of public data, and a citizen engagement aspect to keep people informed with as much or as little data as they want.

The idea builds on the work and concept of MaMairie, a project by OpenNorth that allows users to subscribe to points of interest and receive updates for legislation, policy or budget changes that effect those points of interest. One of their biggest issues seems to be access to data, which is where this idea could play a role.

If you're not familiar with Git or Github this may not make sense. There are self hosted versions of Github so this could all exist domestically behind any firewalls with any ACL rules that are required. Ideally I'd want to find an open source alternative to Github but Github makes a nice illustration for the goals.

The idea is to essentially hold all public data in publicly accessible git repositories and then make use of git hooks to automate some tasks to distribute this data to interested parties for various purposes. I'll use the example of changes to legislation to show how I think this could work.

You could have a legislation repository, with the master branch being officially recognized legislation. For each session of parliament, a branch is made from the master branch, and for each bill, a branch is made from the session branch. Likewise, in an issue tracking system would create a milestone for the session, and issues for each bill, tied to the session milestone. These issues would be tagged with any relevant meta data to help organize what the changes represent. Any changes are committed to that branch, and the commit message contains a reference to a related issue number to have it automatically link to the issue. Approved bills would get merged back into the session branch and sessions upon completion would get merged back into the master branch as recognized law. This could be setup in any way to accommodate business rules such as requiring Governor General authorization through the use of pull requests and user permissions. This would all be performed through a client that simplifies the process and interacts with the underlying systems in the background so working knowledge of Git wouldn't be required by representatives, just training on the software developed for this purpose, nor would the process be as clunky as I've described because the software would handle the heavy lifting to ensure things are maintained properly.

Whenever something is committed, git hooks would notify the user engagement service that issue X has been created and changes proposed relating to it, and any users subscribed to any data points that relate to that bill (as determined by the tagging, and perhaps some string manipulation of the diff between versions) would be notified of the changes. They would be able to view the difference between the previous version of legislation and the new version. I'm imagining the data existing as both a JSON representation of legislation and a plain text description, with the hopes that the JSON representation could create a digital model of law, but even if it was just the bill's text it would be a huge improvement. Organization of this data is definitely something I haven't even attempted to figure out, nor would I want to have to.

The next step in the engagement system would be to allow users to upvote/downvote bills directly in a sort of poll, and provide a way for conversations to emerge with regard to proposed changes. This information could be visualized and presented back to representatives to give them an idea about feedback from their constituents or even a more broad view of the overall response so they can be more informed about people's opinions on various subjects and vote more in line with the people they represent. If the system sees that constituents are overwhelmingly against something, and the representative votes the other direction, it could also start a dialogue that allows the constituents to demand an explanation why they were ignored, perhaps flushing out corruption earlier on rather than ignoring it until it gets out of hand, or at least demanding a context for decisions. The nice thing about using a version control system as well is that at any point, if you wanted to challenge a law directly, you could reference its commit hash and remove/add any commits from the repository after a sanctioned vote if its determined to be invalid.

This system could be used for all public data. Ministry budgets, meeting minutes, video files from parliamentary sessions, etc, all existing in version controlled repositories that are cloneable by the public. Private repositories would also be easier to manage permissions to in a system like this that's made specifically for tracking data and by tying access to SSL certs you could essentially lock data down to certain machines as well, if they're managed in a way to prevent data being removed from them. Best of all, with the wiki system and GitHub pages, it could very well provide a way to get rid of the awful, disparate, and outdated Ministry websites that plague us now by organizing those sites around the data sets that drive their existence.

Also, via APIs this data could be exposed to applications that wish to make use of public data to build off of. I would love to see easy to use government OAuth services that applications can tap into for data. Ideally that would be built first and the user engagement system would become an application itself.

I'm sure there's a number of shortcomings and hurdles that simply make this impossible, but from what I can see most shortcomings seems to be with existing policy and the impossible task of government buy in and not the concept itself. I may pick it up as a hobby project at some point because it could be useful even if its not used in an official setting, but I would love any feedback on it.

Reflections A Decade Later

I still like it, and I still want to either see it get made start making it... 10 years later :\ lol. I'm still toying with this idea, and would still love feedback on it :). "I may pick it up as a hobby project at some point" gave me a good laugh... I now very much have.

In the modern age, the idea almost seems quaint with the number of DAOs proving out new models of open-governance, but I don't think we've yet solved for member participation or properly negated elite capture and arrived at unlocking the true potential of the DAO construct leveraging social capital at its core. It's a challenge I'm hoping to attempt to solve for in order to leverage it for my Commonwealth project, which is 99% a people project and will require a deep and thorough consideration of what it means to be a Citizen of a community and the rewards/responsibilities that come with that relationship.

Feedback welcome/encouraged on this now ancient but still relevant Githubberment idea, Commonwealth, and/or the loosely captured Capital Model & Social Insurance 2.0 components that make it up.