Page MenuHomePhabricator

Surface the impact of the initial successful edits
Open, Needs TriagePublic

Description

Editors making their initial successful edit can be notified to surface the positive impact their edit had and improve their understanding of the collaborative nature of the project (which was identified as an opportunity for improvement in New-Editor-Experiences research). A mockup illustrates the idea below:

Content and timing
The notification can communicate that (a) their edit has been part of an article that got a certain number of views, and that (b) other editors have improved the article since.

The notification can be sent after a one week period which seems enough to consider that the edit survived the review process, while still being recent enough to be relevant.

We probably need to establish certain thresholds to decide the number of first successful edits to notify (only the 1st edit?), the content that is valid (only main namespace?), and whether to skip cases where the edit resulted in too few views and further contributions to actually be motivating.

Impact

The notification is expected to encourage the editor to keep editing on the same topic in the short term, but also to contribute to more long-term motivation by illustrating how wikipedia works with the edit they just did. Currently communication to new editors tend to happen when things fail, communicating when users succeed can be a good motivator.

It would be great to measure the impact at both short and long terms, by analysing changes in productivity and retention for those receiving these notifications.

Event Timeline

This idea came out of the exploration process for New-Editor-Experiences. It is not clear whether it would be part of the main focus of work for any team yet. But given the relative small scope of the task, I thought it would be worth capturing in a ticket to make it available to a larger audience that may be interested.

MGChecker added a comment.EditedNov 16 2017, 7:08 PM

How would you extract the pageview information? It isn't stored by MediaWiki itself and it really doesn't seem like a good idea to depend on external services for actual extension functionality.

How would you extract the pageview information? It isn't stored by MediaWiki itself and it really doesn't seem like a good idea to depend on external services for actual extension functionality.

I'm not familiar with the technical details, but I think the Mediawiki Pageviews API can provide such information for each project.

What if the edit made by the newcomer is not kept at all in the improved version? Articles evolve but it may be confusing for the newcomer not to find the edit.

What if the edit made by the newcomer is not kept at all in the improved version? Articles evolve but it may be confusing for the newcomer not to find the edit.

There are several options:

  • We can assume that communicating that others edited the article ("new contributions from 7 others" ) makes it clear that an article is a living document.
  • We can consider a shorter period of time for that case to be an edge case most of the time, and reduce it's incidence.
  • We can check whether the content is still alive, and only notify users where their contribution still has some impact in the page.

I'd recommend to start with the first approach for simplicity. One of the main goals here is to expose users to how our projects work, and I think that the notification exposes enough context for them to understand the ways in which the article could have changed when other people participated after them. They are probably in a better position than if they find out on their own. Obviously, if we find out that most of the time the notifications becomes useless or even demotivating because of this, we can consider more elaborate approaches.

Thanks.
One day, I'll manage to get an "I don't know" from you. :)

Man77 removed a subscriber: Man77.Dec 2 2017, 10:03 AM

not Tracking-Neverending by definition, hence removing that tag

If you are going to tell the new editor "Your contribution has been live for a week", then you need to first check that the contribution is still live.

Also, I think that most people really aren't going to be excited about know that a trivial spelling correction is live. Maybe there should be a minimum size to receive this? And maybe (at wikis where this is possible) an ORES scan or a FlaggedRevs check, to make sure that the "still live" edit isn't undiscovered vandalism?

If you are going to tell the new editor "Your contribution has been live for a week", then you need to first check that the contribution is still live.

Yes. We want to avoid sending confusing messages. I think that some simple checks make sense even if we don't aim for a 100% accuracy.

One of our main goals is to expose the collaborative nature of the community. So it is not a big problem for users to realise that other editors made the content evolve on top of your contribution.

Also, I think that most people really aren't going to be excited about know that a trivial spelling correction is live. Maybe there should be a minimum size to receive this?

This is intended for the initial contributions of an editor. At that point, even a small contribution to Wikipedia may be rewarding. We may still consider some thresholds to decide who to send the notification, but I don't think those should be very high. Communicating a small success may be more beneficial (to make the community visible) than not doing so.

And maybe (at wikis where this is possible) an ORES scan or a FlaggedRevs check, to make sure that the "still live" edit isn't undiscovered vandalism?

Makes sense. I was expecting the regular review process to already catch most of the vandalism after a week, but ORES can help to be on the safer. I'm also curious to know which would be the impact of a vandal receiving such notification.


Thanks for the comments, @Whatamidoing-WMF. These are all good considerations. I think that experimentation would help to identify how much effort to spend in each front. I think it would be good to launch an initiative like this on a controlled environment (e.g., to a small set of new uses) and evaluate the impact it has to identify limitations and polish them iteratively.

Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 2 2018, 10:57 PM

Triaging as future: this is one of the options we are considering with Growth, but we need to finish the community consultations first and then decide if that ticket is one of the possible solutions we may implement.