Getting started
This guide is aimed at people who are thinking about setting up their own Alaveteli website in a new jurisdiction.
For inspiration, take a look at some of the existing Alaveteli websites, like Informata Zyrtare (Kosovo), AskTheEU (EU), or WhatDoTheyKnow (UK). These sites all use the Alaveteli software, plus their own custom themes installed on top to make them look different.
You don't even need to make a custom theme to get started. You can have a website that looks like the test website and simply drop in your own logo.
The process of getting your own Alaveteli website up and running could take anywhere from 1 day to 3 months, depending on the scale of your ambition for customising the software, your access to technical skills, and your available time. Here's how we suggest going about it:
You're unlikely to be able to get much done on your own. You will need translators, people to hunt down email addresses of authorities, possibly a designer, and preferably a technical expert to help with customisations. Read through this guide first, and think about the skills you will need to successfully launch and maintain the website.
It took about ten people (including translators) working for three days to launch Queremos Saber, a Brazilian version of Alaveteli.
It was really cool setting the site up. And even with some minor difficulties (most related to the fact that we had no one really experienced with both Ruby on Rails and Postfix) it was pretty quick and in less than a week we had a fully featured website!
-- Pedro Markun, Queremos Saber
AskTheEU, a much more complete and polished version with a custom theme and several other customisations, took a team of 2 or 3 people about 3 months (part time) to complete.
You have two options here: install your own copy, or ask the Alaveteli team to provide a hosted version.
If you install your own copy, you have complete control over the website, its performance, how often it is upgraded, etc. This is far preferable. However, you will need some resources to do this.
Alternatively, we have very limited capacity to run a handful of Alaveteli sites for willing volunteers. We want to learn more about how we can support third parties, and to do so are happy to help host low-volume sites for two or three partners. However, you will have no service level agreement, no warranties, and no guarantee on our time: if the website goes down when we're on holiday, you'll have to wait until we're back! If you want to try this route, please get in touch to find out if we have capacity.
You'll need to find a tech person who knows about hosting websites using Apache and Linux. They don't need to know Ruby on Rails, but it would help.
You'll also need to source a server. You should ask your tech person to help with this. The minimum spec for running a low traffic website is 512MB RAM and a 20GB disk. 2GB RAM would be ideal. We recommend Debian Squeeze as the operating system, though any sort of Linux should do. Rackspace offer suitable cloud servers, which start out at around $25 / month.
Alternatively, you could use Amazon Web Services. If you've not used them before, you can get a free "micro" instance for twelve months. This has the added advantage that you can use our preconfigured Alaveteli EC2 AMI to get you started almost instantly. However, it's more expensive than Rackspace, especially if you want more RAM.
You'll need to understand how the website works. Until your own copy is available, you can try the copy running on the test server (though note this isn't guaranteed to be available or working).
Right now we don't have a guide book, so you'll just have to explore on your own.
When you have your own version running, try logging into the admin
interface by adding /admin onto the end of your domain name. This
will take you to the administrative interface. It's plain and simple,
but functional. For example, try adding new authorities there,
perhaps with your own email address, so you can see what requests look
like to them.
When trying things out, you need to wear several hats -- as a site administrator, an ordinary site user, and as a public authority. This can get confusing with several email addresses. One quick and easy way to do this is to use a throwaway email service like http://mailinator.com.
One of the most important things you need to do before launching is to gather together a list of all the bodies to whom you want to address FOI requests.
It's a good idea to make a shared speadsheet that you can ask your supporters to help fill out. A template like this Google spreadsheet is ideal.
If you email possible supporters asking for help, in addition to helping make your job easier, it will also help you identify eager people who might be interested in helping you maintain and run the website. We have written a blog post about this.
The admin interface includes a page where you can upload a CSV file (a kind of spreadsheet) to create or edit authorities.
Obviously, you'll want to put your own visual stamp on the site. Once you have a name for your project (e.g. WhatDoTheyKnow in the UK, AskTheEU in the EU, InformateZyrtare in Kosovo), register a twitter username, and a domain name. Alaveteli relies on you keeping a blog for its "News" section, so you might want to consider setting up a free blog at http://wordpress.com or http://blogger.com and announce your project with a new blog post.
Next, think about the visual identity. At a minimum, you should probably replace the default alaveteli logo that you can see at the top left of http://test.alaveteli.org. It's also easy to change the colour scheme.
If you have a bit more budget and time, you can rework the design more, with a custom homepage, different fonts, etc; however, the more you customise the site, the harder it is to upgrade in the future; and you'll need a developer and/or designer to help do these customisations. We call the custom set of colours, fonts, logos etc a "theme"; there are some notes for developers about writing a theme. You might spend anywhere between 1 and 15 days on this.
We rely on users to help categorise their own requests (e.g. as "successful", or "refused"). We call these categories "states". Most FOI laws around the world are sufficiently similar that you could use Alaveteli's states exactly as they come out of the box.
In addition, we have found that it's generally a bad idea to try to implement laws exactly in the user interface. They are often complicated, and confusing for users. Since the concept of Alaveteli is to make it easy to exercise the right to know, we take the view that it's best to implement how a FOI process should be, rather than how it actually is right now.
However, if you really feel you need to alter the states that a request can go through, it is possible to do this to some degree within your theme. Have a think about what is required, and then send a message to the Alaveteli mailing list for feedback and discussion. Then you'll need to ask your developer to implement the new states. It's usually no more than a couple of days' work, often less. But complicated workflows might take a bit longer.
The default help pages in Alaveteli are taken from WhatDoTheyKnow, and are therefore relevant only to the UK. You should take these pages as inspiration, but review their content with a view to your jurisdiction. The important pages to translate are:
- About: why the website exists, why it works, etc
- contact: how to get in touch
- credits: who is involved in the site. Importantly, includes a section on how users can help the project.
- officers: information for the officers who deal with FOI at authorities. They get a link to this page in emails that the site sends them.
- privacy: privacy policy, plus information making it clear that requests are going to appear on the internet. Let users know if they are allowed to use pseudonyms in your jurisdiction.
- requesting: the main help page about making requests. How it works, how to decide who to write to, what they can expect in terms of responses, how to make appeals, etc.
- unhappy: users are taken to this page after a request that has been somehow unsuccessful (e.g. the request has been refused, or the authority is insisting on a postal request). The page should encourage them to keep going, e.g. by starting a new request or addressing it to a different body.
- why email: a snippet of information that explains why users should insist on replies by email. This is displayed next to requests that have "gone postal".
The help pages contain some HTML. Your tech person should be able to advise on this.
Once the pages are written, ask your tech person to add them to your theme.
Now is also a good time to start thinking about some of your standard emails that you'll be sending out in response to common user queries and administrative tasks -- for example, an email that you send to IT departments asking them to whitelist emails from your Alaveteli website (for when emails are ending up marked as spam). Review the Administrator's manual for details on some of the common administrative tasks.
Perhaps you would like a new usability-related feature not in Alaveteli already, like the automated language detection for multi-language websites; or Facebook integration; or an iPhone app.
Perhaps you've found an area relating to translations that Alaveteli doesn't yet support fully (for example, we've not yet needed to implement a site with a language written right-to-left).
Perhaps your jurisdiction requires a new feature not in Alaveteli -- for example, it may need a user to pay a fee to make requests.
In these cases, you will need to get your tech person (or some other software developer) to make these changes for you. This can be time consuming; new software development, testing, and deployment is often complex. You should get expert advice on the amount of extra time this will require. Typically, changes like these could add between one and three months onto the project schedule.
This is potentially a big job!
If you need to support multiple languages in your jurisdiction, you will need to translate:
- public authority names, notes, etc
- public authority bodies
- help pages
- all of the web interface instructions in the software
It's a bit easier if you only need to support one language in your jurisdiction: because you'll already have written the help and public authority information, you'll only need to translate the web interface.
Public authority names can be edited via the admin interface, or by uploading a spreadsheet. The help pages need to have one copy saved for each language; your tech person will put them in the right place.
The web interface translations are managed and collaborated via a website called Transifex. This website allows teams of translators to collaborate in one place, using a fairly easy interface.
The Alaveteli page on Transifex is at
https://www.transifex.net/projects/p/alaveteli/; the translations all
live in a single translation file called
[[app.pot|https://www.transifex.net/projects/p/alaveteli/resource/apppot/]].
You can set up your language and provide translations there; you can also use specialise software on your own computer (see the help pages on Transifex)
There are (at the time of writing) around 1000 different sentences or fragments of sentences (collectively known as "strings") to be translated. The meaning of many strings should be fairly obvious, but others less so. Until we write a guide for translators, the best route to take is translate everything you can, and then ask your tech person or the project mailing list for advice on anything you're unsure about.
Over time, as bugs are fixed and new features are added, new strings
are added to the file. Therefore, you need to keep an eye on
app.pot and periodically review the untranslated strings.
For launch, the tech person should review the Production Server Best Practices.
A low-key launch, where you tell just a few trusted people about the site, is a very good idea. You can then track how things work, and gauge the responses of authorities. Responses are likely to vary widely between and within jurisdictions, and the right way of making your website a success will vary with these responses.
In general, the best way to engage authorities is with a mixture of encouragement and exposure. In private, you can explain that in addition to helping them meet their legal requirements and civic obligations, you may be reducing their workload by preventing repeat requests. In public, you can work with journalists to praise authorities that are doing a good job, and highlight ones that refuse to take part. It is, therefore, very important to make links with journalists with an interest in freedom of information.
The other important marketing tool is Google Grants, a scheme run by Google that gives free AdWords to charities in lots of countries around the world. You'll find these an incredibly useful resource for driving traffic to your site. It's well worth setting yourself up as a charity if only to take advantage of this programme.
Running a successful Alaveteli website requires some regular, ongoing input. This will be easier to do with a small team of people sharing jobs. Hopefully you have been lucky enough to get funding to pay people to do these tasks. However, you are also likely to have to rely on volunteers. We've written a blog post about the importance of volunteers, which you should read.
You'll need to set up a group email address for all the people who will manage the website. All site user queries will go here, as will automatic notifications from Alaveteli. A group address is really useful for helping coordinate responses, discuss policy, etc.
You could get by with just 1 or 2 hours per week. This means keeping an eye on the "holding pen" of the website, where incoming messages that the site doesn't know how to handle are stored (things like spam, misaddressed messages, etc). However, the more effort you put into this, the more successful your website is. To ensure its success, you should be doing things like:
- Responding to user help enquiries by email
- Monitoring new requests, looking for people who might need help, posting encouraging comments on their requests
- Monitoring responses from authorities, looking for ones who are trying to refuse to answer, offering advice to the person who made the request, possibly coming up with publicity to "shame" the authority into answering
- Tweeting about interesting requests and responses
- Writing blog posts about the progress of the project
- Communicating with journalists about potentially interesting stories
- Recruiting volunteers to help with the site
- Categorising uncategorised requests
There's the beginnings of an adminstrator's manual, describing some of the typical tasks.
This is the first version of a getting started guide. Let us know what you'd like us to add next.