In T368115#10048539, @gonyeahialam wrote:

I would like your feedback to this update to the filter @Daimona @MHorsey-WMF @VPuffetMichel

In T328919#10046294, @Krinkle wrote:

To figure out: it looks like the data provider phase runs MUCH slower in PHPUnit 10; locally, PHPUnit hangs for ~40 seconds before actually starting tests, as opposed to just a few seconds in PHPUnit 9. I still don't know what causes this, whether it's caused by the data provider changes, whether it's caused by our bootstrap code, etc.

Have we reported this to upstream PHPUnit? Sebastian seems pretty interested in performance recently. It's possible that there's a way we can do something different or better to avoid it, but I don't think he would mind finding out that this is something that can happen during upgrades. Perhaps he'd improve docs as a result to make the recommended solution easier to find, or perhaps some kind of warning or deprecation notice for whatever unusual thing we do.

OK, thanks, I'm closing this task then.

In T371711#10043695, @vaughnwalters wrote:

In T371711#10043689, @Daimona wrote:

Hang on a second, the namespace names are already as requested in the AC. What am I missing?

Where are you seeing that @Daimona ? Check out this event for example.

Hang on a second, the namespace names are already as requested in the AC. What am I missing?

In T371711#10041745, @alaa wrote:

Event > فعالية
Event talk > نقاش فعالية

@vaughnwalters and @Bachounda
Can you please put a link for the community discussion (as you mentioned that the community chose); for documentation?

In T369303#10039721, @ifried wrote:

@Daimona, has this already been done?

Can we have an updated translation for the associated talk namespace too, please?

In T365859#10030356, @vaughnwalters wrote:

• ❓ Events that start and end within the selected date range.
  • on betacluster when I switch from en wiki to ar wiki then the date range shown is inaccurate by one day. Is this a bug?

I agree that something like this would be useful. One thing to watch out for, especially for the dropdown approach proposed above, is that "wiki of the event" could mean either

1. The wiki where the event was created, or
2. The wiki(s) where the event activity (e.g., editing) will take place (which we'll implement for T362886)

Scheduled for tomorrow 2024-07-31 15:00 UTC.

In T364804#10025531, @vaughnwalters wrote:

• Below the title, the user should see the following text:
  • ❌ [number] editors generated, based on the following criteria: the bytes they contributed to the articles, the number of edits they made to the articles, their overall edit count on the wikis, and how recently they have edited the wikis.
    • Currently says editors found instead of editors generated. Need to change AC?

In T351818#10018995, @vaughnwalters wrote:

@Daimona checking this on betacluster and everything seems fine except it doesn't seem that response statistics are compiling on betacluster anymore (so I can't check anything inside of that tab). I don't THINK this would be related to this task though would it?

This would be ready for review but I'd like to confirm T365859#10017754 first.

In T349000#10018799, @Jdlrobson wrote:

Hey did this get fixed? I can't reproduce it now on the test URL.

@gonyeahialam Just to confirm: with the dates now being in bold, we should also remove the clock icon as in the specs, right?

In T365859#10016055, @ifried wrote:

While I agree that this solutions seems to be sufficient for the typical use cases, I'm still convinced that the behaviour is really complex and potentially confusing. I agree with the sentiment in T365859#9914041 that we may need to rework this, and I'd still consider having the full 4 fields in the form. While more fields means more complexity, fewer fields also means more surprising behaviour. I've now spent hours engineering this and barely know how it works. I would assume a user coming to use it for the first time might be very confused.

Thanks for sharing this, @Daimona, and I completely agree with you that there are a lot of ways that this could be handled (and perhaps this is not the best way). Can you perhaps share a bit more explanation of how the 4-option alternative could work? I sorta get it, but lots of questions come up in my head when I think about it, so perhaps I need more of a rundown of your thinking on it! If there is a better approach, then let's lay it out and determine whether it should be done instead. Thanks for all of the thought & work you have put into this so far!

@gonyeahialam Thank you!

I'm a bit confused by the task description and want to make sure that I understand it correctly. If I choose to hide ongoing events, then enter July 20 as "From" and July 30 as to, what events should I see? My interpretation is that:

• Event is July 10 to July 15: not shown (obvious)
• Event is July 15 to July 25: not shown (?)
• Event is July 15 to August 10: not shown (?)
• Event is July 21 to July 28: shown (obvious)
• Event is July 25 to August 10: not shown (?)
• Event is August 10 to August 15: not shown (obvious)

Yup, what Andre just said. My idea is to close this task once we confirm that the community has been notified of this issue.

Fixed. Will be live with the next l10n update.

There's nothing we can do about this, as it's caused by on-wiki styles. It's even reproducible when using English. I'm not sure what that rule is meant to achieve, and styling all inputs (and more) en masse is probably not the best. I guess changing the selector to input:not(.mw-widgets-datetime-dateTimeInputWidget-field) would be enough for a quick fix.

In T370666#10005255, @Ragesoss wrote:

I do not have request logs for it. Someone on Telegram noted that registration is closed; can that be related?

We now have a total of 4 modules: event page JS, event page styles, special pages JS, special pages styles. I think it's good enough for this task. For QA, just make sure that everything is still looking good and there are no prominent client-side errors (e.g., a button that does nothing when clicked, a modal that doesn't open, or an unstyled element, etc.).

For QA, the only thing to check is that the behaviour of all the invitation list special pages (Special:GenerateInvitationList, Special:InvitationList, Special:MyInvitationLists) is unchanged in the following scenarios:

• Invitation lists not enabled ($wgCampaignEventsEnableEventInvitation = false)
• Invitation lists enabled, but user not allowed to use them
• Invitation lists enabled, and user is allowed to use them

That's odd. I can't find anything suspicious in the logs, but I also don't really know what to look for. I'm not sure if we log all the outbound requests (as opposed to those that failed, but there are none for event 679). Would you happen to have request logs for this event?

In T370443#9999210, @vaughnwalters wrote:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CampaignEvents/+/1055295/1/i18n/qqq.json

The above change doesn't include "editors found". Is this intentional? If so, we should change the AC. @Daimona

In T368115#9998433, @gonyeahialam wrote:

@Daimona Can you expand more on the challenges of having a filter that applies to both events and Wikiprojects even though all the filter options aren't always going to be applicable to both?

(Made the task more general, and added simpler reproduction steps that don't require any extensions)

Button text has been updated and the info chip work is tracked in T370473, moving this back to QA.

In T370181#9993357, @vaughnwalters wrote:

2. Right now when there are no editors the Processing message still displays instead of the 0 editors generated message. To reproduce, create a new article in the mainspace and then add that article only to a new invitation list at Special:GenerateInvitationList, then visit Special:MyInvitationLists

I don't think this could happen. I've created multiple invitation lists with just one article and everything works fine. Can you please double check again? I suspect that when you checked the special page, the job for generating the list was still in the queue.

Here is a video of retrying it, and you can see below the other jobs where I tried the same thing that are all still marked as processing:

This is scheduled for Monday 22 at 13:00 UTC.

In T370181#9992590, @vaughnwalters wrote:

1. As seen in the images below, the icons (notice style and success style) should be slightly smaller within the div that contains the class cdx-info-chip

In T356683#9992934, @vaughnwalters wrote:

The button is +Add instead of +New. Do we just need to update the AC for this or does the copy need to change?

In T364804#9986643, @gonyeahialam wrote:

@Daimona @ifried another thing I mentioned above is that we will also need to add the 'view article list' when no editors are generated so that organizers can reference it when creating a new list.

I've looked into the popup thing again. First of all, Codex does not seem to have that popup component: T363375. Also, as I mentioned above, the OOUI version only exists in JavaScript and I'd rather not use it for now. So, for this first version I have the following 2 proposals:

In T364967#9974973, @Umherirrender wrote:

Happen on CI as well, providing a flaky test.

In T364804#9978069, @ifried wrote:

• Let's not rewrite the copy; we need to move forward, and I think the current copy works for the MVP.

In T364802#9977630, @gonyeahialam wrote:

Shouldn't the same message for when the list is generated be used for when the list isn't generated?

In T365629#9977404, @gonyeahialam wrote:

In T365629#9975217, @Daimona wrote:

In T365629#9975154, @vaughnwalters wrote:

❓ Noting that Events in the article list get the "The following articles are not in the main namespace." error while other pages that are not in the main namespace (such as Special:EditEventRegistration in this example) get a different error. I think this is probably fine since it does still display an error, but just calling it out here because it is inconsistent. Is this something we would want to fix? It not, we can move this to design sign off.

I think that's a consequence of special pages not being real pages. It'd probably be non-trivial to fix, so I'd vote for leaving it as-is if possible.

I wonder if users will often make the mistake of entering special pages, if they do then the invalid message will not help them identify and solve the problem.

In T364802#9977409, @gonyeahialam wrote:

So the current behaviour mentioned in this task is no longer the current?

In T364802#9977391, @gonyeahialam wrote:

No. I mean that the current expected behaviour is that you always see this message when going to Special:InvitationList, regardless of whether you generated the list or not.

@Daimona I thought in another task we said we show a specific message to people who didn't create the list but try to assess it?

In T365629#9977357, @gonyeahialam wrote:

If the user enters a Wikidata item name or Category page name, what will be the error?

In T364804#9977060, @gonyeahialam wrote:

@Daimona We should use the message component, I was just thinking what message type will be appropriate here - notice, warning or error. I decided to go with 'warning' based on the reasons I describe below, let me know your thoughts.

Actually one more challenge. The CSS-only version of the accordion component does not seem to support actions. I tried a DIY implementation but clicking the button results in the accordion expanding as well. Also, even in OOUI, the popup button is a JS widget and we're currently refraining from adding JS widgets to this page due to T351818. Could we use the accordion description instead?

Also: we need an actual tooltip/alt label for both "info" buttons, so that the purpose of the button is understood by screen readers etc. Something like "Help" or "More information" would do.

In T364804#9974565, @ifried wrote:

My only concern is that we'll need to create the documentation, which doesn't exist yet, and I would like it to not be a blocker for the task. So how about I remove the link for this task and create a separate task to add in the link when the documentation has been created?

In T365629#9975154, @vaughnwalters wrote:

❓ Noting that Events in the article list get the "The following articles are not in the main namespace." error while other pages that are not in the main namespace (such as Special:EditEventRegistration in this example) get a different error. I think this is probably fine since it does still display an error, but just calling it out here because it is inconsistent. Is this something we would want to fix? It not, we can move this to design sign off.

In T364802#9974571, @gonyeahialam wrote:

In T364802#9963020, @Daimona wrote:

In T364802#9962489, @vaughnwalters wrote:

@cmelo Right now, even if I haven't generated an invitation list, but I go to Special:InvitationList I see the message Your list of editors to invite is being generated. Refresh the page in 5-10 minutes to view your invitation list. Is this expected for now? If so, then this ticket can be sent to design sign off.

Yup, that's the expected behaviour at this time.

@Daimona By 'at this time' you mean till the task for the copy change is done, right?

In T364804#9974535, @Daimona wrote:

In T364804#9974351, @gonyeahialam wrote:

In T364804#9974095, @Daimona wrote:

Also one more: should any of the accordions be open by default?

If it is possible to choose different behaviours, can the Highly recommended be open and the other one be closed by default?

Yes, it is possible. I'll do this.

In T364804#9974351, @gonyeahialam wrote:

In T364804#9974095, @Daimona wrote:

• Can we not hyperlink "invitation list criteria"? I think this will become redundant once we add a help link to this special page (which we also discussed yesterday). Speaking of which, should I create a task for that?

I wouldn't be redundant. It is good to have the help link on the special page but it is also best to surface the link where it is most likely to be needed. So when people see 'criteria' and they want to learn more they can immediately click on the link, it wouldn't be always obvious that they should click on the special page help link.

Also one more: should any of the accordions be open by default?

Thanks!

In T364804#9971301, @ifried wrote:

Hey there, @Daimona & @gonyeahialam: I have updated the AC based on our discussions today; let me know what you think, and thank you both for all of the questions you raised & ideas you shared!