Page MenuHomePhabricator

Community updates module: Title & Body text - support for Community Configuration
Open, HighPublic

Description

User story & summary:

As a new editor visiting my Newcomer homepage, I want to see community updates relevant to new editors, so that I can deepen my involvement in the wikis.

Parent task: T360485: [EPIC] Newcomer homepage: Community updates module (FY23/24 WE1.3 / FY24/25 SDS2.1.3)

Designs:

Community Updates: Figma designs for Homepage module.

Community Updates: Figma designs for the configuration form.

NOTE: Figma designs show the end state of the MVP release. This task only covers the Community Configurable text for this module.
Acceptance Criteria:

Initial Community updates Configuration form:

  • Checkbox: to turn the module on
  • Text field: Title (validation error: 50 character limit)
  • Text field: Body text (validation error: 150 character limit)

Event Timeline

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

  • 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?

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

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.