Sounds good, thanks @JSengupta-WMF. DST will plan for this next week!

• As the event will be based in several timezones across East and West Africa, I would say staff in CET or UTC time zone might find it more convenient. The Codex presentation session is planned at the beginning of the day on 12.12.2024

Thanks for the details @JSengupta-WMF. A few questions:

@cmadeo Hi, I've added the data in our sheet.

Hi @Hghani! I'm SO sorry but I just realized I left a request out! We also need the top read article per month on EN wiki from Jan 2024-December 2024

We received input from the Design team during the RDS+Design offsite and are in the process of applying it to the current draft cards. We're also making minor adjustments in a few places. We anticipate using December to invite asynchronous comment from stakeholders on WMF opportunity areas for these Archetypes, followed by a mid-to-late December working session for synchronous input. All-in-all, we appear to remain on schedule.

Data was provided in this google sheet and it includes the 10 most edited wikipedias with their edit counts per the new requirements.

Updated the description to reflect the change from the top 10 most edited articles on EN to the top 10 most edited Wikipedias and their edit counts due to a request to change the graphic from Comms

Noting that we are starting to slowly drop all thumbnails in swift as a one-off clean up which would make the change in size of thumbnails easier: T379942: Gradually drop all thumbnails as a one-off clean up

Thanks for all the input @Bugreporter @TheDJ @mwilliams @sbassett @RHo.

Hey @AlexHollender-WMF I'm a designer, I thought the contribution was about design because it was tagged design. Sorry for the inconvenience this might have caused.

Draft Archetypes have been prepared, and we are anticipating further workshopping them at the upcoming RDS+Design offsite.

In T377616#10297272, @Estherkamso wrote:

I am interested in this task. Can I see the codebase so I can begin the cleanup

1. Displaying the event wiki(s) in various places

Adding a field to the event configuration form that allows organizers to either specify certain wikis, or select "This event is for all wikis". It would be required to either add one wiki, or select "This event is for all wikis".

1. Allowing editors to associate an edit with a specific event
We explored various options for how participants might tag edits with an event, so that things are properly tracked. A general idea is that if someone is registered for an event, that event is currently happening, and they are editing a page that is on the worklist for the event, we would automatically add the event tag to their edit summary. They could remove it if needed.

In T365298#10296939, @mwilliams wrote:

Thanks for this Jonathan! My main priority is to make sure the URL feels trustworthy...simple, clear, and familiar. Sticking to something very close to what we currently use for consistency and familiarity also seems like a good path forward.

Before chatting with you about the constraints the obvious and simple answer felt like login.wikimedia.org with the source wiki as a possible addition in the query parameter. I'm curious how difficult it would be to go in that direction. e.g. It's possible but would add multiple weeks to the implementation, etc.

Between the options you suggested for the wikiidentifier, I’d lean toward https://auth.wikimedia.org/enwiki/wiki/Special:Userloginover the base64url option, which seems less readable and potentially more “phishy” due to the encoded characters. "Auth" is slightly better than "SSO", but agree that most people probably won't know what it means either.

1. Organizers can create worklists, and define goals for specific articles

These explorations are about finding various opportunities to surface events to readers and editors: Figma

I am interested in this task. Can I see the codebase so I can begin the cleanup

Personally, I'm not sure I see an enormous issue with sso.wikimedia.org. The other proposed options seem a bit too vague to me for what SUL3 is actually trying to accomplish.

Thanks for this Jonathan! My main priority is to make sure the URL feels trustworthy...simple, clear, and familiar. Sticking to something very close to what we currently use for consistency and familiarity also seems like a good path forward.

Consumer hat: most people esp non native english speakers and non techies in general, don’t know what ‘auth’ ‘authentication’ or ‘sso’ means, as opposed to login or ‘account’ or even ‘user’