Reduce Gold-Standard of site-admin work

[RichardTaylor]

Are there things we could change to make the site less onerous to run on a day-to-day basis?

Ideas:

• Don't spend time battling redaction via censor rules, especially of PDFs, when we can hide messages and republish key elements via prominence reasons and annotations. Sometimes uploading a replacement document is easier than making redaction via the system work. (We have related tickets on improving censor rules, and improving the formatting of prominence reasons).

• Don't deal with all errors/bounces, leave some up to users to propose fixes for. See https://github.com/mysociety/alaveteli/issues/6871#issuecomment-1167426101 (I'm less keen on this, but we could certainly do more to help users help the core admin team better). There's the linked issue of Pro users being provided with the service they paid for. See also: Commercial use policy.

• In the past we've had the suggestion of answering less email - ignoring more. We've tried tracking emails / alerts etc which we could just ignore, but most of what we could ignore comes from prospective users who are struggling with FOI / our system so they're threads where we actually do want to help, even if we don't have to.

[mdeuk]

I’m not in favour of this - I don’t think we should aim to lower standards just so we can free up capacity.

What I would like us to do is consider what we can automate - e.g. lower value tasks (such as sending acknowledgement type correspondence), and adopting more of a workflow process.

We quite often fixate on an individual case for some time - but that isn’t always the right thing to do. For example, when we are at capacity, are we prioritising tasks in the right way? We should be able to identify tasks that are a “not immediate” necessity, log them (if need be), and act on them within a given timeframe.

The industry lingo here is “work smarter, not harder” - meaningless waffle, but it is what it is.

[FOIMonkey]

I don’t think we should aim to lower standards just so we can free up capacity.

+1 We should be looking at greater automation and other process improvements before thinking about lowering standards.

At exceptionally busy times, I think it is ok to triage issues, (maybe marking some as "not now") but we should still aim to deal with these promptly once there is the capacity to do so.

[RichardTaylor]

A good example of how much of a gold-standard service we provide comes when considering how we respond to issues of problematic data in responses, where the public body is not providing a replacement response.

How much work do we put in to rescue substantive responses, and to censor material ourselves.

There are lots of tools/feature suggestions which would make this less of an issue including hiding individual attachments, more effective censor rules and a feature for admins to upload files.

[RichardTaylor]

Should we always obtain and upload material we spot has been released via a link / file transfer service?

[FOIMonkey]

Should we always obtain and upload material we spot has been released via a link / file transfer service?

Expiring links, probably yes, other things, probably not unless requested/able to be automated.

[WilliamWDTK]

Should we always obtain and upload material we spot has been released via a link / file transfer service?

Expiring links, probably yes, other things, probably not unless requested/able to be automated.

I'm inclined to say that anything capturable by the Internet Archive should just have a request submitted to archive it, if it has not already been archived. Sharepoint or whatever probably won't work for this, though.

[RichardTaylor]

If we're making a best efforts attempt to remove a user's name from correspondence do we just do a censor rule for their username, or do we try one for their first and surname separately? A little more effort can prevent further correspondence in a case where a requester is addressed by their surname, or their surname is used in a filename.

Related:

• https://github.com/mysociety/alaveteli/issues/4922

[RichardTaylor]

When it comes to responding to a subject access request the ICO advise:

You should perform a reasonable search for the requested information.

https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-of-access/

What is reasonable depends on the context and the details of the request, but it's an area where we should be careful about going beyond what's required.

[mdeuk]

When it comes to responding to a subject access request the ICO advise:

You should perform a reasonable search for the requested information.

https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-of-access/

What is reasonable depends on the context and the details of the request, but it's an area where we should be careful about going beyond what's required.

I believe we’ve discussed this one before.

We could take a less liberal reading of some requests - but we do need to be wary that we may simply be making more work for ourselves, as past experience has shown.

Having a regimented process of ensuring we know enough so we can locate the data makes sense (and can be very helpful!), but we need to have cognisance that sometimes [a] the requester doesn’t know what we hold, or [b] we hold a lot of data, and need to take care that we have taken the time to do a thorough search.

It’s worth noting that our acknowledgement for Right of Access / Subject Access Request cases states:

Getting what you need more quickly

It may help you, and us, if you can focus your request and let us know what information you are seeking and why. You may wish to restrict your request to information related to particular time periods, or particular aspects of your use of our service, for example. Please reply to this email with further details, if so.

We are a relatively small charitable organisation and we would like to ensure our resources are used as efficiently as possible. We also want to be as helpful as we can, and our experience has shown that where focused requests are made we can respond more quickly and provide more tailored assistance.

… this will hopefully help to get more refined requests. Another logical step would be to simply ask for clarification if the request is too vague.

I generally regard DPA matters as “measure twice, cut once”. Speed isn’t the ultimate aim, and if it means it takes a little longer - so be it.

[RichardTaylor]

Reasons we do "Gold Standard" work:

• Dealing with something properly at first hopefully reduces the chance of it becoming a bigger / ongoing issue.
• We want to provide the best service we can.
• We care about our reputation and that of the service.

[mdeuk]

Should we always obtain and upload material we spot has been released via a link / file transfer service?

Expiring links, probably yes, other things, probably not unless requested/able to be automated.

I'm inclined to say that anything capturable by the Internet Archive should just have a request submitted to archive it, if it has not already been archived. Sharepoint or whatever probably won't work for this, though.

https://web.archive.org/save is definitely a friend here. I wonder if we could automate submission and retrieval, perhaps as a cronjob or similar?

[RichardTaylor]

We’re getting into passing on messages from public bodies to users in data breach cases, saying eg. please delete the material if you hold it. There’s disagreement among our team over if pointing bodies to the user-user messaging system suffices or if we need to send such direct email. Bodies could even communicate with requesters in public on the thread when providing further responses.

A concern is a message via the user-user messaging system might be ignored, especially if the user has previously received spam or inappropriate messages via the system.

[RichardTaylor]

We currently respond to correspondence via Twitter DMs. This is a hassle for those dealing with front-line support as we have to login to Twitter to reply.

We have some standard responses which others in the organisation can use to point people to the contact form / email, however we could turn Twitter DMs off.

[WilliamWDTK]

I'd support turning off Twitter DMs. We can just, as we do today, refer people to our website for help in the bio (or whatever it's called).

I don't think they add anything from our perspective, because it's hard to help people over Twitter, and we get very little contact through Twitter at the moment.

[mdeuk]

I'd support turning off Twitter DMs. We can just, as we do today, refer people to our website for help in the bio (or whatever it's called).

I don't think they add anything from our perspective, because it's hard to help people over Twitter, and we get very little contact through Twitter at the moment.

We did ponder this before - I don't see a problem in doing it, but I would note that it has proved useful in the past, so I wouldn't like to turn it off.

We do already direct people to the contact form - perhaps something to investigate is whether or not we can have an auto-reply, preferably context based, which could direct people accordingly. Hootsuite (which marketing use) might be able to do it.

[sallytay]

+1 on this from @mdeuk

The twitter DM notifications were moved back to the inbox on request of the team for us to process, previously they were managed centrally by the mySociety comms team.

We do direct people to the contact form, and the process on the Wiki says that we should send one of the standard responses to advise people to re submit their query via the contact form https://wdtkwiki.mysociety.org/wiki/Twitter

We don't get many so I don't think this really increases the work load.

Tagging @MyfanwyNixon in this as it would be a mySociety comms decision to turn off the DMs.

Sally

[MyfanwyNixon]

I'm perfectly happy for DMs to be turned off - we've done this elsewhere, eg across mySociety's Facebook pages, as we never got high quality messaging coming through those channels.

[RichardTaylor]

If we're making a best efforts attempt to remove a user's name from correspondence do we just do a censor rule for their username, or do we try one for their first and surname separately?

Routinely, even where we have a strong legal basis for continuing to publish a user's name in association with their requests, we make an offer to remove their name where it is technically easy for us to do so. The extent of effort we put into that is one area where we can get drawn into doing large amounts of work we don't have to do.

In some cases doing the work might reduce the risk of complaints and ICO referrals so save us time in the long-run.

[RichardTaylor]

Making the case to continue to publish material, or even keep it accessible to requesters, in the face of take-down requests could be placed on this list. I think challenging unjustified takedown requests is at the core of what we do, and need to do, to run a credible and impactful service but there is another argument that service could continue to have some use even if we didn't do that and just acquiesced when someone wasn't happy with what's being published and asked us to remove it.

[RichardTaylor]

The degree to which we note issues arising from support correspondence on tickets is another question.

• Do we comprehensively add relevant tickets, and note on tickets, when relevant?
• Do we always update support threads to note, and link to, the tickets, and ticket comments, which have arisen?

The gold-standard of this is something which we can drop in-order to create capacity to deal with more incoming work, while being mindful of wanting to prompt, and inform decisions on, technical improvements which have the potential to reduce the need for admin work, and make the work we do need to do easier.

[RichardTaylor]

Reducing the quality of reports to the ICO in data breach cases has been suggested. These are often substantial, excellent, pieces of work, but we know if they are effective. (Related https://github.com/mysociety/whatdotheyknow-theme/issues/1128 )

In cases where we have reason to believe the public body are working openly and honestly with the ICO there may be no need for a detailed report from us. However it's hard to know exactly what the public body are saying to the ICO unless we're copied in.

[RichardTaylor]

Republishing tables in responses which are illegible or hard to read as the system doesn't display HTML tables in responses is an example of Gold-Standard work which is currently often, but not always, done. Related: https://github.com/mysociety/alaveteli/issues/1528

[HelenWDTK]

Closing this general issue in favour of looking at specific individual issues as and when they arise. I think we've made a number of process improvements since this was first opened.