At the Ministry of Justice we code in the open by default. Increasingly, we write IT Policy in the open too.
We apply the tenth GDS design principle: improving our IT Policy in the open to make it better.
We use open tools and standards to give us a low-cost, iterative and agile environment, enabling us to write and improve our information rapidly. We've imported our legacy IT Policy into GitHub, and are now updating it. The policies are not sensitive or confidential because if they were a secret, we'd run the risk of someone who needed to see them not being able to find them.
As a simple example, the password for a system must be secret. But the rules for choosing and managing suitable passwords must be as clear and simple as possible. For us, that means keeping the rules open.
Using the Cloud
We store our work in GitHub. This aligns with the UK Government Technology Code of Practice, which recommends use of open tools, standards, and cloud storage. Most important of all, the GitHub repository is public. This means that anyone can view the work in progress; anyone can suggest improvements. We encourage subject matter experts to take part.
The only reasons that content won’t be in the repository are if it:
- is classified above OFFICIAL
- includes personal data such as email addresses or telephone numbers
Storing IT Policy in GitHub gives us a single, definitive source of information. We avoid duplication, reduce problems with out-of-date material, and record what changes were made.
We develop IT Policy using GitHub Flavoured Markdown. It's not the most flexible way of word processing, but it offers advantages:
- it's portable across different environments
- it requires no special tooling
- all publishing systems understand it
- it's easy to review and edit
- It's easy to convert to other formats, including web pages and PDFs
Continuous delivery
GitHub gives us cloud storage and other features that enable the ideals of Continuous Delivery, such as:
- high visibility of work in progress
- feedback to help find and fix problems quickly
- rapid and frequent publishing
An example is spell-checking. We use Travis, so updating a document forces an automatic check. This helps us catch annoying little mistakes that undermine quality and value.
Working collaboratively and openly
Working in the open makes it easier to collaborate. We can work as easily with external partners and suppliers as we can across government. The use of open tools lets us enhance our working processes. They become more iterative and agile.
We can work in short, visible cycles. We can respond to feedback quickly and easily, update rapidly, and publish high quality content.
Some sensitive discussions about IT Policy, especially in the early stages, need to be private, and we make sure this happens. But as soon as possible, the discussion can and should move into the open.
Stability
An argument against this approach is that people want stable information. It's true that a work-in-progress document changes substantially and frequently. But knowing that a document update is in progress, you can:
- request a formal snapshot, for example to support a commercial initiative
- ask questions and make suggestions
Current thinking and technology capabilities change fast, so it's important to review and update IT Policy frequently. But everyone knows the status of a document at any time. It's public knowledge.
What next?
We’re already developing some interesting new features to further improve our IT Policy and its continuous development and delivery.
What do you think about making IT Policy open? Have you done something similar in your organisation? We’d love to hear from you in the comments.
Subscribe to the blog for updates on our work, or follow us on Twitter.
Want to work on things that matter? Find out more at MoJ Digital & Technology.
Leave a comment