-
Notifications
You must be signed in to change notification settings - Fork 1
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 additional MediaVault-specific permissions to users if needed #300
Comments
I think we should have two options here: read-only, for researchers/academics/etc., and then a separate user setting that enables people to submit. |
When you say submit, does that just mean archiving a new piece of media, or submitting a MediaReview too? And would this archived media be part of the public corpus or just a private "my own archive" area? Chris and I have discussed the possible malicious consequences of letting people add to the public corpus, and our liability in all cases of letting users have us scrape things. We'll want to make sure we have really good moderation capabilities. (It's good to know about these permissions in advance though, thanks! I'll be sure we're robust enough to support this.) |
Mmm I meant specifically archiving media -- we're supporting our three FactStream partners in creating MediaReview; I don't think we want to expand that. Others can use the FCMT or json-ld embeds, as they've done with ClaimReview. Actually, thinking through it, if the archiving happens at the point of creating the MediaReview (and then us ingesting the data and scraping), we don't really need the separate permissions. Though we do want to be clear that Vault is opt-in, Insights is opt-out. |
Yup, @cguess can verify, but the architecture we're building toward is automatically scraping new MediaReviews to the Vault at time of entry. May even already be happening.
Correct! In fact, right now the idea is that users don't even opt in to Vault; they're just quietly given permission by an admin if the admin recognizes that a given applicant or user should have it. This is based on some conversation on our last group meeting about keeping Vault's visibility low. There is a middle ground: don't pitch Vault on the public FCI site, but perhaps let all confirmed / logged-in Insights users see a Vault pitch page that gives them a vague description and lets them request access. It just depends on how much visibility we want to provide. |
Although also, we don't actually have a concept of "opting out" of Insights currently. If you have an account, you have access to the data. The architecture currently has no path for being an authenticated user who has opted out of Insights access. |
Ah want to clarify, "opt out" is for the fact-checkers and us scraping their data. Say Full Fact doesn't want their data included in the download dataset, we want to give them the option to ask us to stop scraping their data. |
Oh, I see. 👍 Will that sort of "data source management" ever need to be part of the admin interface? If so I can make room for it in the architecture, though I expect that for a while it'll be baked into the scraper code. |
If there are any specific sub-permissions for Media Vault users, make sure they're settable using the role/permissions system (from #282).
The text was updated successfully, but these errors were encountered: