Topic on Talk:Reading/Readers contributions via Android

Potential problems:

*probability of a large number of vandalism uploads (e.g. profanities instead of article title)

*checking and maintenance burden on Commons

*if the recordings will automatically be linked to Wikidata, burden on Wikidata community to verify uploads

*review of uploads would likely be done by a small subset of experienced anti-vandal editors, and in any case they will have to know IPA or speak the relevant language (which will likely be a language foreign to the wiki from which the recording came)

Necessary countermeasures:

*uploads must be added to a maintenance category or have a revision tag

*recordings must not be automatically entered in Wikidata or linked to from articles; a mechanism to queue for review before use would have to be devised

The consequence of this is that unless communities at large care about spoken titles, the maintenance burden will be resented à la Gather.

The mockup of the moderation mechanism is very un-wiki and appears to involve the app only. It would be essential before proceeding to propose and gain support for a desktop-based review mechanism which involves ordinary wiki processes, for example, making it clear how to unlink the Wikidata item and/or propose deletion of the file on Commons. As with Gather, building a new type of feature with a different moderation UI, not having the accustomed features or means of use, is likely to lead to rejection by core users who do the reviewing.

Thank you for pointing out these issues @BethNaught.

We are working on providing even more context for this consultation, but reading some of your concerns, particularly the one below, I know the purpose is still not clear:

"The consequence of this is that unless communities at large care about spoken titles, the maintenance burden will be resented à la Gather."

Learning from Gather and feedback about talking to the community too late in the product development process, the original purpose of this consultation was to ask what communities care about...before we even fleshed ideas out. As you just posted here, "collaboration on ideas from the start". Specifically we want to identify ways that readers could help editors with existing queues, backlogs or simply add content that editors found valuable. We are explicitly asking, "what would be useful to our communities" and asking for new ideas. We put our own ideas into the mix to start the dialog: they are our best or typical guesses, so hearing your concerns about them are also valid. The prototypes were not in the original consultation but we added them up on hearing feedback that the original concepts could use illustration. We want to adjust the consultation to make this more clear and get new ideas or more meta-feedback like yours; do you have any suggestions around this or any interest in partnering? We worked with @Alsee around related pages and it seemed to go pretty well.

The moderation issues you bring up are valid. Having worked on Gather, I now understand why avoiding a desktop wiki moderation is so problematic. This is going to sound daft given the previous sentence, but one thing I would like to tease out from your comments and Risker's checklist for content-creation extensions is, is there any possible room for pre-vetting by other app users before it reaches the desktop queue (as suggested here) - the idea would be that X% of readers would have to agree that something was okay before it went live and showed up in recent changes. Would recording the mass-vetting in logs work? Given your comments, I fully expect that the answer for anything open-ended is likely "no". If that is the case, can you think of any system by which we can use the vast scale of readers to alleviate the burden? I am not interested in re-living Gather, so rest assured your clarity on this issue is welcome. Thanks again.

Talking about "pre-vetting" by readers: there seem to me to be two possible objections to this.

1. Problematic content is problematic content, however readers are able to access it. Therefore at any stage in the process, per Risker, content needs to be immediately deletable. If content is only passed to the desktop review queue after a certain number of readers have approved it, this violates the principle. Therefore all submitted content must be accessible from the desktop review interface, from where it can be absolutely rejected (and hence deleted since the upload is only stashed).
2. As soon as readers record a clip or upload a photo, they are contributors. Therefore they should be able to expect to get equal treatment regardless of platform, as far as technology allows. Therefore allowing their contributions to be rejected by possibly malicious readers, and not a policy-based on-wiki process, is unfair.

A possible compromise for these issues would be that readers can upvote and downvote submitted, but not accepted, uploads. The desktop review queue can be filtered, e.g. see most upvoted (for those who wish to focus on adding new content), most downvoted (for anti-vandalism patrollers). Desktop patrollers could flag bad submissions for removal, but for fair treatment the Commons community may decide that a certain user right is necessary to reject (and so delete) queued submissions. This would initially be admins, as they can already speedy delete vandalism, but the right could be unbundled.

(Edit: of course, objection 2 could also be taken to imply that all reader app contributions should go live immediately in some sense. But pragmatically, considering how mobile uploads have fared in the past, I suspect that wouldn't fly.)

In my opinion, the initial configuration should be that everything should be kept stashed until approved via the desktop interface. As happened with the selfie problem with mobile uploads, the average quality could be poor or vandalistic. If, however, the scheme is a success, going live based on X reader approvals could be considered. The problem with radically widening contribution channels is that you don't know what the quality will be like; I think there will be more acceptance if the feature were rolled out gradually.

@BethNaught thanks for explaining this further and also mapping out some possibilities. Both the upvoting and the 'stashing' seem like good alternatives and I agree that stashing, being more conservative, is probably the way we would want to start. Obviously, this will impact usage as one of the most satisfying elements of Wikimedia is watching your submission go live in real time, but I think we're learning here*. We'll just need to develop a feedback notification to let them know if/when the submission is subjected or rejected, which is something we need to instrument anyway. *I should note that for editing wikidata descriptions on Android, the expectation is that initially edits will go live in real time after passing through the abuse filters. In my mind, this is a different beast, but curious to hear if you feel otherwise.

I think Alsee makes some intersting points about how we treat these reader-contributors in Awkward user model. It's a difficult choice. As for the wikidata description editing, I agree that is different, as it's a very simple workflow compared to taking a picture/voice clip, the uploading it, then adding it to an article. Also Wikidata folks seem OK with it so I have no complaints.