@KStoller-WMF , yes it needs more work but we do not need a separate task for it.IMO, it shouldn't be a big fix. I"ll create patches for it.

@Urbanecm_WMF, thank you for solving this quickly during our sync session. Assigning this to you to be moved to Q/A :).

In T362203#9739672, @Tacsipacsi wrote:

In T362203#9739550, @Cyndymediawiksim wrote:

However, this approach could lead to a situation where there is no obvious way for users to navigate back to the Special:CommunityConfiguration page from the history page as @Urbanecm_WMF highlighted above.

This is what the link among the content actions aims to solve.

In T362203#9705899, @Urbanecm_WMF wrote:

Would it be okay if the "View History" link lead directly to eg. https://es.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:GrowthExperimentsMentorship.json&action=history (where there would be no obvious way to get back)? Or do we want to do something to make this more clear?

In T362203#9707924, @Tacsipacsi wrote:

Couldn’t the action=history page be made linking back to Special:CommunityConfiguration? Similarly to VisualEditor’s Edit link, Community Configuration provides an alternate edit view of the same page, so putting its link among the content actions would make sense. (And even vice versa: simply call Skin::setRelevantTitle() on Special:CommunityConfiguration, which gives a history link, a talk page link etc. for free.)

@Etonkovidova, yes you can add providers to an extension.json file. In the CommunityConfigurationExample, a provider FooBar is declared. Some other providers are also declared in GrowthExperiments' extension.json file. To test, you would need to add the "skipDashboardListing": true flag to each provider you do not want to be seen on the dashboard. Like so :

@Sgs , is there a way in Codex, to put a backdrop/overlay on the success message that I can use as shown in the figma design?

• The summary box is huge. In one design, it’s a two-line textbox, in the other one, it’s a one-line input; in the implementation, it’s eight lines tall. This gives the impression that the edit summary can be however long I want it to be (and indeed, nothing on the frontend prevents me from writing an over 1000 characters long summary, even though the backend (MW core) caps the summary at 500 characters).

@JFernandez-WMF, in line with @Tacsipacsi's comment, what should be the correct number of lines given the backend (MW core) caps the summary at 500 characters)?

@nettrom_WMF , with regards to the temporary account conversion schema: https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/962569 , what kind of data are you expecting in a success or failed login? In the scenario where we have user *Unregistered56:

Moving this to QA. cc: @Etonkovidova.

I have tested in Beta Cluster with Try Suggested Edits set to 1, and I found that a new user does not receive a notification when 1 non-suggested edit is made. This is equivalent to setting the value to zero. I suggest that we modify the strict comparison in the code:

Thanks @Sgs and @Urbanecm for unblocking this. A Try Suggested Edit notification is shown for a new user with 0 edits. See below :

I've tried to debug this through looking at Logs from the Beta Cluster are sent to Logstash. I found errors about a worker dying and restarting. But I couldn't directly link it to why the notification was not being sent for new users. I'm moving this to blocked until I can maybe be able to ssh to deployment-deploy03.deployment-prep.eqiad1.wikimedia.cloud and find out why. cc: @Sgs

In T343288#9475250, @Etonkovidova wrote:

Test results on testwiki wmf.14 has shown the expected notification behavior:

testwiki Special:EditGrowthConfig (Jan 21/2024) settings:

Try Suggested edits notification	1
Keep going notification	1

new user	Made suggested edits?	Made non-suggested edits	Notification received
user A	no	no	received "Try Suggested edits notification" ✅ Expected behavior
user B	no	1 edit	no notifications the user might not be in the control group?
user C	1 edit	no	received "Keep going to learn more..." ✅ Expected behavior

Another of my new test users made 1 edit (non-suggested) and did not receive "Try Suggested edits notification" notification. User contributions for QTETest2 nov17 shows one non-suggested edit; Special:Notificaitons for that user do not show "Try Suggested edits notification" (Preferences-Notificaitons do have Growth features notifications enabled by default):

I'll re-test to see if it's an actual issue. (will provide an update in this comment)

I reviewed this in test.wikipedia production as well, and the Try suggested edits notification not appearing is most definitely a bug. Moving the task back to Doing. @Cyndymediawiksim, can you please check why this is happening and fix this bug that Elena found?

1. If it doesn't add a lot of complexity, I would prefer that we instrument all account creations. This is so we have a comparison when it comes to folks dropping off in this funnel. If we find that X% of temp users who start registration complete it, it helps if we know that Y% of non-temp users do (and preferably X% is higher than Y%). From what I can tell, that means we might want to rename the schema?

Schema can be renamed.

2. I'm definitely in favour of not having duplicate events. Just so I understand the event generation here, we're instrumenting both account creation and login, but the auto-login doesn't trigger a login event through this instrumentation? It's instead that it creates a second account creation "success" event?

In T332348#9326118, @Urbanecm_WMF wrote:

Hello everyone, I was asked by @Cyndymediawiksim to provide guidance with this task. I had a look at this and here's my current understanding of the task, based on conversations with Tgr and Kirsten.

In T278123: Provide capability for A/B testing task types, we introduced modules/ext.growthExperiments.DataStore/TaskTypesAbFilter.js (and related changes) to provide task type mapping (when an user has copyedit,links enabled and link recommendations is enabled, it gets silently converted into copyedit,link-recommendation), to support A/B testing of the Add Link feature. This addition was labeled as a "temporary hack", and this task was filled to get it removed. As mentioned in the task description, this resulted in production errors such as T332309.

According to @Tgr, we improved the filtering code to the point where the mapping could be just made configurable. One of the projects considered by the team is the Copyedit structured task, but apart from the fact that there will be no capacity to work on it this FY, it is unclear when we could eventually work on that project.

As such, it is a purely engineering judgement whether we want to keep the filtering code in (written properly with configuration, etc.), or whether we want to get rid of it and possibly re-do properly it in the future, for example when/if we get to the copyedit structured task.

With the above in my mind, I think the immediate next step to tackle here is to make an engineering decision whether the task type filtering capability should be kept or made configurable. Based on the decision, we can reformulate the task description to accurately record the decision made.

While making the decision, I think we should keep at least the following factors in our minds:

• Deployment of Add Link to additional wikis: Is the unstructured links task enabled on any of the wikis we're not yet deployed to? If it is, what would be the impact of removing the filtering code?
• Current state of the database: On wikis that have Add Link enabled, is the links task type enabled for any of the active users? What impact would removing the filtering code have on those users?