Responsiveness Stats are Misleading

[amandabee]

This particular agency cares a lot about their profile, which is good. And they've pointed out that our responsiveness figure is not accurate:

https://www.muckrock.com/agency/king-county-73/king-county-directors-association-kcda-kent-33228/

https://muckrock.zendesk.com/agent/tickets/125688
https://muckrock.zendesk.com/agent/tickets/118174

We need to rephrase "responsiveness" to reflect what the stats actually show (time to completion) -- if they're getting back to the user with an acknowledgement and a time frame for compiling the requests, that would be what I expect from "response" time.

[mitchelljkotler]

1. Update the language
2. Review on a jurisdiction level whether the law requires a response or producing responsive documents by deadline
3. Integrate Albert's suggestions

[amandabee]

@morisy and @amandabee to refine the language (in a support Q&A?)
__
We also want to integrate Albert's changes.

[morisy]

data on whether it's initial response or final response is available at https://www.rcfp.org/open-government-guide/

[amandabee]

1. Miranda and I do not recall, any longer, what "Albert's Changes' refers to.

2. RCFP can shed light on what the deadline in the law applies to. Their Washington page says "The agency can meet its five-day obligation simply by acknowledging the request and giving a reasonable estimate for how long it will take to respond."

I think overhauling our whole system so that we know whether any one state requires the request to be COMPLETED by the deadline in the law, or just requires an acknowledgement, is a larger task. In this case there isn't any indication that the agency is not complying with the law -- they respond within five days and give an estimate. They seem to meet those estimates.

I am inclined to say that we need to pull the "by law" section, or figure out how to update it so that it correctly reflects whether the law says acknowledge or complete.

It is confusing that there is a box that lists things like the number of "overdue" requests but there's no way to directly access the requests we're considering "overdue"