officers.html.erb

<% @title = "FOI officer questions" %>

<%= render :partial => 'sidebar' %>
<div id="left_column_flip">

<h1 id="officers"><%= @title %> <a href="#officers">#</a> </h1>

<dl>

<dt id="top">I just got here from bottom of an FOI request, what is going on? <a href="#top">#</a> </dt>

<dd><p><%= site_name %> is a service run by a charity. It helps ordinary members
of the public make FOI requests, and easily track and share the responses.</p>

<p>The FOI request you received was made by someone using <%= site_name %>. You can
simply reply to the request as you would any other request from an individual.
The only difference is that your response will be automatically published on
the Internet.
</p>
<p>If you have privacy or other concerns, please read the answers below.
You might also like to read the <a
href="/help/about">introduction to <%= site_name %></a> to find out more about what
the site does from the point of view of a user. You can also search the
site to find the authority that you work for, and view the status of
any requests made using the site.

<p>Finally, we welcome comments and
thoughts from FOI officers, please <a href="/help/contact">get in touch</a>.
</p>
</dd>

<dt id="responses">Why are you publishing responses to FOI requests? <a href="#responses">#</a> </dt>

<dd>We think there are lots of benefits. Most importantly it will encourage the
public to be more interested and involved in the work of government. We
also hope that it will reduce the number of duplicate requests on any
subject that a public body will receive. Given that Freedom of Information
responses contain public information, which anybody could easily request
again from the public authority, we think there should be no reason not to
publish it widely.
</dd>

<dt id="realpeople">Are the people making requests real people? <a href="#realpeople">#</a> </dt>

<dd>Yes. For the purposes of keeping track of responses we use
computer-generated email addresses for each request. However, before
they can send a request, each user must register on the site with a
unique email address that we then verify. You can search this site and
find a page listing all requests that each person has made.
</dd>

<dt id="email_only">An email isn't a sufficient address for an FOI request! <a href="#email_only">#</a> </dt>

<dd>Yes it is. This
<a href="http://www.whatdotheyknow.com/request/1142/response/2894/attach/5/20080806100741260.pdf">letter from the ICO to Rother District Council</a> gives guidance on the matter, specifically
in the context of requests made via <%= site_name %>.
</dd>

<dt id="vexatious">Aren't you making lots of vexatious requests? <a href="#vexatious">#</a> </dt>

<dd><p><%= site_name %> is not making any requests. We are sending requests on
behalf of our users, who are real people making the requests. </p>
<p>Look at it like this - if lots of different people made requests from
different Hotmail email addresses, then you would not think that Microsoft were
making vexatious requests. It is exactly the same if lots of requests are made
via <%= site_name %>. Moreover, since all requests are public it is much easier
for you to see if one of our users is making vexatious requests. </p>
<p>If that isn't enough for you, the
<a href="http://www.whatdotheyknow.com/request/1142/response/2894/attach/5/20080806100741260.pdf">letter from the ICO to Rother District Council</a> gives some guidance on the matter.</p>
</dd>

<dt id="spam_problems">I can see a request on <%= site_name %>, but we never got it by email!<a href="#spam_problems">#</a> </dt>

<dd><p>If a request appears on the site, then we have attempted to send it to
the authority by email. Any delivery failure messages will automatically
appear on the site. You can check the address we're using with the "View FOI
email address" link which appears on the page for the authority. <a
href="/help/contact">Contact us</a> if there is a better address we can
use.</p>
<p>Requests are sometimes not delivered because they are quietly removed by
"spam filters" in the IT department of the authority. Authorities can make
sure this doesn't happen by asking their IT departments to "whitelist"
any email from <strong>@<%= AlaveteliConfiguration::incoming_email_domain %></strong>.
If you <a href="/help/contact">ask us</a> we will resend any request,
and/or give technical details of delivery so an IT department can chase
up what happened to the message.
</p>
<p>Finally, you can respond to any request from your web browser, without
needing any email, using the "respond to request" link at the bottom of
each request page.
</dd>

<dt id="days">How do you calculate the deadline shown on request pages?<a href="#days">#</a> </dt>

<dd>
<p>The Freedom of Information Act says:</p>

<blockquote><p>A public authority must comply with section 1(1) <strong>promptly</strong> and
in any event not later than the twentieth working day following the date of
receipt.</p></blockquote>

<p>The nerdy detail of exactly how weekends are counted, and what happens if
the request arrives out of office hours, is just that - detail. What matters
here is that the law says authorities must respond <strong>promptly</strong>.</p>

<p>If you've got a good reason why the request is going to take a while to
process, requesters find it really helpful if you can send a quick email with a
sentence or two saying what is happening. </p>

<p>FOI officers often have to do a lot of <strong>hard work</strong> to answer
requests, and this is hidden from the public. We think it would help everyone
to have more of that complexity visible.</p>

</dd>

<dt id="days2">But really, how do you calculate the deadline?<a href="#days2">#</a> </dt>

<dd>

<p>Please read the answer to the previous question first. Legally, authorities
must respond <strong>promptly</strong> to FOI requests. If they fail to do that,
it is best if they show the hard work they are doing by explaining what is
taking the extra time to do.
</p>

<p>That said, <%= site_name %> does show the maximum legal deadline
for response on each request. Here's how we calculate it.</p>

<ul>

<li>If the day we deliver the request by email is a working day, we count that
as "day zero", even if it was delivered late in the evening. Days end at
midnight.  We then count the next working day as "day one", and so on up to
<strong>20 working days</strong>.</li>

<li>If the day the request email was delivered was a non-working day, we count
the next working day as "day one". Delivery is delivery, even if it happened on
the weekend. Some authorities <a href="http://www.whatdotheyknow.com/request/policy_regarding_body_scans#incoming-1100">disagree with this</a>, our lawyer disagrees with them. </li>

<li>Requesters are encouraged to mark when they have <strong>clarified</strong>
their request so the clock resets, but sometimes they get this wrong. If you
see a problem with a particular request, let us know and we'll fix it.</li>
</ul>

<p>The date thus calculated is shown on requests with the text "By law,
Liverpool City Council should normally have responded by...". There is only
one case which is not normal, see the next question about
<a href="#public_interest_test">public interest test time extensions</a>.
</p>

<p>Schools are also a special case, which <%= site_name %> displays differently.
</p>

<ul>
<li>Since June 2009, <strong>schools</strong> have "20 working days
disregarding any working day which is not a school day, or 60 working days,
whichever is first" (<a href="http://www.opsi.gov.uk/si/si2009/draft/ukdsi_9780111477632_en_1">FOI (Time for Compliance with Request) Regulations 2009</a>). <%= site_name %> indicates on requests to schools that the 20 day deadline is only
during term time, and shows them as definitely overdue after 60 working days
</li>
</ul>

<p>If you're getting really nerdy about all this, read the <a href="http://www.ico.gov.uk/upload/documents/library/freedom_of_information/detailed_specialist_guides/timeforcompliance.pdf">detailed ICO guidance</a>.
Meanwhile, remember that the law says authorities must respond
<strong>promptly</strong>. That's really what matters.</p>

</dd>

<dt id="public_interest_test">How do you reflect time extensions for public interest tests?<a href="#public_interest_test">#</a> </dt>

<dd>

<p>The Freedom of Information Act lets authorities claim an indefinite time
extension when applying a <strong>public interest test</strong>.  Information
Commissioner guidance says that it should only be used in "exceptionally
complex" cases
(<a href="http://www.ico.gov.uk/upload/documents/library/freedom_of_information/detailed_specialist_guides/foi_good_practice_guidance_4.pdf">FOI Good Practice Guidance No. 4</a>).
<%= site_name %> doesn't specifically handle this case, which is why we use the
phrase "should normally have responded by" when the 20 working day time is
exceeded.
</p>

<p>The same guidance says that, even in exceptionally complex cases, no
Freedom of Information request should take more than <strong>40 working days</strong>
to answer.  <%= site_name %> displays requests which are overdue by that much
with stronger wording to indicate they are definitely late.
</p>

<p>The Freedom of Information (Scotland) Act does not allow such a public
interest extension. <%= site_name %> would like to see the law changed to either
remove the extension from the UK Act, or to reintroduce an absolute time limit
of 40 working days even with the extension (the House of Lords <a
href="http://www.publicwhip.org.uk/division.php?date=2000-10-17&amp;number=1&amp;house=lords">voted
to remove</a> provision for such a time limit during the initial passage
of the UK Act through Parliament).
</p>
</dd>

<dt id="large_file">How can I send a large file, which won't go by email?<a href="#large_file">#</a> </dt>

<dd>Instead of email, you can respond to a request directly from your web
browser, including uploading a file. To do this, choose "respond to request" at
the bottom of the request's page. <a href="/help/contact">Contact us</a> if it
is too big for even that (more than, say, 50Mb).
</dd>

<dt id="names">Why do you publish the names of civil servants and the text of emails? <a href="#names">#</a> </dt>

<dd>We consider what officers or servants do in the course of their employment
to be public information. We will only remove content in exceptional
circumstances, see our <a href="/help/privacy#takedown">take down policy</a>.
</dd>

<dt id="mobiles">Do you publish email addresses or mobile phone numbers? <a href="#mobiles">#</a> </dt>

<dd><p>To prevent spam, we automatically remove most emails and some mobile numbers from
responses to requests.  Please <a href="/help/contact">contact us</a> if we've
missed one.
For technical reasons we don't always remove them from attachments, such as certain PDFs.</p>
<p>If you need to know what an address was that we've removed, please <a
  href="/help/contact">get in touch with us</a>. Occasionally, an email address
forms an important part of a response and we will post it up in an obscured
form in an annotation.
</dd>

<dt id="copyright"><a name="commercial"></a>What is your policy on copyright of documents?<a href="#copyright">#</a> </dt>

<dd>Our Freedom of Information law is "applicant blind", so anyone in the
world can request the same document and get a copy of it.

If you think our making a document available on the internet infringes your
copyright, you may <a href="/help/contact">contact us</a> and ask us
to take it down.  However, to save tax payers' money by preventing duplicate
requests, and for good public relations, we'd advise you not to do that.
</dd>

</dl>


</dl>

<p><strong>If you haven't already</strong>, read <a href="/help/about">the introduction</a> --&gt;
<br><strong>Otherwise</strong>, the <a href="/help/credits">credits</a> or the <a href="/help/api">programmers API</a> --&gt;

<div id="hash_link_padding"></div>


</div>