-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow authorities to update request status #37
Comments
It might help to highlight to authority users that when they can already categorise requests already (when the requesting user hasn't done it in time) Making clear when an authority was the last user to classify the request might be worthwhile. |
see issue #41 |
I say just add the authority to the list of people who can always change the status (which is currently just the original requester and admins). I suspect edit wars be infrequent enough to handle on a case by case basis when they arise (largely because I'd like to hope that authorities will be more likely to email us to arbitrate than get into a protracted fight). This should be fairly simple to implement and could cut down on a lot of admin requests (which is likely to become even more of an issue if we start publishing more stats). Being able to highlight who set the status (even if just at the level of requester/authority/admin/other user) would definitely be a nice addition but should be a separate feature. |
I think without some level of auditing (e.g. highlighting who set the status) there's too much risk of substantial numbers of miscategorisations - e.g. from the authorities who think "refused" is an unfair description when they've used an exemption. |
The conversation about this that happened with @dracos on FixMyStreet concluded that if you are going to implement this, you should have two statuses - what the user says and what the body says. When they agree, you just show one status, and on occasions when they don't, you show the disagreement (but don't try to resolve) |
I think WDTK is different in that in almost all cases one can make an objective assessment based on the request thread - typically when we get reclassification requests from authorities we can do this without any problems. In cases where there are multiple valid classifications we would be happy for the requester to make the choice. So I'd prefer not to clutter the request pages (and data model) with multiple classifications, and instead have any conflict escalated to the team to resolve. |
There are currently 86,642 unclassified requests on WhatDoTheyKnow https://www.whatdotheyknow.com/categorise/play A user who has categorised many hundreds of threads has been in touch to suggest that allowing/enabling/encouraging public bodies to classify their responses might help. As discussed above this might be done in such a way where it was publicly made clear the classification was by the public body, and the requester, or perhaps others after a period, would be free to override it, or two statuses could be shown. A public body could be invited to categorise their response by visiting our site by a link the footer of requests. We could send public bodies an email for example:
|
This issue has been automatically closed due to a lack of discussion or resolution for over 12 months. |
We are often contacted by authorities about responses miscategorised by users. In most cases the authorities are correct. We should offer authorities a direct mechanism to reclassify requests if they choose to.
I suggest it defaults to off and we enable it on a case-by-case basis, with the implicit understanding that we would withdraw it if the authority misused it.
We may need some mechanism to deal with "categorisation fights", though those can in principle happen now between users and administrators and I'm not aware of any.
The text was updated successfully, but these errors were encountered: