 |
Legislative Reform
improving the US legal system
|
|
|
|
The mechanics of writing and maintaining law in the US leave something to
be desired. I have some observations about problems, and suggestions for
fixing them.
Laws are written in a specialized language resembling English. It's very
difficult to interpret laws accurately without training and a lot of
experience in a legal profession. It is very similar, in this way, to
computer source code. The language written in the law books is merely a
representation, or implementation, of ideas -- not the true form of those
ideas. That's why legal battles arise over ambiguities, and the Supreme
Court then makes rulings on what it calls the "spirit of the law". Someone
encounters an omission, or a bug, in the law, and it becomes necessary to
reverse-engineer the code. The court attempts to guess what a law
was trying to accomplish, and why it was written, and then decide (based on
this speculation) what to do.
I propose that the intent of a law, among other extra data, be included
with each law. That way, the law could specify what and why
up front, and then later go into the details of how.
I propose including the following extra data with each law:
- Intent. This explains what the law is designed to
accomplish, and why.
- Implementation. This details, in usual legalese, how
to implement the law. It contains the code which makes the law
work.
- Reasoning. Explain why the given implementation will
accomplish the law's stated goals.
- Dependencies. Describe relations to other laws, such as
requiring another law in order to be valid, or conflicting with another
law.
- Author(s). A list of people involved with creating the law,
and details of their contributions.
- Notes. Miscellaneous extra data, as appropriate.
- ID. Each law needs a unique ID, so it can be referenced
easily.
- Dates. Required would be the date the law was proposed,
the date it was voted on, the date it goes into effect, and the date
it expires. Other dates may be included too, if necessary.
- Voting Results. After a change is voted on, the detailed
results of that vote should be recorded along with the law. For example,
if the Senate votes on a proposal, keep a record of what each person's
vote was. If it is a public vote, record the end results, perhaps also
including data per county.
I feel it's also important to point out that many sections should include
references. Linking to appropriate research and such are standard practice
in any respectable science, and government should be no different.
Auditing, Verification of Results |
Once the extra data is included in each law, the correct functioning of
the law should be periodically verified. In short, investigate whether
the details of the law match its "spirit", and whether its result is in
line with its intended result. If not, revise the law or throw it out.
Completely eliminate the practice of "rider laws" attached to other bills.
Many large bills get passed, composed of many related (or unrelated)
parts. A standard way of getting a corrupt or unpopular law passed is to
simply tack it onto a well-supported bill, and letting it "ride along".
This is not the only way, of course, but it seems to be one of the easiest
and most common.
The intent of eliminating riders is twofold: To reduce the amount of
corrupt proposals which slip into law, and to encourage modularity in law.
Modularity is one of the most important concepts in computer science, as
a "best practice" and guideline. These "best practices" of information
theory should be included in the development and maintenance of law,
because the fields are so similar.
Give each law a duration, after which time it expires. This applies to
all laws. In order to keep the law after that time, it must be
renewed. To help keep things sane, allow a time window to renew the law...
perhaps any time during the last 10% of its current term.
The point of doing this is to cull obsolete and unnecessary laws. The most
important ones will stay in effect, of course, but questionable laws, or
laws governing minor problems, will not last long. This will probably have
other effects as well: Shifting more laws to lower levels, such as federal
to state, or state to city. It will also likely reduce the size of the
government, by continuously eliminating bloat.
Duration Based on Concordance |
A further suggestion is to set the duration of each law based on how well
it was supported during a vote. The point of doing this is to avoid
constantly re-voting on things everyone agrees on, and spend time
re-evaluating controversial issues instead.
This could work in two ways:
- Determine duration based on popularity. Simply take the percentage
of supporters and translate it to a duration. For example, 55% may
last for 2 years, while 75% lasts for 6 years, and 95% lasts for 15
years.
- Require various levels of agreement for each duration. In other
words, the person who proposes a law determines how long it will last,
but the longer the duration, the higher vote percentage required to
pass it. If you are confident that you can get 80% of the votes,
propose a duration of 8 years. But if you think you don't have many
supporters, propose a 1-year or 2-year duration.
Keep all laws in a revision control system, so that anyone may look up
what the complete legal environment was on any date, and see changes made
throughout history.
Such a system will need to be implemented in a way that is designed to
withstand attack, prevent tampering, and recover from failure. This is
an area of active research, with good results. Projects such as freenet
stand up nicely to almost any attack. Also, distributed backups will
help in the case of failure, and provide a way to audit and verify data
has not been modified.
Make all laws available and easily accessible. This probably means putting
them online, in various forms: web pages, source documents, etc.
Open-Source Methodologies |
Require our elected officials to read laws before voting on them. Bonus
points if they also research the bill by polling their constituents about
it.
Slashdot had some interesting ideas on treating the law-making process
more like the software development process:
link
|
|
|
|
|
