Digital Local Laws

Project Background

Concept

New York State contains over 1,600 general purpose local governments counties, towns, villages, and cities. Each local government has authority to adopt its own laws on a wide array of subjects. In 2014, more than 4,200 local laws were adopted. Local governments have long been required to submit their laws to the Department of State (DOS), and they currently must do so by a paper-based process. Each time a law is adopted, an official specified by statute must complete a certification form, prepare the law in print format that follows certain formal requirements, and mail that form to the Division of Corporations, State Records, and UCC at DOS (State Records). State Records must then manually verify the submitted document meets formal requirements, scan the document, and file it. State Records stores the scanned copy in an enterprise content management system that performs optical character recognition and some indexing of the document’s contents. High Level Model of Local Legislative Process in New York State illustrates this process at a high level. State Records has authority to provide for electronic transmission as an alternative to the paper-based process, but has not implemented such a solution.

Figure 1. High Level Model of Local Legislative Process in New York State

This project seeks to prototype such a solution using technology developed to manage computer source code and publish books online. The idea is inspired both others' observations that law is like source code and should be developed more like source code using distributed revision control tools. High Level Diagram of Continuous Delivery for a Computer Software Application depicts how such tools are used to develop software and High Level Diagram of Continuous Delivery for a Publication depicts how such tools are also used to publish books, technical documentation, and other publications.

Figure 2. High Level Diagram of Continuous Delivery for a Computer Software Application

Figure 3. High Level Diagram of Continuous Delivery for a Publication

Compared with legislators, coders can:

Know every change, who made it, and why. Revision control enables line by line reporting of the history of every file.
Track changes across multiple, interrelated files. Revision control takes a snapshot of a collection of files and stores it in a repository that is separate from the files themselves. So any content — text, pictures, video — can be tracked over time as it changes.
Share and accept contributions without sacrificing control. Revision control enables the coder to share the code in a way where others can make their own copy, improve it, and submit their improvements back to the author. The author always retains control over when or if those changes are accepted in his or her own copy.
Access any past version that was ever shared. The repository, which contains the history of changes to the collection of documents, is checked out by each contributor. So everyone is able to compare and share with any previously shared version.
Run “builds” to make internally consistent “products” from any version. Coders largely automated the tasks that move from the source code they right to the software they deploy. Continuous integration platforms enable each iteration of sharing to automatically trigger testing and releasing new versions of software. This enables coders to respond quickly to problems or requests for improvements. The same tools are also used to convert textual sources of books into printable PDF, ereader EPUB, and web HTML editions.

Preliminary conversations with municipal clerks and attorneys have highlighted three capabilities of great potential value:

instant, automated validation and acceptance of new laws
public, searchable, statewide database of local government policy across 1,600 jurisdictions
secure record of all changes made, who made them, and why

This project starts with an assumption that continuous delivery could be adapted to support the submission process, and possibly even the drafting and adoption process for local laws. High Level Diagram of Continuous Delivery for Local Laws depicts the process at a high level. Detailed Diagram of Business Process for Local Laws in New York State with Continuous Delivery depicts the process at a more detailed level as described in Adopting Local Laws in New York State. Publication Products That Can Be Built Automatically from AsciiDoctor Source depicts how one source format in a legal variant of the AsciiDoctor standard can compile into many expressions. Most of the toolchain to build publications is already available open-source. Dashed lines indicate work that remains to be done as part of this project or related efforts in the AsciiDoctor project itself.

Figure 4. High Level Diagram of Continuous Delivery for Local Laws

Figure 5. Detailed Diagram of Business Process for Local Laws in New York State with Continuous Delivery

Figure 6. Publication Products That Can Be Built Automatically from AsciiDoctor Source

Contribution Guidelines for Project

Development will be open source and on GitHub to maximize opportunity for collaboration.
Process will be agile with frequent releases to assure design meets needs and avoid waste.
Every new feature should be accompanied by a comprehensive suite of unit and integration tests following behavior-driven development practices.
Every contribution should be submitted as a pull request to assure at least one other contributor reviews and understands the contribution.
As much as possible the platform should leverage existing open source components or well-documented API’s.

Implementation Strategies

General Pattern

General Pattern for Developing and Submitting Laws with Git depicts the git-based workflow contemplated for the local legislative process. While the tool should be extensible to support using git for managing legislative drafts, it is assumed that most municipalities will use the system primarily or exclusively for submitting final adopted laws.

Figure 7. General Pattern for Developing and Submitting Laws with Git

New Platform

A new platform was started specifically with this project in mind. It was written in the Ruby on Rails web application development framework. The front-end interface is AngularJS.

Advantages:

intuitive interface
illustrates basic submission process
is accompanied by a suite of tests and libraries that should be easy to extend

Challenges:

is incomplete implementation
“from scratch” approach means deployment and scaling may be more difficult

Wrapper Around Existing Platform

Instead of developing a new platform, the project could utilize an existing continuous delivery platform like GitHub or GitLab and build a user experience appropriate for municipal clerks and attorneys that uses these platforms' robust API as the backend.

Advantages:

scalability
extensive functionality and reporting capabilities already available
potential for external support for the system

Disadvantages:

as-is these platforms do not provide a user experience that is intuitive for users

Adapt Another Platform

Besides GitLab, a variety of open source platforms potentially pertinent to this project exist.

Indigo Platform is a legal publishing and consolidation platform developed by Code for South Africa.
- Advantages:
  - Offers good editing tools for preparing and filing a law.
  - Offers good framework for processing laws in other formats (PDF, Word) and converting them to interoperable, law-friendly forms.
  - Well documented and accompanied by a good suite of tests.
  - Supported by a team with intentions of expanding functionality to provide enhanced legal publishing service.
- Disadvantages:
  - Backend is not distributed revision control.
  - Not a framework for end-to-end support of legislative process.

Initial Approach

Team should examine the existing platform and evaluate whether it could be adapted to wrap around an API.