For @Sneha review/sign-off:
(1) In Category (optional) and Location (optional) labels, the font for optional looks larger than in the figma design

figma design	commons beta

@Sneha - in production there is additional warning when a user removes categories, i.e.

• a user adds categories
• a user clicks on 'x' to remove all categories

The following inline warning appears:

Fixed in commons beta - needs to be verified in production.

Works as expected in commons beta.

Works as expected on commons beta.
Note to clarify the steps:

• Upload multiple files
• In the Describe step, fill in a title for the first uploaded file
• Click on "Copy information to all uploads following...", make sure that " Copy title (with automatic numbering)" is checked

The file titles in the upload should display the same title as the first file but with numbering.
Currently, in production (commons wmf.5) checking " Copy title (with automatic numbering)" will assign the same title to all files in the upload.

Checked on commons beta - single upload/multiple upload (and I've read the original discussion on Commons:Upload_Wizard_feedback#Issues_on_the_new_version).
The workflow that might cause some confusion
Steps:

• Special:UploadWizard - add a single file
• Properly fill in all required fields in Release rights fields
• In the Describe step - the "Same as caption" checkbox is checked
• Now, I'm filling in the Description field first, before the Caption field. i.e. click on the "Same as caption" checkbox to un-check it, so the description field is displayed.
• Then I change my mind and click on the "Same as caption" checkbox to make it checked and enter some text in the Caption field

If after that I want to make sure that the "Same as caption" checkbox does its job and filled the Description field with the same text as in the Caption field, I have no way to confirm it, since the Description field is collapsed when the "Same as caption" checkbox is checked. If I un-check the "Same as caption" checkbox - I will see my previously entered text.

Checked in enwiki betalabs - the current (fixed) behavior is:

• deselect all type tasks - Done button is active, a user can click on it and saves the no-task type selected filter. The count of found tasks is zero. The Done button is inactive.
• after that, selecting any topics won't change the count - zero tasks is found.

I re-checked the issue - the issue is fixed. There are more use scenarios I think need to reviewed- I added them to T365142: Empty state of Special:CommunityConfiguration/GrowthSuggestedEdits is confusing. It fixed in the sense that following the steps in the description won't produce the error.

Adding some use cases to review for the following:

Re-checked on commons wmf. 5 - seems to be working according to the specs

Re-checked on commons wmf. 5 - seems to be working according to the specs

• • Upload step: a file is assigned an automatically generated name
• Describe step: the automatically generated title is not displayed - no warning or user message to provide descriptive title

@Sneha - thank you for the comments above. I filed T365067: UploadWizard - Describe step: message "Caption/Description is required" should appear only upon submitting - added those two cases to, i.e. the Back button case and unchecking "Same as caption" checkbox.

In T362042#9791516, @Urbanecm_WMF wrote:

Hi @Etonkovidova and @Michael, thanks for the ping. This task is probably best tested locally, by temporarily disabling CommunityConfiguration (rendering the validation moot), making any change you want and then re-enabling the extension. That should allow you to create MW pages with invalid content pretty easily. Another approach can be to create the page first, and only then change the schema. With both approaches, you are likely to run into cache-caused issues (that would not actually happen in production), so I recommend to test with caching disabled (setting wgMainCacheType to CACHE_NONE temporarily).

If you want to test in beta, you'd need to find some way to "sneak in" an invalid config. In the past, that used to be possible by importing XML files or moving pages, but we might have fixed those holes already. Testing locally is probably the easiest way forward, I think.

Hope this helps!

In T364593#9791035, @Sneha wrote:

@Etonkovidova Regarding #3, I did not know about this warning so thanks for capturing this. Since we are clearly saying categories are optional it does not make sense to have this warning and dialog. I added a note on the categories ticket to make sure to remove. See comment here.

In T361049#9790936, @Sneha wrote:

@Etonkovidova The copy in the old warning about needs to be revised by the community. @Sannita is going to reach out to community to create a new message with just examples. Until then we ware using the old message which is why I strikethrough one of the AC related to it.

In T361049#9787078, @Sneha wrote:

@Etonkovidova

On commons beta the Title field is pre-filled with the automatically assigned unique name and there will be no warnings. In production, such pre-filled file name immediately triggers the user warning:

This is working as intended in commons beta. The error (if any) should appear when user hits next.

In T361049#9785334, @mfossati wrote:

In T361049#9784859, @Etonkovidova wrote:

(2) I have some problems testing these two AC:

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
• Update the copy for the current error message for when the user has not entered a descriptive title as show here.

There is no validation for a title to be actually descriptive - if I delete portion of that automatic title, the file name would be accepted.

I think that matches the descriptive criteria can be rephrased to validates against Titleblacklist rules: it's not really about being descriptive.

On commons beta I was not able trigger that warning. Although black-listed titles pages are present (e.g MediaWiki:Titleblacklist-custom-SVG-thumbnail),

These are Titleblacklist's custom system messages, which are different from the corresponding rules.

but the warning doesn't appear when I try to use black-listed titles. Two questions

• Is this a known deficiency of beta?

Yes, It seems so: there's no Titleblacklist rule on beta, see https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Titleblacklist VS https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist.

In T364593#9787093, @Sneha wrote:

@Etonkovidova thanks for capturing these details. The first one should be fixed. But second one is correct it was changed to all red after Marco informed me that having two different styling in the same line was not easily feasible. I updated my wireframes now too. Sorry for not updating it earlier.

In T362728#9787342, @KStoller-WMF wrote:

Thank you @Etonkovidova! Should we use T364650 for the follow up engineering improvements, or should I break that into subtasks?

In T362728#9782271, @KStoller-WMF wrote:

@Etonkovidova - Should I create a separate task for accessibility testing, or is that something you plan to cover in this task?

@Sneha - just double checking
(1) the scope of re-designing Describe step presently doesn't include Additional information from the figma mockup

(2) I have some problems testing these two AC:

In T359035#9778480, @Jdforrester-WMF wrote:

I think this is logged-in (with a privileged user) vs. logged-out (with just the 50 limit).

In T362042#9780970, @Michael wrote:

Yeah, in its current form, I'm not sure how many user-facing changes there are. This really comes into play when schemas are changed (by extension/skin developers).

So maybe, "seemingly nothing breaks in normal operation" is sufficient QA for this particular task?

But @Urbanecm_WMF has probably better guidance. I still don't have a good intuition yet for what kind of task/story should receive what kind of QA.

@Michael, @Urbanecm_WMF - I tested client side validation and some results & open issues are summarized in T360971: [QA task] Community configuration test cases

Checked in wmf.3 - works as expected.

In T363801#9774656, @Trizek-WMF wrote:

Connecting the top-of-the-page error message with the actual error is important. We have this problem at EditGrowth Feature, where a message at the top of the page says something went wrong, but nothing indicates which field is concerned, except if you scroll down the page. Have a link to jump to the error(s) would help.

@Trizek-WMF - I filed T364057: [minor] CommunityConfiguration: success/failure messages require scrolling up ; it can be merged with other, more general form submission/validation improvement task(s).

Checked in wikifunctions wmf.3 - aria-label is present (wikilambda-toggle-expanded-view on translatewiki.net).

The call from the task description works on wikifunctions beta - no errors/warnings were retruned.

Special:Preferences page has clear indication of saved/not saved changes:

• Save button is disabled when no changes have been made yet or when users' input has been submitted
• Save button is always visible when a user scrolling down/up the page
• for not valid/not saved users' input, an error message is displayed without additional scrolling up

Checked in eswiki beta the following test cases:

• MediaWiki:GrowthExperimentsMentorship.json and other json pages handle addition of properties quite efficiently. So far, I didn't find any way to break config via json pages.

Tested in eswiki beta and compared with es.Special:EditGrowthConfig.