When you send a Freedom of Information request, a clock starts ticking. Here in the UK, public authorities have 20 working days in which to respond — but of course they can only do so if they’ve received the request.
And, while email is generally reliable, we’re all familiar with the occasional mishaps it can bring: mailboxes that are full, accounts that have been closed down, or messages being returned because they look too much like spam.
Sign here please
Email works a bit like signed-for physical mail. When a letter is delivered to a recipient they either sign to say they’ve received the letter, or the mail company records that there was no-one available to accept the delivery. This lets the mail company keep the sender up to date with where their letter is. Mail servers do the same — the recipient server sends a confirmation that a particular email has been received, or an error code is reported by your mail server if there’s a problem delivering the email.
Like physical mail, we can only verify that the message has been accepted at the destination address. It’s then under the recipient’s control to get it to the right person at that address, a bit like a receptionist receiving a letter for an employee 10 floors above. We think that if an authority’s mail server confirms that one of our emails has been delivered, it’s their responsibility to ensure it reaches the correct people to be able to answer your FOI request.
Proof of receipt
Look at the header of any request on WhatDoTheyKnow, and within 24 hours, in most cases you’ll now see a small green ‘delivered’ confirmation:
Most users can click on this to see further confirmation:
But if you’re the owner of the request, when you click on the green ‘delivered’ link, you’ll see information from the mail logs as the message passed through our server. If there’s ever a query about whether or not a message was delivered, you can hand these on to the authority to help them analyse any issues.
On the rare occasions that something goes wrong, here’s what users will see instead:
– and if it’s your own request, again, you’ll have access to the mail logs.
Small but mighty
This feature might look small, but there’s a lot of thinking behind it — just check the length of the trail on Github, our ticketing system. Anyone will be able to understand the amount of discussion and problem-solving that went into the addition of this small green tick, while the more technically-minded may also find it interesting to see the coding solutions as they unfolded.
This small green tick also gives users something rather powerful: proof that their request was received by the authority’s mail server at a specific time, should that be disputed.
The suggestion for this feature came initially from one of the WhatDoTheyKnow volunteers. It took some time to implement, but we’re pleased to say that it has now been made available for all Alaveteli sites in release 0.25.0.0.
We’ve released Alaveteli 0.25! Here are some of the highlights.
Visible delivery status
Gareth and Zarino have added a delivery status feature that shows whether a message has been received by the authority’s mailserver. This should provide reassurance for site users that messages are getting through and makes it difficult for an authority to successfully claim that they didn’t receive the request.
Clicking on the delivery status indicator reveals a bit more detail about the status itself. Admins are shown more detail here including relevant mail logs to diagnose problems or provide proof to the authority if required.
We’ve upgraded from the so-called “Legacy” (ga.js) version of Google Analytics to Universal Analytics. For most Google Analytics users there’s nothing to do here except sit back and enjoy continued technical support and new feature rollouts from Google but if your Alaveteli theme has custom analytics scripting, you should check Google’s upgrade guide as well as our upgrade notes to see if you need to make changes. If you’re not ready to move to this release yet, don’t panic – you may not get any shiny new features from Google but they haven’t published an end date for support yet.
In addition to spam email, there’s been an increase in the number of accounts that create profiles containing spam links – presumably to boost their search engine ranking score rather than to trick people into clicking through from the site. Having spent some time going through accounts on WhatDoTheyKnow to look for patterns, we’ve added some tools to this release to try to discourage this use of Alaveteli and to make it easier for admins to discover and ban offending user accounts.
(We also looked at extending our reCAPTCHA use for new account signups but this didn’t seem to help so we are not offering it to reusers.)
Martin has been working away on improving page load times and accessibility compliance to make the pages faster to load and easier to navigate. (A process we’re continuing into the next release.) We’ve also updated the help template code so that the examples are in the example theme rather than the core code and added a rake task to help check whether your theme implements the help pages correctly.
The full list of highlights and upgrade notes for this release is in the changelog.
Thanks again to everyone who’s contributed!
We were shocked and saddened to learn that Peter Williams, one of our WhatDoTheyKnow volunteers passed away earlier this week.
Peter only joined WhatDoTheyKnow as a volunteer in March of this year, however in that short time he had become a valued member of the team.
No stranger to Freedom of Information, he had been using the rights provided for in the FOI Act since shortly after it came into force here in the UK, and had been a user of WhatDoTheyKnow since 2012.
Education and senior executive pay and benefits were some of his particular areas of interest, and Peter was researching the reasons why some public bodies sometimes fail to respond to requests.
As a consequence, Peter had helpfully been collecting information on specialist colleges and schools, and proposing additions and edits to the site. Following the same route that has led to several of our keenest users becoming volunteer administrators, he was invited to join the team so that he could make the changes he was proposing himself.
By all accounts he made a strong impression during his short time on the team, both with his fellow volunteers and across the mySociety team.
“Many aspects of the site’s operation, including dealing with correspondence from users, considering requests to remove material from the site, and discussing our policies and the future development of the service, benefited from Peter’s input”, says one.
Others say: “He was a valued volunteer and a great person”; and “he was a funny, thoughtful and committed guy”.
We were saddened to learn of death of someone who shared our beliefs in the value of making information held by public bodies accessible, and who shared our passion for activism.
All are feeling the loss of a colleague who approached his role with such enthusiasm and diligence, and our team will be the poorer for his absence. On behalf of mySociety, our Trustees and the WhatDoTheyKnow volunteers our thoughts are with Peter’s family and friends.
Even official records aren’t as safe as you might think they are. The archive of a country’s political history might be wiped out in a single conflagration.
Take the example of Burkina Faso, a beautiful West African country that is, sadly, perhaps best known to the rest of the world for its troubled political past.
The uprising in Burkina Faso in 2014 led to a fire in the National Assembly building and archives office. Nearly 90% of the documents were lost. Now the National Assembly is working to reconstruct the list of its parliament’s members before 1992.
This means that the data EveryPolitician has on Burkina Faso has nothing from terms before 1992. We’ve got some data for six of the seven most recent terms from the National Assembly so far, of which five are live on the site. Even though that data is not very rich (there’s little more than names in many cases; and the 6th term was transitional so data on that one’s membership might remain elusive) it’s a beginning.
We know from experience that data-gathering often proceeds piecemeal, and names are always a good place to start.
As Tinto finds new data, whether that’s more information about the politicians already collected or membership lists of the missing terms before 1992, we’ll be adding that to EveryPolitician too.
A vast collection
When people ask what EveryPolitician is, we often say, ‘The clue’s in the name’. EveryPolitician aims to provide data about, well … every politician. In the world.
(We’ve limited our scope — for the time being — to politicians in national-level legislatures).
The project is growing. Since our launch last year, we’ve got data for legislatures in 233 countries. The amount of data we’ve collected currently comprises well over three million items. The number of politicians in our datafiles is now in excess of 70,000.
Seventy thousand is an awful lot of politicians.
In fact, if you think that might be more politicians than the world needs right now, you’re right: as the Burkina Faso example shows, EveryPolitician collects historic data too.
So as well as the people serving in today’s parliaments, our data includes increasing numbers of those from the past. (Obviously, if you have such data for your country’s legislature, we’d love to hear from you!)
More than just today’s data
The Burkina Faso fire is an illustration of the value of collecting and preserving this historic data.
Of course, we’re fully aware of the usefulness of current data, because we believe that by providing it we can seed many other projects — including, but in no way limited to, parliamentary monitoring sites around the world (sites like our own TheyWorkForYou in the UK, or Mzalendo in Kenya, for example).
Nonetheless, we never intended to limit ourselves to the present. By sharing and collating historic records too, we hope to enable researchers, journalists, historians and who-knows-who-else to investigate, model, or reveal connections and trends over time that we haven’t even begun to imagine. We know this data has value; we look forward to discovering just how much value.
But it turns out we’re providing a simpler potential benefit too. EveryPolitician’s core datafiles are an excellent distributed archive.
What Burkina Faso’s misfortune goes to show is that, as historians know only too well, data sources can be surprisingly fragile.
In this case the specific situation involves paper records being destroyed by fire. That is a simple analogue warning to the digital world. Websites and their underlying databases are considerably more volatile than the most flammable of paper archives.
Database-backed sites are often poor catalogues of their pasts. Links, servers and domain registrations all expire. Access to data may be revoked, firewalls can appear.
Digital data doesn’t fade; instead it is so transient that it can simply disappear.
Of course, we cannot ourselves guarantee that our servers will be here forever (we’re not planning on going anywhere, but projects like this have to be realistic about the longer view).
There is an intriguing consequence of us using GitHub as our datastore. The fact is, the EveryPolitician data you can download isn’t coming off our servers at all. Instead, we benefit from GitHub’s industrial-scale infrastructure, as well as the distributed nature of the version control system, git, on which it is based. By its nature, every time someone clones the repository (which is easy to do), they’re securing for themselves a complete copy of all the data.
But the point is not necessarily about data persisting far into the next millennium — that’s a bit presumptuous even for us, frankly — so much as its robustness over the shorter cycles of world events. So, should any nation’s data become inaccessible (who knows? for the length of an interregnum or civil war, a natural disaster, or maybe just a work crew accidentally cutting through the wrong cable outside parliament), we want to know the core data will remain publicly available until it’s back.
Naturally there are other aspects to the EveryPolitician project which are more — as modern language would have it — compelling than collecting old data about old politicians. But the usefulness of the EveryPolitician project as a persistent archive of historical data is one that we have not overlooked.
This is Part three in a blog post series highlighting information that has been disclosed thanks to Freedom of Information (FOI) requests on Alaveteli sites across the world. Here are part one and part two.
Australian police use banned restraint technique on asylum seekers
Detention Logs is a project that publishes data, documents and investigations that reveal information on conditions and events inside Australia’s immigration detention network.
As part of the project, Detention Logs used Alaveteli site RightToKnow to ask the Australian Department of Immigration to disclose incident reports from detention facilities.
One such incident report revealed that the Department of Immigration approved the use of a controversial body lock technique on an asylum seeker.
The incident report describes the restraint as follows:
“The seat belt was fastened. The client and the escort staff were the first passengers to board the plane. As the client continued screaming and resisting, DIAC staff issued instruction to the escort staff to ‘lock the client down’ by pushing her chest towards her knees. However, the client still continued screaming loudly and attracting attention of the cabin crew.”
According to New Matilda and Detention Logs, the account of the restraint strongly resembles the “seated double embrace” technique banned by police in Victoria and New South Wales in Australia, and some government agencies in the United Kingdom.
The United Kingdom Ministry of Justice banned this technique in juvenile detention facilities, following the death of 15-year-old Gareth Myatt in 2004.
Why the EU’s taking its time on restricting harmful chemicals
Endocrine disrupting chemicals (EDCs) are chemicals that are present in everyday products – from plastics and cosmetics to pesticides. Because of their ability to interact with the hormonal (endocrine) systems of living organisms, they are suspected of having serious health and environmental impacts.
The European Union is supposed to regulate EDCs, in order to protect citizens from harmful effects. Both the EU’s 2009 pesticide regulation and the European chemicals package (REACH) demand that the EU take action on these chemicals.
However, several years later, the European Commission is still no closer to taking concrete action.
The documents have helped journalist Stéphane Horel and research and campaigning group Corporate Europe Observatory (CEO) to piece together why the process has stalled, and what has been said behind closed Commission doors.
To communicate their findings, they produced a book and documentary, which explains how corporations, and even actors within the Commission, are stalling the process of this key public health and environment legislation.
Now Rwandans can find out when their parliament is in session
The Rwandan parliament now publish the Chamber of Deputies’ schedule of debates/activities for each day on the homepage of their official website (under ‘Today in Parliament’).
This follows an FOI request on Rwandan Alaveteli site Sobanukirwa, which urges the parliament to do just that. The Sobanukirwa team don’t know for sure if their request influenced parliament’s decision to publish this information, but we are pretty sure it had an impact.
The Australian and EU examples above show the power of making a lot of FOI requests, across authorities, and then grouping them together to create/support a project or investigation about a wider issue of public concern.
The Rwandan example shows that perhaps, just perhaps, a single request can cause a big impact.
So, what do you want to investigate? What have you always wanted to know? Start your own investigation to unearth truths that may just surprise you, and use an Alaveteli site to help you.
If you know of any interesting requests made on Alaveteli sites (or other online FOI portals) that you’d like featured in this blog post series, then please do get in touch.
— mysociety (@mysociety) June 27, 2016
That’s the tweet we put out on Monday, after a few days of the fastest-moving politics the UK had seen in years. Little did we know that there was plenty more to come.
And it’s true. Everyone is talking politics — in the street, in the pub, on Facebook. Everyone wants information; everyone wants to express their opinions: which means that TheyWorkForYou and WriteToThem are pretty useful right now.
This has been an interesting week for us here at mySociety. As well as engaging in the same scrolling through fast-changing news stories as the rest of the nation, we’ve been dashing to make a few changes to our sites.
In general, our working methods favour considered actions. We ticket ideas, we discuss them, we prioritise and schedule them, we peer review them, and then they go live. It’s an excellent system for ensuring that work is both necessary and robust. It’s not quite so ideal for working on a new feature you need, like, yesterday, so this has been a change of pace for us.
Information is key
Here’s our first significant addition. Before you email your MP on matters concerning Brexit, it’s useful to know where they stand, so we quickly created an infobox for MPs’ pages on TheyWorkForYou (based on data from the BBC):
Neither of our parliamentary sites needed structural changes: fortunately, they are built robustly and hosted on servers which cope with increased visitor numbers when they occur.
And they are occurring. In a week that has seen the referendum, the resignation of the Prime Minister, mass shadow cabinet resignations, and Conservative leadership nominees, you have had plenty to research and plenty to write to your representatives about.
Here’s what visitor numbers for TheyWorkForYou look like — five times the usual traffic:
And six times as much as usual for WriteToThem:
Increased traffic is no problem (quite the contrary; we love it!), but there were some things that needed our attention. More users means more user support, so we’ve spent more time than usual answering questions about who we are, how we generate our data, what to do if a confirmation email doesn’t arrive, and so on.
Oh, and about that data:
All these resignations- will nobody think of the people who maintain parliamentary monitoring websites?
— Myf Nixon (@mockduck) June 27, 2016
Lots of what’s published on TheyWorkForYou updates automatically, but not necessarily immediately. Parliamentary roles, for example, are only scheduled to update weekly.
That doesn’t allow for the rate of resignations and replacements that we’ve seen in the shadow cabinet this week, so our developers have had to go in and manually set the update code running.
We wanted to remind people that TheyWorkForYou is a great place to research the facts about those standing in a leadership contest. In particular, our voting record pages set out clearly and simply what each MP’s stance is on key issues.
So we’ve been tweeting and Facebooking reminders like this:
At times, the news moved too fast for us to keep up:
Oops! Meanwhile, we also have another useful source of information: the Conservative party speeches that were removed from the internet in 2013 and which we republished on our SayIt platform:
We’re working on improving the way that TheyWorkForYou pages look when you share them on Facebook and Twitter, which seems sensible given that they are being shared so much right now.
Videos from TICTeC — our Impacts of Civic Technologies Conference — are now available for viewing.
So, whether you were there and you want to experience it all over again, or you just want to see what you missed out on, settle down and enjoy accounts from some of the most interesting civic tech projects around the world right now.
What is TICTeC?
Here’s mySociety CEO Mark Cridge explaining what TICTeC is, and why we run it:
And if that’s left you hungry for more, make sure you visit our YouTube channel to watch the other TICTeC videos.
You might also enjoy the slides, photos and other media that have all been collected together on the TICTeC 2016 page.
We recently made some changes to our Freedom of Information software, Alaveteli, that makes it twice as easy for partners to change the look and feel of their site. This post goes quite in-depth, so it’s probably best suited for designers, developers and other technically-minded readers
This year we embarked on a ground-up redesign of Alaveteli’s theming capabilities to make customising Alaveteli easier and faster. We used a mixture of techniques to try to achieve this and since releasing the update we’re happy to have seen a decrease in the complexity of our themes, and the time we spend making them.
Alaveteli, our Freedom of Information platform is one of our most deployed software packages and each deployment requires some customisation, from simple branding changes to complex functionality to support a country’s FOI process. This is either done internally by our own developers, or our partners take this on themselves.
An Alaveteli deployment consists of two things, the core: the guts of Alaveteli with no customisations, and the theme: the aesthetic and functional customisations made to each site. We ship Alaveteli with a fully-featured base theme that gives partners a good starting point to work from, but they can also start their own theme from scratch.
After talking to our partners and the Alaveteli team we felt that the process of theming was too complicated and involved. It required a lot of knowledge of Alaveteli’s inner workings, was coded in a way that made it hard to understand, and almost always required the intervention of a front-end expert, even to make trivial changes.
Our vision for how Alaveteli’s theming should work was:
- Intuitive Front-end developers and designers should be able to follow and understand the templates without needing expert knowledge about Alaveteli’s inner-workings.
- Flexible Overriding Alaveteli’s core code should be easy, so a theme should use low-specificity, componentised code to enable this.
- Supportive Should a partner decide to only change a few colours, or embark on a large-scale redesign Alaveteli, the theming process should never get in the way.
How we did it
Using the tools we have
Alaveteli is built on Ruby on Rails, so our first goal was to make better use of Ruby on Rail’s template inheritance.
Firstly, we split all of the Sass files into logical components.
Each component has two associated Sass files, a layout.scss and a style.scss. layout.scss describes only layout of a component, e.g. the physical dimensions and position on a page. style.scss describes the styles, for example typefaces, colours, borders and other presentational properties.
Should a partner wish to totally redesign or replace a component, they can replace both files with their own. Alternatively they can just choose to replace one part of the component, for example keeping the layout, but replacing the styles.
Ensuring the lowest possible specificity
When customising Alaveteli we want to be sure that a partner never has to fight with the base theme to achieve their goals. The most important part of this is to ensure CSS styles are easy to override.
Firstly we removed all ID selector’s from Alaveteli’s stylesheets and replaced them with class selectors, giving us a good jumping off point as class selectors have much lower specificity than IDs. We then rewrote and refactored Alaveteli’s CSS using the Block Element Modifier methodology (BEM).
BEM helped us in two ways: it’s written in a way that makes CSS self-describing, for example the code snippet
.header__navigation__listtells us that this list is a child of the navigation element and a grandchild of the header element.
As well as this, using a single class to define the styles for this element means that using BEM gives our styles the lowest possible specificity, so partners can override them with little resistance.
Using a settings partial
All of our theme’s styles use the variables defined in _settings.scss when referencing colours, typefaces, spacing, and even logo files so the bulk of Alaveteli’s customisation can be done in our base theme’s settings partial _settings.scss.
This allows partners to make simple changes which have a huge impact on the look and feel of the site. We’ve found that the large majority of our theme customisation can be done by just changing the variables in this file and it has sped up the theming process markedly.
We’ve quietly rolled out these updates to Alaveteli over the past 12 months and the impact of the changes has been encouraging.
Internally, we’ve found our theming projects are faster and more efficient. We conservatively estimate that it takes half the time to make a new theme than it used to.
Thanks to the self-documenting nature of BEM and the styles encapsulated in our settings partial, Alaveteli theming requires a lot less understanding of the platform’s inner workings. Our partners are able to be more self-sufficient and rarely require our intervention to assist with simple customisations.
Maintenance and support of our themes is greatly simplified, as the structure is consistent across projects, we’re able to roll out further changes and fixes in a more predictable way.
Overall, we’re really happy with how the changes worked out and the things we’ve learnt from this project we’ll be carrying into our others too, so look out for changes like across our work in the future.
If you’ve used WriteToThem, you’ll know that two weeks after you submit a message to your MP, we send a follow-up questionnaire to check whether you received a response.
Each year, we collate that data to see how MPs are doing at responding to constituents’ mails*, and we publish the results. (This year, we waited a bit longer than usual so that we could cover a full year since the general election.)
They’re now live, so you can go and check exactly how your own MP did — just enter your postcode.
Some interesting stats
- Because we’ve been running these figures since 2005 (with a gap between 2008-13), we can make some comparisons. We’re disappointed to see that the responsiveness rate of MPs has been steadily declining. In 2005, 63% of respondents indicated that they’d had a reply; this year, that’s down to 50%.
- Before we analysed the data, we thought that new MPs, elected in 2015, would perhaps perform better than the jaded incumbents. Not so: on average ‘old’ MPs responded to 53.07% of constituents’ messages, while the newly-elected managed only 46.10%. One new MP, Marcus Fysh, MP for Yeovil, came in at 635 out of the 642 MPs eligible for inclusion.
- Receiving more mail doesn’t necessarily mean you’ll perform poorly. Notable in this respect is Gerald Kaufman, who managed a 79% responsiveness rate despite having the second largest postbag.
- And being in the public eye doesn’t necessarily impact an MP’s responsiveness: Sadiq Khan and Jeremy Corbyn performed poorly, but have done so in prior years, too. Equally, we suppose it follows that a poor responsiveness level doesn’t necessarily impact on electoral success.
- We were curious to know whether there’s a gender divide when it comes to responsiveness. There is, but it’s very slight: on average male MPs responded to 52% of correspondence; female MPs to 50%.
- And another thing we’ve been asked about, sometimes by MPs themselves. There is no significant relationship between parliamentary constituency size and responsiveness. In other words, having more people in a constituency does not automatically mean that the MP is a poor responder.
Anyway, enough of this — go and check how your MP did, and then tell everyone else to do the same.
*This needs a caveat. Our data only covers messages sent via WriteToThem, and, furthermore, only those messages where users completed the questionnaire. You can see the full methodology on the rankings page.
We held our second TICTeC conference in Barcelona at the end of May. The feedback has been generally very positive, and there are many aspects that we were very pleased with: the quality and diversity of the speakers, the smooth running of the event, the opening up of debates that will continue to resonate in the civic tech world.
But, nothing’s ever perfect, and on reflection there are some aspects, some large, most small, which we can improve for our next big event.
These are conversations that often happen behind the scenes, but we thought it might be useful for anyone else planning a big event or conference, if we share some of the things that didn’t work so well, and our plans for making things better next time.
Please do feel free to join in the discussion in the comments below, whether you were there or not.
It was obvious from the number of hands up, and disappointed faces, that we hadn’t allowed enough time for questions or discussion about the presentations. We’d allocated twenty minutes’ speaking time to each speaker, intending that slot to include questions and discussion. But most speakers filled, or almost filled, their time with their presentation.
Next year we propose formally splitting the slot into 10 minutes of presentation time and 10 minutes of discussion time for each speaker. Oh, and although we were sitting in the front row waving ‘five minutes left’ cards in the speakers’ faces, we appreciate that there are improvements to be made here, too. We’ll use countdown clocks to make it very easy for the speakers to see how much time there is left.
mySociety cares so much about gender balance that we even built an app around it. And yet we could have done better when it came to the gender balance of the panels.
Speakers were chosen on the quality of their submission, and while we don’t believe we have any internal biases we’d be interested to see what happened if we introduced an entirely name- and gender-blind selection process.
For 2016, there were no all-male panels, but overall the gender-split of speakers was 60% male to 40% female (incidentally, the same gender split as made up the delegates as a whole).
Also, there was a strong European and US bias among our speakers, with only 8 out of 62 coming from outside North America or Europe. So we could be criticised for giving a voice to those who already speak quite loudly enough in the civic tech world.
We’ll definitely aim for more equal balances next year.
No-one likes lugging their heavy bags around, and this especially becomes an issue on the final day of an international conference, when people may have checked out of their hotel and have their luggage with them, too.
Yet in our chosen venue, there was nowhere for people to put coats and bags. This is a pretty simple fix — we’ll make sure that there’s a secure cloakroom next year.
Coffee was only available during breaks, and wasn’t self-service.
Conferences run on coffee (and tea) — we know that — but it was whisked away at the end of the breaks and people had to wait to be served when it was there. Next year there will be limitless, self-serve coffee available the whole time. Because it’s important.
Somewhere to network
There was no real networking/seating area. Other than in the auditoria, there wasn’t a space where people could sit and catch up between sessions. That’s partly because Barcelona didn’t pony up the stunning sunny weather we thought we could rely on, so no-one felt inclined to linger in the outdoor space, but still. Something to allow for next time.
Time to mingle
There wasn’t enough time for networking/breaks. We crammed an awful lot into the one and half days, but it meant for a pretty packed programme. Next year we’ll run the event for two full days and allow more break/networking time.
The venue map should have been printed on the main programme, rather than being a separate insert in the bag. That was confusing and yet another piece of paper for people to wrangle.
All hands on deck
We needed more mySociety people on hand. We ran the whole event (including note-taking and session chairing) with a team of seven. With more people, we could have ensured that, for example, the reception desk was always manned. Raising the numbers would also make things a little less stressful for our team.
The usual wifi issue
The wifi wasn’t great. This is a perennial issue, we know. It’s hard to know how a venue is going to perform when there are 140 people with multiple devices each trying to get online.
Next year we’ll try and contact those who ran previous events at the shortlisted venues to find out how things were for them.
Something we all got right
At the last moment, we decided to introduce a Code of Conduct, setting down in black and white what kind of behaviour was not acceptable at the conference, and providing an anonymous route via which to report any contraventions.
We’re glad to say that this wasn’t used — we hope we’re right in surmising that this is because it wasn’t needed — but more than one delegate thanked us for putting it in place, and it’s something we’ll be replicating and refining for future events.