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.

Checked on testwiki wmf.11 - the edits to Special:CommunityConfigurtion are tagged with Community Confiuration tag , (e.g. MediaWiki:GrowthExperimentsSuggestedEdits.json&action=history

Checked in commons beta - works as expected.

Checked in wikifunctions wmf.10 view-source:https://www.wikifunctions.org/view/en/Z10001 only one instance is left:

Thank you @matmarex for looking into the issue! Basically, the purpose of this task is to effectively inform users that a page is protected and no editing is possible.
I checked it today on protected pages for Flow and for the new discussion tool (Talk pages). Flow pages look good, so the task is Resolved. Protected Flow pages on mobile inform users that a page is protected and hide all edit buttons:

The current implementation (eswiki wmf.10) - I marked the first AC as done:

Checked in eswiki wmf.10 :

• the link Special:EditGrowthConfig on Special:NewcomerTasksInfo correctly redirects to Special:CommunityConfiguration.

Thank you, @Michael for the thorough explanations! I agree that the way the CommunityConfiguration and Growth features (i.e. MentorDashboard link works quite efficiently when I checked. A user without sufficient permissions, is informed about it; a user with sufficient permissions and who is not a mentor will be redirected to EnrollasMentor).

In T365402#9876192, @AUgolnikova-WMF wrote:

Will be irrelevant after we merge the depicts patch

In T365541#9876174, @Cparle wrote:

@Etonkovidova does this also happen on production?

Checked in betalabs - works as before (i.e. the licence selection(s) is remembered during a user session (i.e. uploading another batch after the initial upload as per the task description).