Topic on Talk:Reading/Readers contributions via Android

I've been thinking about commenting on "reader contributions" for weeks, but I keep putting it off because I want to be positive, and because it's hard to explain what I'm trying to say. But I'll try.

The current Wikipedia model (basically) has two categories of users:

• Readers: Simple. They come seeking information, they are hopefully well served, and they hopefully leave happy. Our core mission is accomplished.
• Editors: Editors have free access to powerful tools, editors are largely trusted to do almost anything at will.

Why it works:

• Editing tools are publicly accessible, but they are presented with low-profile links in a basically Pull technology. Someone who isn't particularly interested in editing will ignore the links. If they do randomly explore the links they'll realize it's not want they're looking for. They move on. The tools are generally only used by people who take a serious interest in the project.
• We expect to be able to communicate with other editors. That is how we teach and socialize them.
• People who make bad edits generally quit, or eventually get blocked. Either way, the inflow of bad contributions is terminated. That quality review happens in the natural course of editor-editor interaction.
• We don't complain (much) about poor edits from newbies because it's part of the learning process. If they stick around, we expect them to start learning policies and how we work. It's the on-ramp to becoming a skilled, powerful, and trusted editor. One experienced, skilled, trusted editor is more valuable than a horde of contributions by a horde of random internet yahoos.

The Readers Contributions idea basically suggest creating a third class of user.

• The "reader tools" are closer to a Push technology. Some prominent call-to-action is splashed on top of each article served, actively soliciting contributions from people who didn't come to Wikipedia to contribute.
• There is zero expectation for these users to communicate. Anyone who is unwilling or unable to participate in discussions is a problem... a problem that we can only fix with the BLOCK button.
• There is zero expectation that these users know anything.
• There is zero expectation that these users learn anything.
• There is zero expectation that these users have any competence.
• There is zero expectation that these users have any meaningful interest in the project.
• The target audience is explicitly "causal", with no real expectation of progress. The only avenue of progress is to abandon the "reader tools" and find the edit button & community pages.
• These users are walled-off from, or shielded from, the general powerful editing tools. (When in fact the tools are just a click or two away.)
• These users are treated like children who need extraordinary supervision by "real editors", because of the above points.

It's almost silly to impose elaborate "editor moderation" systems when these people could simply make the edit themselves by clicking the edit button. But those systems are necessary because of how these features are being presented to users, because of the audience you are targeting.

Perhaps it's not politically correct to say this out loud, but the average editor is more intelligent than the average internet commenter. Seriously... editors are people who think writing an encyclopedia is a fun hobby. That's a pretty unique group with a rather intellectual interest. That's a major reason that Article Feedback Tool failed. The average Article-feedback contribution was significantly below the average editor contribution, and half of the feedback contributions were below it's own average. I wasn't active during Article-feedback, but I know some of the feedback was referred to as borderline illiterate. It wasn't worth spending editor time reviewing it for anything of value. Skilled editor time is better spent on editing.

I'll discuss probably the best proposal, and perhaps the worst proposal. You may be surprised by my comments on worst :)

Best

Geolocation picture contributions. This is a high value contribution. This is not work that can be done, and be done better, simply by having a random experienced editor show up at the article. This is a case where it's worth it if one person takes the picture and they need someone else to add it to the article. This is a highly targeted call-to-action, which is likely to draw minimal garbage-uploads. This is also something where people can develop a real motivation and investment in the project. I can see this contributor seeking out many other important things to photograph, and perhaps exploring editing in general.

Worst

One of the proposals mentioned identifying typos/spelling-errors. The obvious point here, and the wrong point, is that it's a really lousy division of labor to have skilled-labor review those submissions to carry out trivial edits. That work is best done by an editor spotting the issue and simply doing it themselves. However there's a less obvious aspect here. Let's say there's a typo. Ninty-nine readers spot it, and do nothing. Then the next reader comes along, they see the obvious and trivial typo, and they think it's dumb to leave it there. They are motivated by that typo to try out the EDIT button. They find they're able to fix it, and they save the edit. They think "Oh wow! I just edited Wikipedia!". That's how people get hooked. That's how we get new editors. We want the reader to make the edit.

I've heard stories from the early days of Wikipedia were people would deliberately add typos and spelling errors to articles. They did it explicitly to bait readers into trying the edit button. Now we're so fast at cleaning up vandalism, and we're so good at cleaning up the trivial stuff, that we undermine our best on-ramp for new editors.

The last thing we would ever want is a dead-end interface for non-editors to summon an editor to fix a typo.

@Alsee Thank you for this thoughtful perspective. More than anything, I appreciate you prefacing it with the genuine desire to be supportive - that goes a long way. The dead-endedness of these explorations is the only thing I would push back against*, saying that the lack of progress for a reader-contributor is temporary--if this were successful we would want to look at moving people up the engagement ladder or through the funnel (choose your metaphor). The same goes for the walled-off garden.

Your point about the futility of creating a project for people we have zero expectations is very good--I think in some ways we have lapsed into thinking about making the 'easiest' experience and your comment actually convinces me we need to be more proactive and targets.

Here is why I think the answer is to be more targeted...not to abandon the concept. If we expect these users to be mindless idiots who don't care, I agree that this would be futile. However, I also I believe there is a lot of human space between the <1% of the population that are capable of being encyclopedia editors and the garbage-spewers we see on most comment boards. We need to find a way to set barriers so that the we let people in who can actively contribute--people we have serious expectations of. In other words, I don't think there are only two buckets of users: the <1% of people capable of using pull technology and becoming encyclopedia editors and the > 99% of zero-expectation-worthy users. I think within that 99% of non-enyclopedia writers is a spectrum and that maybe as low as 5% of the total population aren't encyclopedia writers, but have something to contribute and would be interested in contributing or may have even tried and been rebuffed because they didn't read 10 pages of rules. We get more than 1M people who give us donations every year, so we know that readers want to help beyond just getting their knowledge: the push model works for some people for some things. Even if it is just 500k people who might have something to offer, we will be adding value-provided we find the right tasks. I, for instance, love taking pictures and uploading them with the commons app, but I am not and never will be a big encyclopedia editor. We don't want or need the 100% of readers to contribute--we just need the 1% who love us and have something small to give. Based on your comment, I think the trick is how to weed them out besides having confusing or obtuse literature and controls--there have to be other ways, like fun tests where you prove your skills.

As to best and worst. I agree. The problem with the nearby images is that there are 1M entities in Wikipedia with geo-coordinates, and 750k of them already have images. So there are just 250k in English (presumably the largest)...I don't know if we can build a feature that has such a low opportunity. It might be that we need to identify when there is a picture that is too small, too old, etc.

*Philosophically, we could also argue about whether or not people who write useless things are less intelligent, less educated or depends, but that would be a long sidetrack.

Re "there are just 250k in English (presumably the largest)...I don't know if we can build a feature that has such a low opportunity." Adding images is an ongoing process - new articles without images keep being added and millions of new images flood in to commons. But if your ambition is only to add features where the opportunity is greater than the hundreds of thousands of Wikipedia articles without images then you might as well give up now. None of the other opportunities being discussed are close to that size, or that impact. Adding the first image to an article doesn't just double the number of people who open the thumbnail in search engines. In many cases it adds huge amounts of information to the article. Fixing typos for example isn't just a smaller opportunity, and one with a lot of competition from existing editors, but it doesn't make much impact on an article unless it is being viewed through Google translate. When you fix a typo on an article you are rarely fixing something that has persisted for more than a few months, but many of our articles without images have been so for years. There are some tasks such as adding alt text that are bigger in scale, but adding alt text only helps a small minority of readers. Referencing unreferenced information is bigger as an opportunity, but traditionally we have treated that as the advanced task for experienced editors, cracking that with an app that encourages people to fact check wikipedia would be brilliant but I'm not sure how to do it. Adding commons images to articles is by several orders of magnitude the biggest task anyone is envisaging doing by app.

@WereSpielChequers Thanks - this is useful perspective!

If you want big tasks that could be apped another would be upgrading images in use. To some extent this could be semi automated, there are lots of articles still illustrated by 50kb image files from up to a decade ago despite 5mb pictures now being available. Images can be very "sticky" once in use. In theory even a minor improvement in image quality is worthwhile, but there are sensitivities - some people have gone to a lot of effort to get photos they took into articles, and you need to be cautious about replacing such images unless you can clearly show that the replacement is "better". However some of our lowest quality images in use in articles are from some low quality mass imports such as most of the geograph import. For example most of the Geograph images are less than 100kb. Replacing one of them with another, better photo of the same object could be a big plus for the project, but you would also need to review the caption and the alt text, and of course you need a human to look at the images - sometimes the photos may be taken at the same place and even facing in the same direction, but if one image is illustrating an author then the low quality image of their grave is better to use than a high quality image of the church behind it.

Biggest and least contentious task that I know of is adding alt text. Most images don't have it, almost all images could do with some sort of additional information that isn't in the caption but which would be useful to the blind and other users of screen readers. The slight problem is that getting people to add useful alt text is a non trivial task.

I'm skeptical of the new tier of user, and hardcoding microtasks, but here's what I picture as the best chance for success.

You could have something like Toolbox or You can help Wikipedia: Tasks available, which expands when clicked. That won't have as high engagement, but it would largely avoid "not interested" people playing with a call-to-action pasted on top of the article. The good aspect here is that you can always ramp up engagement of a successful product, rather than risking a poor contribution stream on a high profile product.

Another big thing is the potential to communicate. The community has pretty well abandoned Flow, and the WMF has pretty much abandoned any work on Talk pages. But what could a minimal solution look like?

They obviously need to be able to read their talk page. There's an option for "basic" and "advanced", where advanced lets them edit as usual. In "basic" they can tap Reply to someone. The page is scanned for links to user pages, user_talk pages, and maybe user_contributions. You have just identified signatures, mentions, and possibly some harmless false-positives. You merge consecutive links to the same user as one. You overlay a Reply on each. Then they can type plaintext. Tapping save adds the message to the end of the section like this:

@[[user:ReplyTo|]] This is the message. ~~~~

The user mention and the signature are added automatically. This doesn't let them put a reply into the middle of a thread, and they probably don't know how to indent, but it gets the job done. Formatted discussions are nice, but we can deal with a person who can append plaintext.

Maybe show a preview of the section, with the new comment, before save.

If you want to get more involved, you could put a template on the page to activate our talk-archiver bot, to prevent pages from getting too long. And you could scan their "plaintext" message for any wiki markup.... in the most minimal mode you might even warn/block/nowiki any markup, so they don't accidentally mangle the page. There should probably be a way to turn off the markup protection, but people wanting to use markup are probably using advanced mode anyway.

@Alsee Thanks for this about talk pages. You're so right: think this is definitely a huge barrier we have to address at some point if we are going to pull people from very limited tasks into more meaningful contributions, because ultimately communication is at the heart of this work. There are at least two approaches that have been considered: complete overhaul (flow) and incremental changes (liquid threads). Given the recency of Flow, it feels like incremental changes, like the one you described are what we would want to approach. I don't know how succesful an attempt at structuring what are essentially unstructured talk pages in order to abstract them a little for new users, but we can try. As others have mentioned on this talk page, however, unless changes happen or are compatible with desktop, there are going to be major issues.

Thanx. This sounds promising. I'd like to clarify my thoughts a bit. I wasn't suggesting anything remotely as elaborate as Liquid threads. I was suggesting going after some very very low hanging fruit. Basically just expanding on the trivial "New Section" button. Add some newbie-mode buttons that append signed text to sections. The only fancy part is for the software to be able to grab a username to prepend a reply-ping. This concept is effectively limited to the user interface, with zero change to pages themselves. That virtually eliminates any possibility of objections. Not only is it compatible with desktop, the next step would be to add the buttons on desktop too.

Evolving Talk pages to support genuine structure may have potential, but I struggle to come up with concrete ideas. It's hard to mix structured with unstructured. There are reasons we like our unstructured wiki-world. A talk page is simply an article page at a different address. There is a certain simplicity, power, and flexibility in that. It's part of the wiki appeal.

One of the proposals mentioned identifying typos/spelling-errors. The obvious point here, and the wrong point, is that it's a really lousy division of labor to have skilled-labor review those submissions to carry out trivial edits.

This seems like a severe case of cognitive dissonance. If it is really true that this is the "worst concept", then it would be prudent to create discussions in English wikipedia perhaps even at meta and all the particular wikis to get rid of all "cleanup" type of templates:

• https://www.wikidata.org/wiki/Q6473982
• https://www.wikidata.org/wiki/Q6292692

These are created out of a desperate need to plead for others to come by and clean it up. If people should "just fix them" then those templates are unneeded, as it is easy enough to just add categories. The only other conceivable uses of such templates is to either inform readers that the article might be bad (and wrong) or to create a "pseudo-worklist" of articles to clean up.

Regardless of how desperately editors enjoy abusing templates for such reasons, both of those potential "use cases" are not what templates were designed for. In fact, such abuse is one of the reasons such templates are sometimes hidden on mobile devices (T76678).

Not only did you miss the point, you literally copy-pasted text stating it was "the wrong point".

The hardest and most important step to becoming an editor is making a first edit. People will often be worried if they can or should make an edit. When it comes to something like a spelling fix, they can be motivated that it should definitely be fixed, and confident that no one could possibly blame them for writing something they shouldn't have. They don't need to know anything except being able to find and type-over a spelling error. And once they do that, they realize "wow I edited Wikipedia", and that feeling of accomplishment encourages them to keep going.

<blockquote>When it comes to something like a spelling fix, they can be motivated that it should definitely be fixed, and confident that no one could possibly blame them for writing something they shouldn't have.</blockquote>

The first edit is indeed a hard step, a harder step is finding what to help out with. A list of typos or useful simple tasks that experienced editors may not be interested in doing may be a perfect starting point for a novice editor to gain confidence and experience before performing complex edits. It may also directly highlight things that are perfectly fine to fix without needing to read huge guidelines.

As a counter example of trivial cleanup, editing an infobox should be trivial except for the fact that a good portion of the infobox data isn't even on the page itself. A typo on an infobox may be coming from a deeply nested template, wikidata or lua module, or some other protected page. An editor would have to go through the rabbit hole to find said page, and finally when they do, they'll either give up because they can't understand it, or they may add something to the talk page " summoning editors" to fix it.

If experienced editors find such spelling issues a waste of time then it can simply be surfaced to readers and require deliberate action from editors to actually see them.

I find it strange that you believe that some meaningful percentage of editors consider it a "waste of time" to fix a spelling error. If they are editing the page and see the spelling error they would almost certainly include that fix. And even if they weren't planning to edit the page, almost any editor would take ten seconds to make that trivial edit on sight. (Note: Virtually everyone uses the wikitext editor for good reasons. One of those reasons is that VE load time ranges from poor to browser-time-out errors.)

If we did implement this, the outcome is obvious from a community perspective. What would happen is that a hat collector or other editor would grab this trivial list and do a speed-run to rack up their edit count.

The list cannot be "simply be surfaced to readers", you need someone to do that work. It makes no sense for an experienced editor to spend ~10 seconds tagging a spelling error when they can fix it in ~10 seconds, and we don't want new users dead-ending here. We want the new user to click the edit button and discover that they can (and did!) make the edit themselves.

This really is the most counter-productive idea here. We don't want to divert "non-editors" away from actually making the easiest possible first edit themselves, and you would just end up with editors doing speed runs blanking the entire list for potentially disreputable reasons. It would diminish our on-ramp of editors.

I do a lot of typo fixing, and I have various tools and searches to find typos. I haven't yet given up hope of designing a newbie friendly typo finding and fixing app, but there are some barriers.

Much closer to market for a new entry path for newbies are ideas like adding images to articles.

Whilst I'd agree that most maintenance templates should be replaced by hidden categories, and ones like dead end and orphan should be auto generated, good luck getting consensus for such a change. There is a strong lobby of template bombers who consider their activity to be worthwhile, convincing them that what they are doing is not a net positive will not be easy, and yes it has been tried.