@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

Note that this is also happening in other edit forms. I have added a couple more screenshots to the task description.

Thanks Elena!

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

Thank you @Urbanecm_WMF and @Sgs for your comments here. To check if I am understanding correctly: we would use the per-field descriptions to display the recommendations for the help panel links? If that is the case, I agree with that approach.

Thank you @Etonkovidova & @KStoller-WMF!

Some types of Newcomer Tasks are surfaced through maintenance templates. Articles containing those templates are added to the Homepage's Suggested Edit feed. To see how many articles are available for each type of task, see this page.

Thanks Elena!

This sounds good to me as a short-term improvement. I will update the task description with that suggestion.

Thanks for filing this @KStoller-WMF and @Tacsipacsi for providing feedback on this. I'll address the different points below:

In T361324#9867903, @Sgs wrote:

I did some tests with max-width: 512px on all of our fields. All screenshots take on laptop wide screen 3582px.

current config in cswiki	CC2.0 suggested edits	CC2.0 help panel	CC2.0 help panel with sidebars

I can see some problems:

1. 512px maybe to narrow in wide screens, see help panel example
2. The chip input selectors (namespaces & and page titles) can grow vertically quite a lot like in the infobox templates case. Narrowing the control increases that vertical height
3. The horizontal gutter is different if the sidebars are hidden or not
   
   Some ideas:
4. extend the 512 limit
5. make the limit relative to the screen width
6. apply different limit to the chip input selectors than the rest of fields
7. investigate how to "flex" the form width or fields width based on sidebars hidden or not

Sure, that sounds good, thank you!

I am getting different spacings using Chrome's inspect/Developer tools:

Thanks @Etonkovidova for testing! This difference should be resolved once T358221: Add support for displaying grouped configurations is supported. @Sgs please feel free to chime in if my assumption is incorrect.

Thank you @Jdlrobson! To clarify, would the task description proposal cover both standard and night modes? Or do we need to make a new proposal for night mode?

Thank you @Etonkovidova, that is true, sections are still unsupported (T358221: Add support for displaying grouped configurations). This looks fine to me until we can resolve that task.

Thanks for filing this task @Jdlrobson! This is my suggestion:

Acceptance criteria is crossed out so I will close this as resolved and we can continue with the open questions in other tasks. Feel free to re-open if there's disagreement on this.

Thanks for testing @Etonkovidova 😊

Thanks everyone for your comments here. We will be re-styling from a Warning to a Notice message component. See example mock-up:

Here's the proposal @Sgs and I discussed yesterday:

@KStoller-WMF I have created T365888: Community Configuration: Checkboxes in 'Suggested edits' form should use 'turned on' language for this purpose. Feel free to adjust!

I suggest we go with 'The task is turned on', I agree adding context to the checkbox can work better. I will update designs with this new copy, @KStoller-WMF do we want to have an Engineering task for this?

Engineering work on this is being tracked in T358335: Allow to display informational header text in the editor. @KStoller-WMF I assume we can close this task, what do you think?

@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!

In T360445#9791108, @KStoller-WMF wrote:

• "Destination page" and "Label" could possibly be headers for the full column rather than needed for each new row.

In T363961#9810454, @KStoller-WMF wrote:

This is OK with me. (I admittedly find the turned on language slightly awkward since it has so many different meanings in English, however I can't think of a better suggestion at the moment).

@Sgs I have updated the descriptions that were separated by sections to have a single description at the top of the form until we support grouping (see task description). Do they make sense?

For consistency throughout the checkboxes and the turned on/off language:

I have updated the task description with the main things that were needed for a design review for the first release. Spacing was the main one, and it was already worked on 🎉.
Note that QA will do the accessibility review, and then reviewed by Design, so it does not fit into this task.

Thank you for creating this task Sergio, some input on your open questions below:

In T360445#9783835, @Sgs wrote:

This improves the current status quo we have but I think it does not complete the management requirement as it lacks a delete button (trash button in "design alternative") and also the "single" labels approach in the "design alternative" seems it would save some vertical space in the form which would improve the UX. What do you think?

I have discussed this with other designers + @KStoller-WMF and gathered some thoughts/questions.