Page MenuHomePhabricator

Newcomer tasks: Use edit tag for edits that originate from Suggested Edits module
Closed, ResolvedPublic


Using an as-yet-to-be-determined mechanism (probably a query string parameter that persists across editor loading / state switching / MobileFrontend overlays etc) we want to add an edit tag tag to edits that originate from the user interacting with the Suggested Edits module on Special:Homepage.

In addition to facilitating analysis, this will also allow experienced users on our target wikis to filter Recent Changes to patrol the newcomer tasks edits.

The wording of the tag can be "Newcomer Tasks".

Event Timeline

@MMiller_WMF can you please provide wording for this tag (see for other examples)?

MMiller_WMF updated the task description. (Show Details)

@kostajh -- I added the wording for the tag to the description.

Note: we decided in standup today that this task is not strictly necessary for V1.0, because we will be able to tell from EventLogging whether users edited an article they selected. This edit tag will make it easier to analyze, and make it possible for community members to explicitly patrol these edits, but it's not strictly necessary. @kostajh -- if this gets to be a challenge, you can move it back to Ready for Development.

Alright, moving back for now then. This is a relatively straightforward task (to define the edit tag) but to actually make use of we'll need other bits of code in place first.

Change 549916 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Tag edits originating via newcomer tasks

Gergő has a work in progress patch, assigning to him. (@Tgr please unassign / move to Ready for Development if you'd like someone else to finish it)

Could we make use of cache to check on the server-side when we think a user has made an edit via newcomer tasks? Something like:

  1. User clicks on task
  2. JS click handler posts to an API endpoint which sets the page ID in the cache with a TTL of 60 (?) minutes, keyed on the user ID
  3. The recent change save hook handler checks for clickId in the URL, or, if not found, checks to see if that page ID exists in the cache

That would certainly make life easier, compared to passing through the click ID to all the VE, MF etc APIs. There is some chance of false positives (user clicks on the link, then leaves without editing, then late somehow ends up editing that page anyway) and negatives (editing takes more than 60m, or user leaves the tab open for a while before editing) but those seem remote enough. On the flip side it would fix some false negatives where the id gets lost (like editing-viewing-editing in the wikitext editor), and it's of course wastly simpler as the number of moving parts in extensions maintained by other teams is reduced. @Catrope @MMiller_WMF what do you think?

If we do that, I suppose we should rewrite the existing logging code to use it as well?

JS click handler posts to an API endpoint which sets the page ID in the cache with a TTL of 60 (?) minutes, keyed on the user ID

Not really needed, we can just do it on the request that results from the user clicking on the link.

If we do that, I suppose we should rewrite the existing logging code to use it as well?

I think it would make sense to leave the existing implementation, since that allows @nettrom_WMF to join with the EditAttemptStep schema.

Not really needed, we can just do it on the request that results from the user clicking on the link.

I think you're right about that. But OTOH we have already wired up code to target all of the possible edit links on the client side. So it might be easier and less maintenance burden to add a handler to that existing code, rather than add new code to try to intercept all of the requests generated by clicking the edit link. Also, I'm not sure we'd have somewhere on the server side to intercept clicking the edit link for MobileFrontend, as that only results in an API query to get the latest revision and some ResourceLoader calls.

@Tgr and I just talked about his comments on this task and also the ones at T230068#5691717. While I still have a limited technical understanding of this situation, I can say these things:

  • I'm not very worried about picking up false positives -- in fact, I don't think they could almost ever occur. If a user is suggested an article to edit and they click on that article, I think that even if they edit it weeks later, that probably has something to do with it coming from the homepage.
  • I am in favor of doing the easier option if we don't lose very much by doing.

I think @nettrom_WMF should also weigh in.

What is the status of this task?

I'll work on it this week while @Tgr is OoO.

Change 554370 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Add newcomer task tag when user makes edit

Change 549916 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add tag for edits originating via newcomer tasks

Change 554370 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add newcomer task tag when user makes edit

for @MMiller_WMF review - I assume that the following is expected:
Once a user clicks on an article from Homepage Suggested edits and edits the article, all subsequent edits from that user on that article will be marked with the Newcomer task tag, i.e.

  • the initial edit on a suggested article was made after clicking on the article from Suggested edits module
  • then, a user goes to the article by searching it or clicking on an article link e.g. from Recent changes - all edits will be marked with Newcomer task tag.

Thanks. I think this is working well in both beta and production.

For our information (especially @nettrom_WMF and @RHo): this tag will be placed on all edits a newcomer makes for a week following when they click on the task from their homepage. So if they click a task, make an edit, then watch the page, and come back to edit 6 days later, they will still get the tag on their edit. But if it's 8 days later, they will not.

On the one hand, this is good because it allows for if the newcomer takes a long time to make their suggested edit, or needs to come back to it the next day. And if the newcomer makes many edits to the suggested article, those will all show up under the tag, and that makes sense because they are all edits that would not have happened without our feature.

On the other hand, because this one week time period does count multiple edits, its data needs to be further processed to count the number of distinct users who did suggested edits or the number of distinct articles that got suggested edited.

@Catrope says if we don't like the one week time period, we can change it. @nettrom_WMF what do you think?