Version Control
This entire project is based around the idea that version control is king. Therefore choosing the version control system is paramount to a successful project.
Version Control System Options
So let us consider the possibilities. There are many version control systems such as SVN, Darcs, Git, Bitkeeper and others. However I have two overriding requirements for the version control system:
- It must be free open-source software that is compatible with the GPL;
- It must be a distributed version control system. This will give us maximum flexibility with regards to members having their own repositories.
So, with the above requirements we are basically reduced to three options which are Darcs, Git and Mercurial.
In terms of features these systems are relatively equal (in my opinion) therefore it is mainly a matter of personal preference and in this case I choose git.
Why Git?
Git is a relatively new version control system that emerged out of a debacle with the proprietary Bitkeeper software. It has since become rather popular and is used in many projects.
My main reasons for choosing git is that there are useful Ruby (My programming language of choice)libraries for interfacing with git that will reduce development time. There is also Gitorious.
Gitorious is a free open source git repository hosting website. Since this is largely what our proposed website will be, it gives us a good starting point in terms of code. Rather than having to write everything from scratch we can adapt large parts of the Gitorious code-base (One of the advantages of open source software). Of course there will need to be extensive modification of the Gitorious code to adapt it to our usage scenarios but it is a definite springboard.
Repository Organisation and Hierarchy
A sane and simple organisation of the repositories is essential to maintaining an easy to understand structure which contributes to easy updating. Below is the organisation I am thinking of implementing.
Main Repository (Main Repo)
This is the main trunk repository. This repository is considered to be the prime repository and is the repository that contains the legislation that is condsidered to be law by the country at large. Any parties who want a mirror of the official laws of the land should mirror this repository.
Updates to this repository will never be manual but be the result of automated processes triggered by voting results of the house.
Committee Repositories (Committee Repo).
Each committee will have one repository that represents it and contains all the amendments that have been voted for by the committee members but await voting by the main house to be promoted to the Main Repo.
Updates to this repository will never by manual but be the result of automated processes triggered by voting results of the committee.
Committee Member Repository (Committee Membe Repo)
This is the repository that is owned by an individual Committee Member and is descended from a particular Committee Repository. Because a Member of the House can be on many committees it is possible to own many such repositories. All changes made to this repository as well as controlling access to it is the responsibility of the Member of the House.
Server side
The CM’s personal repository is mirrored. One of them is on the main server. This copy can be set to personal (Only viewable to select people) or public (Viewable by all).
Updates to this respository will only be made by pushing changes from the client-side repository
Client side
This is the CM’s personal repository on his or her local computer. This is where changes will be made directly and is the first stage of updating legislation. All changes will have to be pushed to the Server side mirror before any voting or collaboration features are available.
However because not everyone is technically minded and may not wish to use git on the client side there will be a web interface for updating the CM’s server-side personal repository directly.
Legislation Update Process (Technical Viewpoint)
Following is a diagram that show the initial process of updating a personal repository and committing it to the committee repository.
The CM first updates his personal repository on the client side then pushes the changes to his server side repository. At this point the CM can create a discussion thread regarding his changes if he wishes.
When the CM wishes his changes to be put to the vote he may choose to do so via the interface. A discussion thread will be automatically created for the amendment and the amendment put into the voting queue.
