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

[mediawiki/extensions/GrowthExperiments@master] [WIP] Config: add community updates initial config

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

Similar to T365606, the provider that holds the suggested edits intro links and the leveling up notification thresholds is a server configuration provider. However the nature of the community updates module is data rather than server config. We need to decide how to proceed:

• Treat community updates community config as server config: not ideal, we considered this an anti-pattern in the past. Should we capture this in CC2.0 guidelines or technical docs? cc @Urbanecm_WMF
• Create a new (data) provider: shortest solution although it creates yet another "entry point" for Growth features configuration in the dashboard.

Note on designs: the help text is displayed above the field in the Figma designs but help text is rendered below in the editor, can we update designs? cc @JFernandez-WMF

In T367223#9899843, @Sgs wrote:

• Create a new (data) provider: shortest solution although it creates yet another "entry point" for Growth features configuration in the dashboard.

Especially when thinking about future iterations for Community Updates, it probably makes sense for them to have their own provider. If they keep growing in complexity (scheduling multiple updates, etc.), then I can see them taking up a lot of space on that form and could "drown out" the other configuration that exists there.

Note on designs: the help text is displayed above the field in the Figma designs but help text is rendered below in the editor, can we update designs? cc @JFernandez-WMF

In principle, Codex does not only support help-text for fields, but also descriptions. I wonder if alternatively we could use this opportunity to add support for those to CommunityConfiguration? That should not be a big deal, basically just in every place where we allow a -help-text message, we would also allow defining a -description message. Then the people implementing a form can pick what is appropriate.

What do you think?

If creating a new data provider is the "cleaner" technical solution, I think that's OK from the end-user perspective.

We may need to eventually improve the organization (and perhaps add search) to the Community Configuration dashboard as more features are added, but that's not an issue yet. I agree with Michael that this feature could grow in complexity, furthermore in the future it might no longer relate to "Newcomer onboarding" if the Homepage is made available to all users. T350837: Homepage access for all account holders

@Sgs - Should we ask for updated designs? I assume if nothing else, you need a new short description of the feature for the Dashboard, correct?

In T367223#9899843, @Sgs wrote:

Note on designs: the help text is displayed above the field in the Figma designs but help text is rendered below in the editor, can we update designs? cc @JFernandez-WMF

I just realized from T367792: Clarify recommended usage of description vs help-text in form fields that there's Codex support for "descriptions" instead of help texts, I think we adding the description above the field is fairly easy to support in CC2.0, then the designs are just fine. What do you think? cc @Michael @JFernandez-WMF

In T367223#9901325, @KStoller-WMF wrote:

If creating a new data provider is the "cleaner" technical solution, I think that's OK from the end-user perspective.

Alright. Let's proceed with this solution.

We may need to eventually improve the organization (and perhaps add search) to the Community Configuration dashboard as more features are added, but that's not an issue yet. I agree with Michael that this feature could grow in complexity, furthermore in the future it might no longer relate to "Newcomer onboarding" if the Homepage is made available to all users. T350837: Homepage access for all account holders

+1

@Sgs - Should we ask for updated designs? I assume if nothing else, you need a new short description of the feature for the Dashboard, correct?

I think the designs are just fine (once the help text vs description question is solved). Yes, we need a new description for the dashboard.

In T367223#9902727, @Sgs wrote:

In T367223#9899843, @Sgs wrote:

Note on designs: the help text is displayed above the field in the Figma designs but help text is rendered below in the editor, can we update designs? cc @JFernandez-WMF

I just realized from T367792: Clarify recommended usage of description vs help-text in form fields that there's Codex support for "descriptions" instead of help texts, I think we adding the description above the field is fairly easy to support in CC2.0, then the designs are just fine. What do you think? cc @Michael @JFernandez-WMF

Sounds good!

I think the designs are just fine (once the help text vs description question is solved). Yes, we need a new description for the dashboard.

Maybe I missed something, but on the designs I placed the Community Updates setting inside of 'Newcomer homepage' (now Newcomer onboarding). Did we change placement? @KStoller-WMF

In T367223#9904871, @JFernandez-WMF wrote:

Maybe I missed something, but on the designs I placed the Community Updates setting inside of 'Newcomer homepage' (now Newcomer onboarding). Did we change placement? @KStoller-WMF

See: https://phabricator.wikimedia.org/T367223#9899843 & follow up discussion. @JFernandez-WMF - but please let me know if you think that's an issue.

In an attempt to unblock this, here's a proposed description for the dashboard:

Community updates
Share important community news, campaigns, events, or WikiProjects on the newcomer homepage.

@KStoller-WMF Sorry, I somehow missed that comment that was right above :) That sounds good to me, thank you for clarifying and for providing a suggested copy — I think it works great

In T367223#9904871, @JFernandez-WMF wrote:

Sounds good!

Filed as T368160

In T367223#9908109, @KStoller-WMF wrote:

In an attempt to unblock this, here's a proposed description for the dashboard:

Community updates
Share important community news, campaigns, events, or WikiProjects on the newcomer homepage.

Thanks for the copy. Sadly, as I see it, the task is blocked on T367655, since we only want to show this on Beta wikis.

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

[mediawiki/extensions/GrowthExperiments@master] Config: remove CommunityUpdates provider if feature not enabled

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

Change #1046629 abandoned by Sergio Gimeno:

[mediawiki/extensions/GrowthExperiments@master] [WIP] Config: add community updates initial config

Reason:

Suqashed in Ia757d6b3e8c571dfd09d5d6727ca91d34c155f49

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

Change #1049927 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config: add community updates config provider

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

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

[mediawiki/extensions/GrowthExperiments@master] Config: display text as description instead of help text

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

Change #1051795 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Config: display text as description instead of help text

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

Moving Elena's comment to this task:

In T368805#9967831, @Etonkovidova wrote:

@JFernandez-WMF @KStoller-WMF - the both links in the task description don't seem to be working - displays "couldn't find file" message.
I found the following figma references to Community updates banner -this figma link; not sure if the design there is up-to-date.

Minor questions:

(1) the link Community Updates redirects to https://www.mediawiki.org/wiki/Growth/Community_Updates not to the Spanish translation of the page - https://www.mediawiki.org/wiki/Growth/Community_Updates/es. Is it a normal behavior?

<a href="https://www.mediawiki.org/wiki/Special:MyLanguage/Growth/Community_Updates" class="extiw" title="mw:Special:MyLanguage/Growth/Community Updates">Community Updates</a>

(2) A suggestion - dipslay should be followed by an object or may be used in a passive voice, e.g. "is displayed".
This Community Updates module will display on the homepage and should be used to share ...

(3) Movement strategy’s “Topics for Impact” recommendation redirects to https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Identify_Topics_for_Impact#Changes_and_Actions%7C2030 which produces "this topic could not be found" message on the page.

<a class="external text" href="https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Identify_Topics_for_Impact#Changes_and_Actions%7C2030">Movement strategy’s “Topics for Impact”</a>

Maybe it'd be better to make the link direct to just a page not to a specific section?

(1) the link Community Updates redirects to https://www.mediawiki.org/wiki/Growth/Community_Updates not to the Spanish translation of the page - https://www.mediawiki.org/wiki/Growth/Community_Updates/es. Is it a normal behavior?

@Sgs is this a fairly easy improvement? Ideally we are linking to the translation if it's available, but most languages won't have translated versions of the mediawiki page, so the English version should be the default if there isn't a translation available. (I don't think we need to fix this if it's a complex change, but I assume it's a minor fix).

(2) A suggestion - dipslay should be followed by an object or may be used in a passive voice, e.g. "is displayed".

This module will be turned off by default, so I opted for language that didn't imply the module was already visible / displayed. But writing copy is not my strong-suit. I'm not opposed to a change, but I'm not sure it's necessary.

(3) Movement strategy’s “Topics for Impact” recommendation redirects...

Oh bummer, I incorrectly assumed that page was relatively stable, but it appears a section changed after I wrote this task. I agree linking to the base page is safer: https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Identify_Topics_for_Impact
@Sgs can we make that small change?

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

[mediawiki/extensions/GrowthExperiments@master] CommunityUpdates: use base url rather than section for info link

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

In T367223#9971493, @KStoller-WMF wrote:

(1) the link Community Updates redirects to https://www.mediawiki.org/wiki/Growth/Community_Updates not to the Spanish translation of the page - https://www.mediawiki.org/wiki/Growth/Community_Updates/es. Is it a normal behavior?

@Sgs is this a fairly easy improvement? Ideally we are linking to the translation if it's available, but most languages won't have translated versions of the mediawiki page, so the English version should be the default if there isn't a translation available. (I don't think we need to fix this if it's a complex change, but I assume it's a minor fix).

I'm unfamiliar with the Special:MyLanguage code, but from what I hear this sounds like a bug in the upstream. For instance, if I test against the "Growth" link from This page allows you to edit configuration of...in Special:EditGrowthConfig, dawiki, I also get redirected to the English page rather than the dansk, which exists. @Etonkovidova, could you help confirming this issue is present broadly for any Special:MyLanguage? I haven't found any open phab neither docs around the expected behavior of Special:MyLanguage. That is because I'd like to know which language should be picked up for a user that navigates to https://www.mediawiki.org/wiki/Special:MyLanguage/Growth/Community_Updates from another wiki. Should the wiki source language be used instead of the mediawiki.org user preference?

(3) Movement strategy’s “Topics for Impact” recommendation redirects...

Oh bummer, I incorrectly assumed that page was relatively stable, but it appears a section changed after I wrote this task. I agree linking to the base page is safer: https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Identify_Topics_for_Impact
@Sgs can we make that small change?

Sure.

In T367223#9972723, @Sgs wrote:

In T367223#9971493, @KStoller-WMF wrote:

(1) the link Community Updates redirects to https://www.mediawiki.org/wiki/Growth/Community_Updates not to the Spanish translation of the page - https://www.mediawiki.org/wiki/Growth/Community_Updates/es. Is it a normal behavior?

@Sgs is this a fairly easy improvement? Ideally we are linking to the translation if it's available, but most languages won't have translated versions of the mediawiki page, so the English version should be the default if there isn't a translation available. (I don't think we need to fix this if it's a complex change, but I assume it's a minor fix).

I'm unfamiliar with the Special:MyLanguage code, but from what I hear this sounds like a bug in the upstream. For instance, if I test against the "Growth" link from This page allows you to edit configuration of...in Special:EditGrowthConfig, dawiki, I also get redirected to the English page rather than the dansk, which exists. @Etonkovidova, could you help confirming this issue is present broadly for any Special:MyLanguage? I haven't found any open phab neither docs around the expected behavior of Special:MyLanguage. That is because I'd like to know which language should be picked up for a user that navigates to https://www.mediawiki.org/wiki/Special:MyLanguage/Growth/Community_Updates from another wiki. Should the wiki source language be used instead of the mediawiki.org user preference?

@Sgs - you're right. I checked and also couldn't find any instances where a user would be redirected to an English version of the doc page. Although I still think it's not user-friendly, the issue is not seriously impacting user experience and it's is an upstream issue.

Checked in beta - the screenshot below shows error handling (no issues):