-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add egregious blocks info to DB #184
Comments
Is this different to what we're talking about in #175? |
Possibly not, but I don't know. i am looking at the spreadsheet here: https://docs.google.com/spreadsheets/d/1lTOwREoSWW8rwAFOUqpxQTYl8NpGm5Ds9WmnmqghYIk/edit#gid=0 and wondering if this is in the DB and retrievable to publish on the front end. |
It isn't in the DB yet, though I did suggest to Ed that we add it. I feel like that was part of the intent of #175, though it's expressed much more concisely in this ticket. I definitely agree, as the most egregious blocks could be accompanied with some text and description and would make a great thing to publish on the Blocked frontend to show both the successes of the tool and the failings of the filters. |
Yep, that makes sense. Does a checkbox capture enough information? Would a star rating be useful for capturing levels of egregiousness (sp?!) We could then score reports on the quality of the original block, the quality of the responses and the eventual outcome (matches_policy). |
I wonder what @JimKillock thinks, but personally I think maybe two checkboxes would be useful. One for "egregious block" and maybe a second for "featured block", which could be used to tag the blocks which are noteworthy and interesting enough to be featured on the main Blocked site? |
I like the suggestion of two tickboxes. I think it's too subjective to have a star rating. However a block that seems to be clearly in violation of the policy leading to a particularly perverse result seems reasonably easy to judge. |
I've added the checkboxes. It's worth noting that the flag values are stored specific to the ISP report record at the moment; it's possible that flagging this against the ISP itself might be more appropriate (as in, all blocks against this site are egregious). |
I think it needs to be per ISP or filter setting as you have set it, I would say. Policies vary and so on.
It could be that a block is egregious in all circumstances but I’m not sure that it matters as such?
|
Can we make it clearer when to tick the checkboxes that say "This is an egregious block" and "Add to frontend site "featured blocks""? This would help future users of the functionality and help us have a shared understanding when using these analytical tools. It's not necessarily obvious when to tick each one at the moment. We could add or edit copy to achieve this. We could use tooltips or some explanatory text underneath the checkbox label, possibly in grey to show it's supporting copy. From talking to @alexhaydock and reading comments from Alex and @JimKillock around here, it seems like the way we want to use the buttons is like this below. This should help us write the copy described above in the right way…
|
Sorry for all the questions...but: Is there any guidance that can be given to the user on what "clearly against the ISP's policy? Could it be tricky for the researcher to make the required judgement? Could you give a screenshot of the current interface? Options
checkbox: "egregious block"
checkbox "this is egregious" If you could show what space there is to use, I'd maybe be able to suggest some better options. |
The egregious block field is present in the backend, but we're not currently using it anywhere in the frontend. Perhaps they could be considered a superset of the "featured blocks" set. |
Rather than storing the egregious blocks in a separate spreadsheet only, could we add this information into the Blocked DB?
This could be a flag: "Egregious error"; and a description field.
On the public side, this could be a simple list.
The text was updated successfully, but these errors were encountered: