search

openrightsgroup / cmp-issues

Centralised issue-tracking for the Blocked backend
2 stars 0 forks source link

Add checkboxes and notes to record bad blocks and/or reviews in Admin #175

Closed edjw closed 5 years ago

edjw commented 5 years ago

Can you add two checkboxes into the admin area to record both whether a) an original block was bad and b) a ISP’s review was bad?

Can you also add a single notes box to document thinking on this?

(We could use this to show off bad examples on the front end at some point too.)

dantheta commented 5 years ago

Evaluating the ISP's responses seems like a good idea - I'm not sure of the distinction between the matches-policy field and the bad-original-block field. Would it be possible to provide more information about the anticipated use-case (mainly so we can work out at which level to store the value)?

edjw commented 5 years ago

Thanks for coming back on this Dan. This definitely needs further discussion to work out what the problem is and how to deal with it.

Say we were looking at a CAMRA site and an ISP blocks it because it fits into the category "Alcohol and Drugs".

Is it about "Alcohol and Drugs"? Yes. It's in line with their policy because it is about Alcohol.

But is it reasonable for ISPs to block it and/or make a recommendation to parents that it's unsuitable for children? Is there actually a risk/harm associated with a CAMRA site? I'd say no.

In this case, I'd say it does match the ISP's policy but is still a 'bad' block that shows the weaknesses in the system.

Equally, I don't want to overcomplicate the system we've got going so if we can think of another way to square this I'm all ears.

JimKillock commented 5 years ago

The problem here is that a single observation and judgement is quite subjective. This means we can't easily use Alex's categorisation process to make objective results.

What we could do is flag these sites as "May be harmless". We could then take a look at those sites that have been reported and look for themes and issues.

The way we discussed this at planning stage was that we would need to gain wider information about people's views about categorisation or appropriateness via focus groups, for instance, where we could seek consensus about what children of a particular age ought to be able to view. This would speak to ISPs who are ultimately trying to reflect customer expectation and currently believe their customers want alcohol related sites blocked.

alexhaydock commented 5 years ago

I would agree with a "May be harmless" checkbox or flag as a useful addition.

I've just been struggling with this problem for a site which makes gun grips for handguns. They don't make guns themselves, nor are they an online marketplace. It appears that their service is very bespoke, by direct-contact only, and they're unlikely to deal outside of the US. It seems like the chance of such a site being "harmful" to children is incredibly slim, yet it's also arguable that a broad category of "Weapons" would be appropriate for the site.

This is the kind of issue that such a checkbox would be useful for, so I can flag these for later scrutiny.

dantheta commented 5 years ago

closed in favour of #184

JimKillock commented 5 years ago

I'm not sure that "may be harmless" is the same as "egregious".

(1) A block of a pub is bad as that site is "harmless" but in line with policy

(2) A block of a cannabis oil site as "drugs" is out of line with policy, and if maintained, is "egregious"

dantheta commented 5 years ago

Ah, sorry - I'd thought that #184 subsumed this ticket.

To clarify, should a third checkbox "May be harmless" be added alongside "Add to frontend" and "Egregious block" ?

dantheta commented 5 years ago

@JimKillock @edjw

To clarify, should a third checkbox "May be harmless" be added alongside "Add to frontend" and "Egregious block" ?

Is there still time left in the analysis project for this field to be useful?

JimKillock commented 5 years ago

I think so yes, so long as we can get to a list.

dantheta commented 5 years ago

This has been added, and the same filter and count functions provided for "featured block" are available for this flag.