Skip to content
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

Open
JimKillock opened this issue Feb 12, 2019 · 12 comments
Open

Add egregious blocks info to DB #184

JimKillock opened this issue Feb 12, 2019 · 12 comments
Assignees
Labels

Comments

@JimKillock
Copy link
Member

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.

@edjw
Copy link

edjw commented Feb 12, 2019

Is this different to what we're talking about in #175?

@JimKillock
Copy link
Member Author

JimKillock commented Feb 12, 2019

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.

@alexhaydock
Copy link
Member

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.

@JimKillock JimKillock changed the title Add genrgious blocks info to DB Add egregious blocks info to DB Feb 12, 2019
@dantheta
Copy link

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).

@alexhaydock
Copy link
Member

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?

@JimKillock
Copy link
Member Author

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.

dantheta added a commit to openrightsgroup/Blocking-Middleware that referenced this issue Feb 13, 2019
dantheta added a commit to dantheta/blocked-frontend-py that referenced this issue Feb 13, 2019
@dantheta
Copy link

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).

@JimKillock
Copy link
Member Author

JimKillock commented Feb 14, 2019 via email

@edjw
Copy link

edjw commented Feb 15, 2019

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…

Click Egregious blocks when it's a block that's clearly against the ISP's policy, but the ISP's refused to correct it after a report has been submitted.

Click Add to Frontend when the story about the block would look good on the frontend of Blocked to demonstrate the failings of the filters and the usefulness of the Blocked tool. For example, this might be charities, small businesses, or educational resources. This should be ticked even when the block was lifted by the ISP to show the system failing if it wasn't for our tool. These sites won't go directly onto the Blocked front-end but are available for further consideration

@ei8fdb
Copy link

ei8fdb commented Feb 18, 2019

Click Egregious blocks when it's a block that's clearly against the ISP's policy, but the ISP's refused to correct it after a report has been submitted.

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

  1. Help: Does the ISP refuse to correct the block even after a report? Do you believe this block is against the ISP's policy? Clicking here allows you to flag it as an egregious block.

checkbox: "egregious block"

  1. Is this block egregious? Is this block against the ISP policy? Do they refuse to unblock it?

checkbox "this is egregious"

If you could show what space there is to use, I'd maybe be able to suggest some better options.

@edjw
Copy link

edjw commented Feb 18, 2019

Thanks Bernard. Our summary of the ISP's policy is shown in the interface next to the data entry area. Here's a screenshot of what it looks like
site_report

@dantheta
Copy link

dantheta commented Jun 5, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants