A new task type suggested after a person completes 5 tasks of a certain type.

Should this number be community-configurable?

These dialogs should not be shown to those with more than $(2) reverts in the last $(7) days.

Revert for any type of edit? Or is this looking only at edits of the newcomer task type they were working on?

The second and subsequent times the dialog is shown, an additional checkbox to “Don’t show this again” is shown. If the person selects this checkbox, they will opt out of further level up post-edit dialogs.

[minor] It would be a bit easier to show this from the first time, not the second time they've seen the dialog. (A little less state management to handle, fewer rows in the database for tracking.) Could we start with always showing that checkbox, and analyze the usage data to see if users are opting out at a high rate the first time they see it?

If 5 tasks are completed, then the next unselected task type is suggested

I wonder if we should define a field in MediaWiki:NewcomerTasks.json, something like GENewcomerTaskProgression that would define the pathways to different task types. That might be better than relying on hardcoding the progression order.

A new post-edit dialog message type is added to encourage newcomers to try a new task type.

What should we do if there are no tasks available for that task type?

Related: should we take into account the user's topic filters when getting the queue of tasks for the next level? In some cases, a user with "Art" and "Philosophy" for their topic filters wouldn't get any results for "References" task type, but if they dropped those topics, they would see tasks available.

Try new task

What happens when the user presses "Try new task"? Do we take them directly to the article with guidance and/or structured task helper loaded? Should we provide some preview of what the task is in the dialog, so it is not a complete surprise to the user as to where they land? Given that we have some sensitive content that ends up in the suggested tasks feed, it would be nice for the user to see what they are going to click on. If we implement a preview, we'd probably also want to have the forward/backward arrows like we have in the post-edit dialog for cycling through suggested tasks.

In T322386#8569295, @kostajh wrote:

A new task type suggested after a person completes 5 tasks of a certain type.

Should this number be community-configurable?

@KStoller-WMF to make the call.

These dialogs should not be shown to those with more than $(2) reverts in the last $(7) days.

Revert for any type of edit? Or is this looking only at edits of the newcomer task type they were working on?

Any type of edit.

The second and subsequent times the dialog is shown, an additional checkbox to “Don’t show this again” is shown. If the person selects this checkbox, they will opt out of further level up post-edit dialogs.

[minor] It would be a bit easier to show this from the first time, not the second time they've seen the dialog. (A little less state management to handle, fewer rows in the database for tracking.) Could we start with always showing that checkbox, and analyze the usage data to see if users are opting out at a high rate the first time they see it?

@KStoller-WMF to confirm, but that sounds reasonable to me.

If 5 tasks are completed, then the next unselected task type is suggested

I wonder if we should define a field in MediaWiki:NewcomerTasks.json, something like GENewcomerTaskProgression that would define the pathways to different task types. That might be better than relying on hardcoding the progression order.

Sounds reasonable to me. But are there any downsides to adding such a field?

A new post-edit dialog message type is added to encourage newcomers to try a new task type.

What should we do if there are no tasks available for that task type?
Related: should we take into account the user's topic filters when getting the queue of tasks for the next level? In some cases, a user with "Art" and "Philosophy" for their topic filters wouldn't get any results for "References" task type, but if they dropped those topics, they would see tasks available.

We decided the simple thing would be to show the standard no suggestions found post-edit dialog, but with updated copy - see T324177.

Try new task

What happens when the user presses "Try new task"? Do we take them directly to the article with guidance and/or structured task helper loaded? Should we provide some preview of what the task is in the dialog, so it is not a complete surprise to the user as to where they land? Given that we have some sensitive content that ends up in the suggested tasks feed, it would be nice for the user to see what they are going to click on. If we implement a preview, we'd probably also want to have the forward/backward arrows like we have in the post-edit dialog for cycling through suggested tasks.

In this case, as it is someone who is finished doing a newcomer task, when they select this, the 'normal' post-edit dialog with the preview task queue is shown. This way, they are not taken to a new context but stay on the article with a new suggested task type loaded in situ.

Should this number be community-configurable?

My current thinking is that we should run this experiment before investing the time to make Leveling up features community configurable. After the experiment, we can follow up with that work assuming this work shows promise. Follow up task created: T328386: Leveling Up: community configuration

It would be a bit easier to show this from the first time, not the second time they've seen the dialog. (A little less state management to handle, fewer rows in the database for tracking.) Could we start with always showing that checkbox, and analyze the usage data to see if users are opting out at a high rate the first time they see it?

Sounds good, thanks for thinking about how to keep this smaller and more iterative! I'll update the task description.

After another 5 completed suggested edits they will see message again.

To clarify, are we looking at sequential edits with a particular task type, or cumulative?

For example:

• if I do 5 "add link" edits in a row, I would see the "try a new task" dialog.
• If I do 2 "add link" edits, then 1 "add image", then 2 "add link" edits (5 edits total, but not sequential for a particular task type nor cumulative for a single task type), I should not see "try a new task" dialog.
• if I do 2 "add link" edits", then 1 "add image", then 3 "add link" edits (5 add link edits cumulative) I should see the "try a new task" dialog
• if I do 4 add link edits, 4 add image edits, 4 copy edit edits, then the next time I do add link, add image, and copy edit edits, I would see "try a new task" dialog each time (?)

In T322386#8569447, @RHo wrote:

If 5 tasks are completed, then the next unselected task type is suggested

I wonder if we should define a field in MediaWiki:NewcomerTasks.json, something like GENewcomerTaskProgression that would define the pathways to different task types. That might be better than relying on hardcoding the progression order.

Sounds reasonable to me. But are there any downsides to adding such a field?

It adds some more complexity, so maybe it's not worth it. Just wanted to note that currently, the ordering of task types in MediaWiki:NewcomerTasks.json controls how the task types appear in the task types dialog. So, someone could move "add link" to appear before "copyedit" in the easy group, for example. (Or change its difficulty setting entirely.) But saving the Special:EditGrowthConfig form resets to our deafult ordering of "copyedit" then "add link".

All of that is to say, defining a mechanism for controlling the ordering and placement (group) of each task type might be better than the current setup we have. But it is not strictly necessary for this task.

To clarify what the algorithm for "next unselected task type" should be:

• "add link" appears second in my task type list, and copy edit is unchecked and appears first. If I do 5 add link tasks, should my next unselected task type be "copyedit" or should it be "add image", which is the first item in the next difficulty group (medium)?

Considering that users will interact with their task filters to check/uncheck different difficulty types, should we choose "next task type" based on analyzing their edit history for each task type and the number of edits they have for each task type?

For example, let's say you started with "add link" edits, did 5 of them, and were prompted to do copy edits. You do a copy edit. Then you update your task type filters to only show copy edits, and not "add link". Then you do 4 more copy edits. "Next unselected task type" would now be "add link", which is not what we want, AIUI.

(The above two comments/questions are for @KStoller-WMF and @RHo, sorry for not tagging initially.)

One more question: when we prompt the user to switch to the new task type, should we also update their saved task filters to include that task type? e.g. if I was doing copyedit, and got prompted to do "add link", should my saved task type filters on Special:Homepage now include "add link"? (And should "copyedit" be removed from my saved filters? That might be a bit too aggressive in pushing the user the to try new task types, though.)

I'll provide my thoughts, but @RHo is welcome to override me:

To clarify, are we looking at sequential edits with a particular task type, or cumulative?

Cumulative for a particular task type.

"add link" appears second in my task type list, and copy edit is unchecked and appears first. If I do 5 add link tasks, should my next unselected task type be "copyedit" or should it be "add image", which is the first item in the next difficulty group (medium)?

I think it's most important for newcomers to try and learn new skills, so in my opinion we should just prompt the next unselected task type. AKA If I do 5 add link tasks, then I'm next prompted to do "copyedit".

Considering that users will interact with their task filters to check/uncheck different difficulty types, should we choose "next task type" based on analyzing their edit history for each task type and the number of edits they have for each task type?

Hmmmm, I would suggest we keep this as simple as possible. I think it's OK if we suggest a task type that the user has already unchecked as long as we don't continue to suggest that same task type again and again. Would it be fairly straightforward to only suggest a specific task to a user once? @RHo do you agree we should consider something like that?

when we prompt the user to switch to the new task type, should we also update their saved task filters to include that task type?

Yes, if they select "Try new task" then I think we should update their saved task filters to include that new task.

Thank you, @kostajh, for asking these questions and considering all of this... it gets complex fast! Thinking through this, I realized there are likely a few other edge cases we need to consider:

• We should never suggest a task that is disabled or not available at a given wiki.
• How should we handle when a user is "leveling up" to a task that is available at a given wiki, but they don't have a task that meets their topic filters? @RHo - thoughts?

In T322386#8586023, @KStoller-WMF wrote:

I'll provide my thoughts, but @RHo is welcome to override me:

To clarify, are we looking at sequential edits with a particular task type, or cumulative?

Cumulative for a particular task type.

"add link" appears second in my task type list, and copy edit is unchecked and appears first. If I do 5 add link tasks, should my next unselected task type be "copyedit" or should it be "add image", which is the first item in the next difficulty group (medium)?

I think it's most important for newcomers to try and learn new skills, so in my opinion we should just prompt the next unselected task type. AKA If I do 5 add link tasks, then I'm next prompted to do "copyedit".

Considering that users will interact with their task filters to check/uncheck different difficulty types, should we choose "next task type" based on analyzing their edit history for each task type and the number of edits they have for each task type?

Hmmmm, I would suggest we keep this as simple as possible. I think it's OK if we suggest a task type that the user has already unchecked as long as we don't continue to suggest that same task type again and again. Would it be fairly straightforward to only suggest a specific task to a user once? @RHo do you agree we should consider something like that?

Hiya, not suggesting the next unchecked task more than once sounds good to me, assuming it doesn't add too much complexity to keep track of this? So in @kostajh's earlier comment where someone started doing 1 Add link task, then deselected it and then did 5 copyedits, we would then suggested Add link to them. If they dismiss or deselect this task before doing say 5 add image tasks, we would not suggest Add links again. How does that sound?

when we prompt the user to switch to the new task type, should we also update their saved task filters to include that task type?

Yes, if they select "Try new task" then I think we should update their saved task filters to include that new task.

Agree.

Thank you, @kostajh, for asking these questions and considering all of this... it gets complex fast! Thinking through this, I realized there are likely a few other edge cases we need to consider:

• We should never suggest a task that is disabled or not available at a given wiki.
• How should we handle when a user is "leveling up" to a task that is available at a given wiki, but they don't have a task that meets their topic filters? @RHo - thoughts?

I think we had said to simply show them this improved no suggestions found filter per T325390. However, maybe it makes sense to add a task to track how often this situation happens so that we can reconsider if it is happening a lot? One potential consideration is to open up to all topics if no suggestions are found.

However, maybe it makes sense to add a task to track how often this situation happens so that we can reconsider if it is happening a lot?

Agreed.

We just completed T316749: Image suggestions: add instrumentation for "No suggestion found", but I think that only covers tracking the "No suggestions found" error for "add an image" and "add a link":
https://grafana.wikimedia.org/d/vGq7hbnMz/special-homepage-and-suggested-edits?forceLogin&orgId=1&viewPanel=164

It sounds like we should add a task to cover instrumentation for "No suggestions found" for ALL task types. Does that sound correct, @kostajh?

In T322386#8587948, @KStoller-WMF wrote:

However, maybe it makes sense to add a task to track how often this situation happens so that we can reconsider if it is happening a lot?

Agreed.

We just completed T316749: Image suggestions: add instrumentation for "No suggestion found", but I think that only covers tracking the "No suggestions found" error for "add an image" and "add a link":
https://grafana.wikimedia.org/d/vGq7hbnMz/special-homepage-and-suggested-edits?forceLogin&orgId=1&viewPanel=164

It sounds like we should add a task to cover instrumentation for "No suggestions found" for ALL task types. Does that sound correct, @kostajh?

Ah, sorry, T316749: Image suggestions: add instrumentation for "No suggestion found" is a bit vague. That one is about keeping track of this scenario:

• user clicks on "Add Link" task or "Add Image" task in suggested edits module
• user arrives at article page, but the metadata we need to support the add link/image workflow is no longer available

In T322386#8587319, @RHo wrote:

"add link" appears second in my task type list, and copy edit is unchecked and appears first. If I do 5 add link tasks, should my next unselected task type be "copyedit" or should it be "add image", which is the first item in the next difficulty group (medium)?

I think it's most important for newcomers to try and learn new skills, so in my opinion we should just prompt the next unselected task type. AKA If I do 5 add link tasks, then I'm next prompted to do "copyedit".

Considering that users will interact with their task filters to check/uncheck different difficulty types, should we choose "next task type" based on analyzing their edit history for each task type and the number of edits they have for each task type?

Hmmmm, I would suggest we keep this as simple as possible. I think it's OK if we suggest a task type that the user has already unchecked as long as we don't continue to suggest that same task type again and again. Would it be fairly straightforward to only suggest a specific task to a user once? @RHo do you agree we should consider something like that?

Hiya, not suggesting the next unchecked task more than once sounds good to me, assuming it doesn't add too much complexity to keep track of this? So in @kostajh's earlier comment where someone started doing 1 Add link task, then deselected it and then did 5 copyedits, we would then suggested Add link to them. If they dismiss or deselect this task before doing say 5 add image tasks, we would not suggest Add links again. How does that sound?

I'd like to propose that we separate keep the state of user's task filters separate from the business logic about which task type to show, to make things a bit simpler. I am thinking something like:

• have a way to easily get a list of task types and the number of unreverted edits user has completed for that task type
• when the user has just finished the 5th edit for a certain task type, we'd consult the list of task types that are under 5, and that are in the same group (easy/medium/hard) or next level up
• we'll need to keep track of which task types the user has seen this "try new task" dialog for, so we don't show it more than once

Does that sound ok?

• the

In T322386#8599390, @kostajh wrote:

I'd like to propose that we separate keep the state of user's task filters separate from the business logic about which task type to show, to make things a bit simpler. I am thinking something like:

• have a way to easily get a list of task types and the number of unreverted edits user has completed for that task type
• when the user has just finished the 5th edit for a certain task type, we'd consult the list of task types that are under 5, and that are in the same group (easy/medium/hard) or next level up
• we'll need to keep track of which task types the user has seen this "try new task" dialog for, so we don't show it more than once

Does that sound ok?

That sounds OK to me. Anything to attempt to make this simpler for the initial iteration is preferable in my opinion.

Change 887881 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Add try new task dialog

https://gerrit.wikimedia.org/r/887881

Technical implementation notes:

• in HomepageHooks BeforePageDisplayHook, export a variable to the client side to indicate if the completion of the suggested edit will result in the user reaching the quota for the task type, and also export the ID of that task type. Something like wgGELevelingUpNextTaskType = "copyedit". If it's null, it means that there is no next task type to suggest.
  • this will result in weird behavior if the user opens multiple tabs for different task types, but we are not going to worry about that scenario.
• A "LevelingUpManager" class and service for doing the database query to export the user's quota and suggested next task type to the client-side in homepagehooks
• In modules/ext.growthExperiments.PostEdit/index.js, check if wgLevelingUpNextTaskType is set. If so, show the "TryNewTask" panel inside a collapsible drawer.
  • if user clicks "Try new task" then close the "try new task panel" and show the post edit dialog
  • when opening the post-edit dialog, add a parameter with the new task type to add, and this gets added to ApiQueryGrowthTasks call, also update the user's task type filters.

Change 888235 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Leveling up manager

https://gerrit.wikimedia.org/r/888235

Change 889810 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] TaskTypeHandler: Allow finding task type ID from change tag name

https://gerrit.wikimedia.org/r/889810

One thing I noticed when I was just checking the mocks is that the proposal is to show the dialogue on every k edits (with k=5) as the default. So if I've made 10 add a link edits, I should see the dialogue again (provided I haven't checked "don't show me this again"). Are we still planning on doing that or have these changed to milestones that trigger the dialogue and then never again?

Thanks for thinking about this @nettrom_WMF! I agree that your Newcomer Task analysis makes it worth revisiting the "levels" we set here.

I'm torn on this one. Since new editors often complete many "add a link" edits, I can see the argument that we should be setting the threshold higher for this task. However, I can also see the argument that "add a link" edits are most valuable for giving new accounts an easy way to make a first edit, and that we really should try to encourage new editors to move on to more significant tasks.

When in doubt, I try to give favor to the simplest solution. Which I believe is to leave the task completion level at 5 for all tasks for now. I don't think it's a major problem if a new editor is on an "add a link" roll and sees this prompt a few times, they can always select "don't show me again." I'm not sure if adding in additional complexity is worth it, especially once we consider how we might support this through Community Configuration.

That's my current thinking, but as always I'm open to a different approach if others feel strongly about this!

Change 889943 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] UserImpact: Calculate and store edit count by task type

https://gerrit.wikimedia.org/r/889943

Change 889993 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] API: Add "growthnextsuggestedtasktype" query module

https://gerrit.wikimedia.org/r/889993

Change 890406 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] LevelingUpManager: Add support for opting out of prompt

https://gerrit.wikimedia.org/r/890406

Change 889810 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] TaskTypeHandler: Allow finding task type ID from change tag name

https://gerrit.wikimedia.org/r/889810

Change 889943 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] UserImpact: Calculate and store edit count by task type

https://gerrit.wikimedia.org/r/889943

Change 890406 abandoned by Kosta Harlan:

[mediawiki/extensions/GrowthExperiments@master] LevelingUpManager: Add support for opting out of prompt

Reason:

squashed

https://gerrit.wikimedia.org/r/890406

Change 888235 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Services: Introduce LevelingUpManager

https://gerrit.wikimedia.org/r/888235

Change 889993 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] API: Add "growthnextsuggestedtasktype" query module

https://gerrit.wikimedia.org/r/889993

@RHo @KStoller-WMF in the copy document and the mockup, we just have wording for a prompt to try the references task:

{DRAFT} Thanks for your contribution. Are you ready for a new challenge? Try finding references.

Instead of adding 6 new strings (copyedit, link recommendation, image recommendation, expand, update, references) I was wondering if we could possibly make use of the existing copy we have, which you can see in the preview section of the Suggested Edits module:

Otherwise, could you please provide copy to use for each of the task types, in the form of "Try {verb} {task type}" per the existing references example?

Change 891537 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] SuggestedEditSession: Fetch next suggested task type when initiating

https://gerrit.wikimedia.org/r/891537

@kostajh I'm certainly in support of reusing existing strings & translations if possible!

Am I correct in understanding that the text would then read:

Thanks for your contribution. Are you ready for a new challenge? Find references.

With Find references being replaced with any of the following strings depending on the next task type suggested to the user:

• Copyedit
• Add links between articles
• Add a suggested image
• Update articles
• Expand short articles

That seems OK to me.

Would we also consider adding the info popup on desktop, or is that overboard? Recent community feedback from newcomers was that they liked the leveling up post-edit dialog, but were curious to know more about the task type and level of difficulty of the new task type. That being said, a pop-up over a module might be a UX pattern we want to avoid? @RHo - thoughts?

In T322386#8642134, @KStoller-WMF wrote:

@kostajh I'm certainly in support of reusing existing strings & translations if possible!

Am I correct in understanding that the text would then read:

Thanks for your contribution. Are you ready for a new challenge? Find references.

With Find references being replaced with any of the following strings depending on the next task type suggested to the user:

• Copyedit
• Add links between articles
• Add a suggested image
• Update articles
• Expand short articles

That seems OK to me.

Would we also consider adding the info popup on desktop, or is that overboard? Recent community feedback from newcomers was that they liked the leveling up post-edit dialog, but were curious to know more about the task type and level of difficulty of the new task type. That being said, a pop-up over a module might be a UX pattern we want to avoid? @RHo - thoughts?

Hmm, seeing those typed out, I am unsure about using them, but I leave it for you, @RHo and @JFernandez-WMF to decide. Adding six new translation strings isn't a problem, in the bigger scheme of things. I would just eventually need some copy to place in the dialog, because at the moment we only have it for references.

In T322386#8642385, @kostajh wrote:

In T322386#8642134, @KStoller-WMF wrote:

@kostajh I'm certainly in support of reusing existing strings & translations if possible!

Am I correct in understanding that the text would then read:

Thanks for your contribution. Are you ready for a new challenge? Find references.

With Find references being replaced with any of the following strings depending on the next task type suggested to the user:

• Copyedit
• Add links between articles
• Add a suggested image
• Update articles
• Expand short articles

That seems OK to me.

Would we also consider adding the info popup on desktop, or is that overboard? Recent community feedback from newcomers was that they liked the leveling up post-edit dialog, but were curious to know more about the task type and level of difficulty of the new task type. That being said, a pop-up over a module might be a UX pattern we want to avoid? @RHo - thoughts?

I definitely would avoid having a pop-up or tooltip over a pop-up. I understand the community feedback, but in this Levelling up scenario the newcomer has done a bunch of one task type already so does know something about the concept of different editing types, and I feel like the names of the tasks are fairly self-explanatory. Would stick to minimum copy/help text in this first version.

Hmm, seeing those typed out, I am unsure about using them, but I leave it for you, @RHo and @JFernandez-WMF to decide. Adding six new translation strings isn't a problem, in the bigger scheme of things. I would just eventually need some copy to place in the dialog, because at the moment we only have it for references.

Instead of six new strings, can we using whatever the task type name is as a variable? Something like Thanks for your contribution. Try a new edit type: $TaskName

Change 891661 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] ApiQueryNextSuggestedTaskType: Return edit count by task type

https://gerrit.wikimedia.org/r/891661

In T322386#8642433, @RHo wrote:

Instead of six new strings, can we using whatever the task type name is as a variable? Something like Thanks for your contribution. Try a new edit type: $TaskName

Sounds good to me!

In T322386#8642459, @kostajh wrote:

In T322386#8642433, @RHo wrote:

Instead of six new strings, can we using whatever the task type name is as a variable? Something like Thanks for your contribution. Try a new edit type: $TaskName

Sounds good to me!

I propose to bold the task name, so it stands out a bit more. What do you think?

In T322386#8644096, @kostajh wrote:

In T322386#8642459, @kostajh wrote:

In T322386#8642433, @RHo wrote:

Instead of six new strings, can we using whatever the task type name is as a variable? Something like Thanks for your contribution. Try a new edit type: $TaskName

Sounds good to me!

I propose to bold the task name, so it stands out a bit more. What do you think?

Sure, bolding works for me! Wanted to confirm though hat the line-height for that string will be 1.5? It looks a little tight from the screenshot...

In T322386#8644104, @RHo wrote:

Sure, bolding works for me! Wanted to confirm though hat the line-height for that string will be 1.5? It looks a little tight from the screenshot...

Oops, yes, just added it.

Change 891537 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] SuggestedEditSession: Fetch next suggested task type when initializing

https://gerrit.wikimedia.org/r/891537

Change 891661 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] ApiQueryNextSuggestedTaskType: Return edit count by task type

https://gerrit.wikimedia.org/r/891661

Change 887881 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Leveling up: Add try new task dialog

https://gerrit.wikimedia.org/r/887881

These dialogs should not be shown to those with more than $(2) reverts in the last $(7) days.

@KStoller-WMF sorry, I forgot to implement this. Is it important for this release, or can we look at data and decide later if we want to put time into implementing this?

Change 893754 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] trynewtask: Finalize i18n

https://gerrit.wikimedia.org/r/893754

In T322386#8660464, @kostajh wrote:

These dialogs should not be shown to those with more than $(2) reverts in the last $(7) days.

@KStoller-WMF sorry, I forgot to implement this. Is it important for this release, or can we look at data and decide later if we want to put time into implementing this?

I'm OK with releasing the MVP of Leveling up without that for now. Instead it's something we can consider after we look at data and start working on community configuration T328386: Leveling Up: community configuration.

Change 893754 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] trynewtask: Finalize i18n

https://gerrit.wikimedia.org/r/893754

@kostajh - is "Try a new task" dialog enabled in betalabs? I tried with new accounts on enwiki betalabs and cswiki betalabs - and no amount of edits triggered the new post-edit dialog.

In T322386#8664569, @Etonkovidova wrote:

@kostajh - is "Try a new task" dialog enabled in betalabs? I tried with new accounts on enwiki betalabs and cswiki betalabs - and no amount of edits triggered the new post-edit dialog.

I think it's because the new impact module isn't the default on beta labs. I made a patch to set it as the default T328757#8667874.

In T322386#8667877, @kostajh wrote:

In T322386#8664569, @Etonkovidova wrote:

@kostajh - is "Try a new task" dialog enabled in betalabs? I tried with new accounts on enwiki betalabs and cswiki betalabs - and no amount of edits triggered the new post-edit dialog.

I think it's because the new impact module isn't the default on beta labs. I made a patch to set it as the default T328757#8667874.

Thanks, @kostajh - it works now.

Checked in betalabs:

betalabs -

mockup -

In T322386#8671109, @Etonkovidova wrote:

In T322386#8667877, @kostajh wrote:

In T322386#8664569, @Etonkovidova wrote:

@kostajh - is "Try a new task" dialog enabled in betalabs? I tried with new accounts on enwiki betalabs and cswiki betalabs - and no amount of edits triggered the new post-edit dialog.

I think it's because the new impact module isn't the default on beta labs. I made a patch to set it as the default T328757#8667874.

Thanks, @kostajh - it works now.

Checked in betalabs:

betalabs -	mockup -

Hmm, that is confusing because I had not yet merged the patch. So I don't know why it was not working, and is working now. In any case, I am glad that you are able to QA there. Is it with the same user that didn't see the dialog when you tried a few days ago?

In T322386#8671767, @kostajh wrote:

In T322386#8671109, @Etonkovidova wrote:

In T322386#8667877, @kostajh wrote:

In T322386#8664569, @Etonkovidova wrote:

@kostajh - is "Try a new task" dialog enabled in betalabs? I tried with new accounts on enwiki betalabs and cswiki betalabs - and no amount of edits triggered the new post-edit dialog.

I think it's because the new impact module isn't the default on beta labs. I made a patch to set it as the default T328757#8667874.

Thanks, @kostajh - it works now.

Checked in betalabs:

betalabs -	mockup -

Hmm, that is confusing because I had not yet merged the patch. So I don't know why it was not working, and is working now. In any case, I am glad that you are able to QA there. Is it with the same user that didn't see the dialog when you tried a few days ago?

Most likely it was a different user. I did not realize that the presence of the leveling up post-edit dialog might depend on a user, so I signed up with random test users.

Change 900686 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Leveling up: prevent try new task dialog from showing on reload

https://gerrit.wikimedia.org/r/900686

@KStoller-WMF please confirm that the following is an expected scenario (checked in testwiki wmf.2)

1. A user click "Don't show again" and selects "Try a new task"
2. After accomplishing next set of 5 new task, the leveling post-edit dialog will show up again because the new type of tasks will start its own path of tracking edits.

• a user finishes 5 copyedit tasks
• a user sees the leveling post-edit dialog - a user clicks "No thanks"
• a user proceeds to to edit another 5 copyedit tasks - and sees the leveling post-edit dialog again suggesting to try Add links between articles tasks.
• a user clicks "Don't show again" and clicks "Try a new task"
• a user finishes 5 Add links between articles and sees the leveling post-edit dialog again suggesting Find references type tasks.

In T322386#8740661, @Etonkovidova wrote:

@KStoller-WMF please confirm that the following is an expected scenario (checked in testwiki wmf.2)

1. A user click "Don't show again" and selects "Try a new task"
2. After accomplishing next set of 5 new task, the leveling post-edit dialog will show up again because the new type of tasks will start its own path of tracking edits.

• a user finishes 5 copyedit tasks
• a user sees the leveling post-edit dialog - a user clicks "No thanks"
• a user proceeds to to edit another 5 copyedit tasks - and sees the leveling post-edit dialog again suggesting to try Add links between articles tasks.
• a user clicks "Don't show again" and clicks "Try a new task"
• a user finishes 5 Add links between articles and sees the leveling post-edit dialog again suggesting Find references type tasks.

My understanding of the requirements is that "don't show again" is task type specific, so "Don't show again" clicked while on a copyedit task applies only to the copyedit task type. Which is why you see it again when doing "add link".

Thanks for checking, @Etonkovidova!

In T322386#8741323, @kostajh wrote:
My understanding of the requirements is that "don't show again" is task type specific, so "Don't show again" clicked while on a copyedit task applies only to the copyedit task type. Which is why you see it again when doing "add link".

Ditto.
This is one of the many complexities of this task that I could have defined a little better (sorry!). This approach makes sense to me. It ensures we aren't annoying newcomers who just want to stick with the same task, but still gives them a reminder to try new tasks if they are progressing on. Also based on what we know from Newcomer task milestone analysis, the number of newcomers who will get exposed to several of these notices in a short period of time is very low.

Change 900686 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Leveling up: simplify logic to close the post edit drawer

https://gerrit.wikimedia.org/r/900686