Main Content

Architecting Information for an Open Source Citizenry

About the Talk

March 23, 2018 2:15 PM

Chicago, IL

Chicago, IL

"Part 1: Software and Law - Cousins

Software is a complex system, often engineered by a coalition of highly trained individuals who sometimes work on just the individual pieces, apart from the whole. Moreover, the average layperson finds it difficult (or impossible) to determine whether the software will affect their lives until the software is translated into a working product.

Law is similarly complex. The average bill may only be about 15.2 pages in length, but some like the recent healthcare bill are over 1000 pages and riddled with legalese.[1] This results in bills inscrutable to the very citizens that need to understand the legal consequences to their daily lives. Given the haste and often secrecy with which recent bills have been pushed, public contribution and comment becomes nearly impossible.

If source code and law share so many similarities, why have we been so slow to successfully apply decentralized open source process models for delivering software to the legislative process models for making bills into law?

Part 2: The User Experience and Information Architecture of Open Source Software

Open source software relies on community support. Support can be defined by two categories:

  • Consumption: communities of interest use, evaluate, report defects, and suggest new features. * Contribution: people within a community of interest not only consume the software, but also work some aspect of the product itself, from coding to marketing.

But how has the community around open source been enabled to do both of these core components?

That’s both a question of need and enablement via user experience.

Software engineering is global. Engineers, designers, reviewers are distributed widely around the world and great ideas aren’t limited to those who may be co-located.

The creators of GitHub met in 2008 in SF. It was there that they crafted the first version of their platform that would eventually become the largest source code repository in the world, and the go-to home for open source collaboration. Coming up on their ten year anniversary, the community has grown to almost 20 million users, 57 million repositories, and 100 million pull requests[2]. How did they get that big and why did it become the favored way to collaborate on code?

That’s down to user (or developer) experience.

Designed by developers, for developers, it’s not that surprising that GitHub has created a UX that speaks fluent coder. The IA of the system is all centered around the code repository. Using an elegant model and a system of sophisticated integrations, the system not only functions as a place to host code, but it encourages and enforces documentation, code review, code quality and collaboration by keeping the repo at the center. We will cover in some detail how this IA is structured and why it has been so successful.

Part 3: The Open Government Initiative

The stated goals of the open government initiative are:

  1. Transparency: Making government information available to the public is a requirement for an informed citizenry and an accountable government.
  2. Participation: Democracy requires opportunities for participation and collaborative problem solving whenever possible; this is at the core of democratic governance.
  3. Accessibility: A government serving all its people needs policies which provide maximum information accessibility and maximum inclusion in participatory processes.

While we’ve seen some strides in the transparency part of this equation, participation, especially in our current political climate, continues to be slow.

For example, the city of Chicago has it’s own GitHub repository where citizens can access open data in the form of JSON files[3]. And GitHub itself in 2012 reported that 350 repositories on their system were tied back to government agencies. [4]

What we see though is that these repositories are mostly about transparency of data. Which is wonderful, but still misses the boat on points 2 and 3 above.

There have been efforts to engage the public in this way. Notably in 2007 when the New Zealand Police Commissioner put the widely criticized 1958 Police Act online as a wiki and invited people to edit it. Again in 2009, Melbourne city government set up ""Future Melbourne,"" a wiki for residents to collaboratively engage in drafting the city's official ten-year plan. [5]

In the US, the only notable effort to truly engage in this kind of open collaboration on a bill was spearheaded by Senator Ron Wyden (D-OR) and Congressman Darrell Issa (R-CA) in 2008 in the wake of the SOPA bill. They sought to create a system where the public could collaborate on a new version of the bill (OPEN). This system, Madison, is still up and running, but the level of collaboration has been low even in the beginning, and has not grown in the intervening years. [6]

We will also examine the US’ commitments to the open government partnership, particularly commitment 26: Civic engagement in decision-making processes. A commitment with no leading institution, start or end date. [7]

We propose that this is due to user experience. We will examine Madison in detail and demonstrate where the IA fails to encourage participation. We will also cover interview results from conversations with people working in open government today.

Part 4: A GitHub for Open Legislation

Despite the similarities we introduced earlier - the people that craft laws are not the same as the people who craft software. Because of that, the information architecture and user experience of GitHub does not translate smoothly into collaborating around legislation.

What we need to do is what designers and information architects do best: create a new design, centered on the users of our new system.

Who would the users of this new, law-centered, GitHub be?

  1. Legislatures: our elected officials - tasked with passing laws that protect the integrity of our society
  2. Lawyers: the individuals who will be tasked with understanding laws & supporting them in the courts.
  3. Activists: individuals who are campaigning to bring about political or social change.
  4. Lobbyists: special interest group advocates with the intention of influencing government decisions.
  5. Citizens: the individuals who will ultimately be impacted by the passed legislation

Interview research conducted with each of these personas will be shared in order to establish an understanding of user needs. This will help segue into our next topic: the IA of our new proposal.

This IA will be centered around the concept of a “bill” rather than a code repository. The architecture we present will seek to create a safe space for all five of these personas to collaborate on the creation of legislation.

Part 5: A Call to Action

What we’ve done here is only the beginning. In the spirit of open government and open knowledge, we are inviting you to join us on this journey. In order to truly create a flourishing and involved open government community around a technology platform new collaborators are always welcomed. Law experts, politicians, activists and most importantly - citizens - are encouraged to join us.

Tweet us with #DemocracyNeedsIA&UX

And join our slack community:

Ratings and Recommendations

This Talk hasn't been rated yet. Sign In to rate Talks.

comments powered by Disqus