@Urbanecm_WMF - could you provide some specific examples how to disable Suggested edits and Help panel in the config files?

Thank you, @Sjoerddebruin for reporting it! That change in color when a notifications changes from unseed state to the seen state, seems to be consistent with instances where such colors appear. For example, a success message (for a saved edit) displays the same color:

The found issues (reported in the task) were separated into phab tasks (see the tasks in the Task Graph for this task). Closing as Resolved since the scope of this task is done.

Checked on commons wmf.13 - all specs seem to be in place. The additional refinements will be addressed in T369746.

In T369053#9964550, @matthiasmullie wrote:

@Etonkovidova I misunderstood the ask and thought we wanted to convert all warnings to notice style.
Above patch should change warnings back to their original style, and re-introduce "notices" for "we recommend providing a full date if it is known" (date) and "we recommend keeping the number of items to a maximum of x" (depicts/statements)

As for depicts: the only thing we have there is a notice when more than 3 statements have been selected (from the autocomplete field)
Looks like you had ,,,,, input there (which, I suspect isn't triggering any autocomplete suggestions), which is simply ignored; only things ("chips") selected from the autocomplete matter.
(Nit: we could revise how that input field works and how/when it triggers warnings, but that's a separate thing)

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

To summarize

• on commons beta the Date field doesn't display a warning - it's either an error message or a notice
• I was not able to trigger any message for the depicts field

Checked in beta: -description have been added.

Checked on eswiki beta - works as expected; Special:ManageMentors displays the banner if the mentorship is disabled:

Thx, @Urbanecm_WMF for a suggestion to test frwiktionary beta!

In T366672#9950423, @Sgs wrote:

I agree it does not seem a high priority issue. I we should be able to replace the OOUI widget by T363375: Popover: Add Popover component to Codex in the mid-term, for the Echo menu at least. If @Etonkovidova agrees I think we can resolve this issue.

In T367986#9945425, @Michael wrote:

I'm not sure if anything here still needs doing? We've seem to have fixed the immediate issue, but should we still look into transitioning away from growth-specific tokens to more generic ones?

I'm adding the Technical-Debt tag here because it mainly seems like a refactoring that we may or may not want to do.

@matthiasmullie - I think I need some clarification on the following from https://gerrit.wikimedia.org/r/1051758

• the style of warnings has been updated to look like notices

Checked all three scenarios on commons beta - work as expected.

Fixed on commons beta:

For @Sneha review:

Checked on commons beta - the issue is fixed.

In T362328#9955022, @Sneha wrote:

cc @Etonkovidova

The following AC messages are missing

• If the file is ‘own work’ and has a date in the EXIF show that date in the date field by default with a message as shown here
• If the user proceeds without entering the date show the error message as shown here

Checked in commons wmf.12 - the error messages are displayed correctly according to the scenarios listed in the task description.

Thank you @Mbch331 for filing this issue! The issue is confirmed on wmf.12

• clicking on the blue dot button displays in the Console:

jQuery.Deferred exception: number 10609595 is not iterable (cannot read property Symbol(Symbol.iterator)) TypeError: number 10609595 is not iterable (cannot read property Symbol(Symbol.iterator))

• a tooltip "Mark as read" appears on hovering up
• the mouse pointer is displayed as a hand pointer implying that clicking on on the button will produce some action

In T365412#9943752, @Cparle wrote:

@Etonkovidova maybe you could confirm?

Another question - the order in which the items (i.e. months) are displayed is alphabetical on Special:ListObjectsByType/Z16098 and the order in the drop-down menu on Z13163 is difficult to identify.

Special:ListObjectsByType/Z16098	Z13163

Checked on testwiki wmf.11 and on arwiki wmf.11 - works as expected. It's possible to save an item with a blank label which would be displayed on Special:Homepage as an empty bullet point, but it should be in the scope of a different task if needed.

Checked on testwiki wmf.11 Special:UploadWizard, see example (autimatically asigned tile/imported description and user defined title/impoted description) - both issues seem to be resolved:

• an automatically assigned or a user defined title is displayed
• the description is imported

@Sgs - two files in the task description - for Add link task onboarding and for Help panel are marked as Restricted and are not displayed.

In T357699#9913747, @Sgs wrote:

I keep finding contrast issues and issues in general in GrowthExperiments interfaces, an example of that is the "help panel" and the "onboarding dialogs". At this point I don't know how many notheme skin-invert more we would need to introduce to fix all growth features. Since the task is just in the scope of the homepage, my proposal would be that we fix the rest of Growth features with Option 2 (when possible) instead of Option 1? I'm adding known issues (as issues that exist without the skin-invert applied) in T367986, given the spread of background-colors around the extension modules, maybe it's easier to handle this by use case? cc @Jdlrobson @ovasileva @Etonkovidova

Thx, @Sneha - I marked the items that are good as they are with a green check mark.

In T366376#9933773, @gerritbot wrote:

Change #1050463 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Fixes colors of data table sort icons and header in dark mode

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

In T366761#9933958, @Urbanecm_WMF wrote:

Note that in rOMWC7de06e315685: CommunityConfiguration: Log info and higher, I decreased the log level for CommunityConfiguration from "everything" to "info and higher". In this particular case, we're logging an error, so it is likely not related to the confusion @Michael mentioned, but noting that regardless, just in case.

There are no errors for wmf.11 deployment - https://logstash.wikimedia.org/goto/82d669789943d91b1169bc18ccd91f37. The errors stopped completely:

Checked in wmf.11:

Checked on commons beta - a page correctly scrolls to any field that prevents a user from publishing. The error message under the field is displayed - all behaves as per the specs.

Thx, @Sneha for the review and @matthiasmullie for the patch.

In T366376#9932722, @Jdlrobson wrote:

the icons in the table are still not visible

Yep this is covered by the last remaining patch https://gerrit.wikimedia.org/r/1050463 🙌

Copied the test results from https://phabricator.wikimedia.org/T366376#9932698

Test results - Special:CommunityConfiguration

Description	Element Location	Screenshot(s)
Accessibility issue - doesn't exist in Light mode Links must be distinguishable without relying on color (two issues)	.ext-communityConfiguration-Guidelines__Guideline:nth-child(1) > p > .external.text <a class="external text" href="https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Community_configuration">Learn more</a>

@Jdlrobson, @KStoller-WMF - I re-tested Special:CommunityConfiguration (and submodules), Special:EnrollAsMentor, and Special:MentorDashboard. Below are the test results (testing is done on eswiki beta. The issues listed there are specific for Dark mode.
It seems that except the icons on Special:MentorDashboard - all looks fine.

Thanks, @Urbanecm_WMF for the comments and clarification - closing this task as Resolved.

In T367201#9897588, @Urbanecm_WMF wrote:

Done. FWIW, I rephrased the beginning of both messages to not say "Communities can", as that is a phrasing that makes sense at eg. project pages (which address multiple communities at once), while the interface messages only address a single user, rather than multiple users (or communities) at the same time. This is how it looks with my patch applied:

Hope this is fine :). Moving to Code Review!

eswiki beta has the second AC implemented:

Checked - all looks as expected.

Testing note: check when group 2 is deployed - https://logstash.wikimedia.org/goto/aed67635717e182a88afc0330e118d36

Checked on commons wmf.11 - minor UI issues are filed as T368581, subject to @Sneha review.