Since we don't have support for form sections or groups yet (T358221), I think this task should be scoped to an informational section per form. That restriction open the door to render the section on the server instead of the client, however that might be counter productive for the next iteration in which we would want to display informational text on a per-section or group level. Any thoughts here? cc @Cyndymediawiksim @Urbanecm_WMF

Change #1021409 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Add informational sections to configuration forms

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

Moving to Doing, as the patch was reviewed.

Change #1023051 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Add mentorship key to en.json

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

Change #1023051 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add mentorship key to en.json

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

Change #1021409 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Add informational sections to configuration forms

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

Moving for Design review . @JFernandez-WMF - please review for font, line spacing etc. Also, it'd be helpful to have some feedback on the scope of this task (see my Notes below the screenshots).

eswiki beta	figma design

Notes:

• the Mentorship module implementation doesn't have "configuration" in the title, i.e. "Edit Mentorship configuration". The figma design does a great job to keep a user informed that a user, in fact, is editing Mentorship configuration.
• The additional indication of Mentorship section ("Mentorship" title in figma design) is not present. Again, having a clear visual separation of the forms' fields (as in the figma design) from informational/warning area provides a logical workflow for users.

Thank you, @Etonkovidova!

@Sgs - can we add the 'configuration' piece at the end of the form titles?

In T358335#9760051, @Etonkovidova wrote:

The additional indication of Mentorship section ("Mentorship" title in figma design) is not present. Again, having a clear visual separation of the forms' fields (as in the figma design) from informational/warning area provides a logical workflow for users.

Agreed, since right now we don't have the warning message or the following section in the 'Mentorship' form (Personalized Praise), I understand why the 'Mentorship' section isn't present yet. @Sgs should we create a task for this work (adding the section names)?

In T358335#9762675, @JFernandez-WMF wrote:

Thank you, @Etonkovidova!

@Sgs - can we add the 'configuration' piece at the end of the form titles?

In T361933: Community configuration: Special:CommunityConfiguration/PROVIDER should display the provider name in the header instead of provider ID we decided to remove the apostrophes around the provider name. Let's try to clarify that decision as I could not find context in the task description. Why was it a requirement to remove the apostrophes? cc @Urbanecm_WMF

In T358335#9760051, @Etonkovidova wrote:

The additional indication of Mentorship section ("Mentorship" title in figma design) is not present. Again, having a clear visual separation of the forms' fields (as in the figma design) from informational/warning area provides a logical workflow for users.

Agreed, since right now we don't have the warning message or the following section in the 'Mentorship' form (Personalized Praise), I understand why the 'Mentorship' section isn't present yet. @Sgs should we create a task for this work (adding the section names)?

We have a task for generic support for groups or sections, T358221. One design pitfall I see in figma is that the grouping is done at different "levels".

Let me try to clarify by listing the GrowthExperiments form section use cases:

Growth experiments use cases

• Mentorship and Personalized praise in the "Mentorship" configuration form. These two sections are indeed groups because they mix different fields under a common title.
• Newcomer homepage links in the "Newcomer homepage" configuration form. This is not a section because it does not group different fields. Newcomer homepage links is actually a field with two nested fields inside. Hence the Newcomer homepage links text should show as field label not a section title.
• Help panel links and Help panel settings in the "Help panel" configuration form. These seem to be again two groups because Help panel links groups the collection of links and also a final View more help articles link field. Help panel settings is a group indeed. However there's a pitfall under Help panel links, this title concides with the label of the collection of links which is missing.
• Suggested edits and Notifications in the "Suggested edits" configuration form. These seem to be again two groups. However there should be some degree of "nesting" in the Suggested edits fields.

I think part of this confusion is because from a visual side is impossible to know if a form is rendering correctly without knowing the underlying data structure that backs it. I think that we are missing to follow the Codex specification for nested fields (see docs). That would help designers and testers understand the hierarchy relation between properties in a form. And that should facilitate deciding which properties need grouping or which ones are already grouped by definition of its data structure. I have filed T364846: Collection items fields should be wrapped in a module like box for that and I think we should tackle it and then revisit the groupings in GrowthExperiments forms.

Based on conversation with @JFernandez-WMF we can proceed with a single informational section per form. Julieta will provide copy texts asap.

@Cyndymediawiksim, I have written copy for each edit form in T363614: Community Configuration: Add Information section to each Growth edit form, I am sorry tasks got mixed up!

I am going to update this task description with the proposed copy.

Change #1037472 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Update informational sections of providers

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

Change #1037472 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Update informational sections of providers

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

@Sgs - should the Growth experiments use cases from your comment https://phabricator.wikimedia.org/T358335#9794235 be added to T358221: Add support for displaying grouped configurations?

QA review

Mentorship form copy:

Newcomers are automatically assigned to mentors; these mentors are categorized as "Automatically assigned mentors" in Special:ManageMentors. A mentor can update their Mentor Dashboard settings to only claim mentees manually, they are categorized as "Manually assigned mentors". The ideal number of mentors is: one mentor for each group of 500 new accounts, with a minimum of 3 mentors. Mentees can also receive encouraging messages from established editors, which can improve new editor retention. The Personalized praise module surfaces praiseworthy new editors to their mentor, to help productive new editors feel more engaged and involved in the community.

Questions to @JFernandez-WMF

• the current view on eswiki beta, cswiki beta is as following:

@Cyndymediawiksim - the message in the task refers to Special:ManageMentors, but the implemented text on beta refers to Mentor Dashboard. The Mentor Dashboard links to Special:ManageMentors.

<div class="communityconfiguration-info-section"><p>Newcomers may be automatically assigned to mentors, and they are categorized as <i>Automatically assigned mentors</i> in the <a href="/wiki/Especial:Gestionar_mentores" title="Especial:Gestionar mentores">Mentor dashboard</a>. A mentor can also update their settings in the Mentor dashboard to only claim mentees manually, and then they are categorized there as <i>Manually assigned mentors</i>. The ideal number of mentors is: one mentor for each group of 500 new accounts, with a minimum of 3 mentors. Mentees can also receive encouraging messages from established editors, which can improve new editor retention. The Personalized praise module surfaces praiseworthy new editors to their mentor, to help productive new editors feel more engaged and involved in the community.
</p></div>

QA review

Help panel form copy:

The help panel can be available in any namespace, in reading or edit mode, as configured below. It includes the ability to search for help, click help links, and >ask questions to either mentors or to the help desk. It displays five links and one "view more" link. These can be configured to be any links in the wiki, but >recommendations are included below.

• @KStoller-WMF - the intro text (see the above) may be revised for clarity, especially since there are the cases (I listed them below) when the info seems to become not so relevant.
• the info refers to five links and one "view more" link. If admins edit MediaWiki:GrowthExperimentsHelpPanel.json and remove some of the links entirely, then the mentioning of the specific number of links in the info section might be confusing.

QA review

Newcomer homepage form :

• the text in the Newcomer homepage on Special:CommunityConfiguration page mentions defining infobox templat. On the form Newcomer onboarding (Special:CommunityConfiguration/GrowthHomepage) there is no field(s) accommodating the infobox templates.

Personalize onboarding for new account holders via post-registration help, Leveling up notifications, and defining infobox templates.

• also, referring to Leveling up notifications with no supporting titles on Special:CommunityConfiguration/GrowthHomepage (the titles for notifications - ry Suggested edits notification and Keep going notification - have no direct reference to Leveling up notifications or features.

QA review

Suggested edits form

Comparing with the figma design

• the following paragraph is not present:

"Some types of Newcomer Tasks are surfaced through maintenance templates. [...]"

• the link for the image suggestions is not present

figma design	beta

Thanks for the detailed QA!

In T358335#9877452, @Etonkovidova wrote:

• @KStoller-WMF - the intro text (see the above) may be revised for clarity, especially since there are the cases (I listed them below) when the info seems to become not so relevant.
• the info refers to five links and one "view more" link. If admins edit MediaWiki:GrowthExperimentsHelpPanel.json and remove some of the links entirely, then the mentioning of the specific number of links in the info section might be confusing.

Good point. I agree that including the exact number of links is unnecessary. Especially once we add support for easily adding or removing links: T366274: Support item management for arrays.

The help panel displays help pages about editing and one "view more" link. The help panel can be available in any namespace, in reading or edit mode, as configured below. It includes the ability to search for help, click help links, and ask questions to either mentors or to the help desk.

Since most of discrepancies Elena has noticed fall outside the original acceptance criteria of this task, and we should also update Figma designs/ copy, I'm thinking @JFernandez-WMF
should review the QA notes, update designs, and add a follow-up engineering task for the copy and UI changes needed.