In T356679#9901158, @ifried wrote:

Ah, I think redirecting the user to the login page is better than a message that *tells* them to login, so we can keep the current behavior, @cmelo. But to clarify: Is this behavior only for cases when the user is not logged in and the extension is enabled on the wiki? I am asking because I think this would be appropriate behavior for when the extension is enabled, but it would not be appropriate behavior if the extension is not enabled.

Thanks, @ifried and @Daimona,

1. Yes, they should with a full stop because they are complete sentences. Thanks for checking in about this!

This is done now

2. Yes, in cases when the feature is not enabled on a wiki, the user should see the same message, whether or not they are logged in. I have updated the AC.

I will add it, thanks

But one thing occurred to me: I don't think we currently cover in the AC cases in which the wiki has the feature enabled, but the user is not logged in (so we don't yet know if they can access the feature or not). The best behavior would probably be to have a message for that too, such as: "Please login to see if you can access invitation lists." Is there a default way that the code is currently handling this?

At the moment, if the user is not logged in and tries to access Special:GenerateInvitationList, the user is redirect the to login page.

In T366354#9876945, @Ladsgroup wrote:

Once the discussion is over on the team side, let me know to review the schema, thank you!

In T366354#9894448, @Daimona wrote:

Thank you. Is this ready for DBA review then?

In T366354#9890136, @Daimona wrote:

I was going through this again, and I have a few questions/thoughts:

• AIUI, "worklist" is just the list of articles. "Invitation list" is the list of users to invite, and we're also using this term to identify the combination of worklists + users. But then, shouldn't ce_worklists actually be called ce_invitation_lists? ce_worklists_articles is maybe fine, though I'm unsure about the plural in "worklists". ce_worklists_users would presumably be ce_invitation_list_users?
• Who should be able to view a given invitation list? I thought it would only be the person who created the list itself (not the event). If so, we should store the creator of the list in the ce_worklists table, else we don't know who each list belongs to.
• Thinking about indices. In SpecialMyInvitationLists, we'll need to filter by user and, optionally, wiki. So, I think we'll need a composite index on user + wiki (in this order). I don't think the application needs an index on the wiki alone, but unsure about whether it's needed for analytics. The other indices seem sufficient (I think we'll only need primary keys and the indices on invitation list IDs).
• There's also the page ID question that was discussed in code review, which should go with the DBA review.

@ifried just some notes on this one:

• I think this could be merged with T356679
• The default way to add messages to translation's files, is to make only the first letter uppercase
  • So this: You are not allowed to use Invitation Lists
  • Would be:You are not allowed to use invitation lists

I am saying this because this type of questions always shows up in code reviews.
Not sure though about the reason behind it, but I think it is due to internationalization or maybe just because it is the default, but @Daimona may know more about the reason why.

In T366354#9889709, @Daimona wrote:

In T366354#9885784, @Daimona wrote:

@cmelo The current schema only stores the wiki of the event page, but that field might be absent.

(Small correction: it doesn't. We're only storing the event ID, which can be used to derive the event wiki. Still, the event ID is optional, so my original comment stands)

In T356679#9888770, @gonyeahialam wrote:

@cmelo I don't think so. Are you already done with development of this? The changes are only copy changes.

In T356679#9888678, @gonyeahialam wrote:

Preliminary feedback from the Usability test for the Invitation lists MVP
(Urgent feedback that needs to be worked on for people to be able to use the tool.)

• Some participants misunderstood the Invitation list name field to be where they add their own invitation list(list of editors to invite) rather where they write the name of their invitation list
• Most participants thought they are to enter the event page URL instead of the event page name in the Event page field
• Participants understood the how to input the article list but many didn't understand the purpose. They thought the list will be sent to participants for them to know the articles to be worked on during the event. They also didn't know to exclude redlinks.

In T356679#9886018, @ifried wrote:

Thanks for flagging this; and we discussed this in backlog refinement today, @cmelo! Yes, I think we should have one main message for all circumstances, which is "Invitation Lists is not enabled on this wiki." I have updated T365068 with this information.

@ifried one last question on this, should we have a custom message for when Event Invitations is not enabled on a wiki rather than just show an empty page?

In T356679#9869645, @ifried wrote:

Hello, @cmelo! Yes, ideally, we would want to allow wikis to decide if they want Event Invitations. For some wikis (for example, Meta-Wiki), it does not seem like it would be a very useful feature. For some other wikis, they may want Event Registration, but they may not want Event Invitations (for example), so we would like for them to choose which features they want turned on and off. So, my first choice would be to allow each wiki to choose if it is enabled.

However, I think we also discussed in the past that it may add extra complexity to allow each wiki to turn it on/off. Also, in the future, we could handle the situation of wikis turning features on/off via Community Configuration. So, would an easier alternative to be to have the extension released to all Wikipedia wikis that have the CampaignEvents extension enabled as default, but they have the option to hide it if they do not want it?

So, I see a few options (and there are probably more options, but these are just a few of them):

• Option 1: We turn on Event Invitations for all wikis that have the extension enabled by default
• Option 2: We turn on Event Invitations for no wikis that have the extension enabled by default, but we can enable it on individual wikis that request it
• Option 3: We turn on Event Invitations for only Wikipedia wikis by default

To me, Option 2, followed by Option 3, is the probably the best. Option 2 offers us the most flexibility in our communication with communities in getting the extension enabled. I'm not as interested in Option 1, since the extension is already enabled on Meta-Wiki and it already has many users with the organizer right on the wiki; I don't think we need to try to convince that community to enable a new feature/power to organizers on Meta-Wiki, when the actual feature itself will be of minimal value.

@Udehb-WMF @EUwandu-WMF & @Sadads, I'm curious about what you think about the question of whether Event Invitations should be enabled on all wikis (by default) that have the CampaignEvents extension enabled. Eventually, we will want this to be chosen by wikis via Community Configuration, but we need to make a decision in the meantime. Maybe there is a better way to think about this, so I would love to hear your perspectives!

In T366354#9871859, @ifried wrote:

Ahhhh, thank you for clarifying, @cmelo!

In the earlier versions of Event Invitation designs, we did show which article generated which user in the invitation list. However, after consulting with @Sadads, we heard that this would probably not be very useful, whereas more data about the users themselves (such as their edit count) would be more useful. Now, I do not know if we will get a request in the future to show which users came from which article, but we have so far discussed that it may not be very valuable.

OK, thank you, In this case I will remove it.

However, there is one use case that I can think of, which is the following: Let's say that an organizer does not like their Invitation List because they think that many of the users in the list don't seem like good candidates to invite. For this reason, they may want to generate a new invitation list with a revised worklist. In this case, it would be helpful to know which users came from which articles, so they could say, "Okay, this article DID generate a list of users who I would want to invite, so I'll include that article again, but this article didn't, so I won't include this article." Then, if we later allow users to export an invitation list or to select users to email from the invitation list, they could use that finalized version of the invitation list, rather than needing to pick and choose various users from multiple lists.

This makes me think: Data on which user is from which article will not be useful for the MVP, but it could be useful for later versions, if we provide support for potential actions that an organizer may take after generating an invitation list.

What do other people think? Would also love feedback from @gonyeahialam.

Thanks @VPuffetMichel and @ifried.

Hi @ifried, @VPuffetMichel, in this new schema to store the worklist date, I added some columns to relate a user with articles in a worklist.

In T366354#9870902, @Marostegui wrote:

@Ladsgroup could you review this request? Thanks!
@cmelo a quick glance shows that you are not having any single PK on any of the tables, is that correct? Or should we assume cew_id cewa_id cewuba_id would be PK for each table?
If you could provide the full "show create table" for each table, that would be clearer to review.

In T366354#9869820, @Marostegui wrote:

@cmelo is this task meant to be for DBAS? There is no mention to the storage you want to use, is this request for a MariaDB database in our misc sections? If so please follow: https://wikitech.wikimedia.org/wiki/MariaDB#Database_creation_template

Hi @ifried, while adding the feature flag for this special page, some questions come up on code review:

Hi @Iflorez, wondering what do you think about the new DB schema to store the worklists data, does it sound good to you?

We also think it would be nice to have a link to the list of worklists.

I don't understand this.

Thanks @Isaac, @ifried and @Daimona, it is so nice to see all this details, here are some thoughts I have:

@gonyeahialam we may need pagination for this one

@gonyeahialam we are wondering where this empty state image is.

@gonyeahialam We have a question about scrolling it, let's say we have a big list of users (200), should the accordion have a scroll?

To be able to test it locally, you need to add the below to your LocalSettings.php:

In T356679#9855550, @gonyeahialam wrote:

@ifried Let's go ahead with you initial suggestion for the Event page field. If there is confusion reported or observed in the feedback survey or usability test then we can change it.

In summary:

Invitation list name
My Event Invitation List

Event page (optional)
My Event

Article list
Sun
Moon
House

This is my suggestion for the new DB schema to store the worklists data cc: @Iflorez.

In T356508#9848556, @ifried wrote:

Thank you for this explanation, @cmelo! I agree that we should go with concept 3. Concept 1 only allows for one wiki, so we should not use it. That leaves concept 2 and concept 3. It seems that concept 3 is more straight-forward and asks for less information in order to accomplish the same goal, so it is the better experience for the user. Also, thank you for explaining how translation would work.

In T356679#9849885, @gonyeahialam wrote:

In T356679#9840479, @ifried wrote:

Hi @cmelo & @gonyeahialam, I have some comments on the placeholders; let me know what you think:

For the invitation and event name titles, I don't think we should include a date, such as "2024," since it will soon seem outdated. Also, although I understand the purpose of writing "Wiki Loves Wiki," it seems like it could confuse people. They may wonder, "What is Wiki Loves Wiki?," if they are unfamiliar with Wiki Loves events or don't know if/how their event needs to be similar to a Wiki Loves event. So perhaps we can have something more generic, such as:

• My Event Invitation List
• My Event

For the article list name, I don't think we should have actual articles listed because that seems to advertise certain articles in the interface. For example, one of the articles has been flagged as having issues on French Wikipedia. I think we should have something more neutral and generic, like:

• Article 1
• Article 2
• Article 3

I have been thinking about this. We are aiming to create a balance between being too specific and too generic. The goal with the placeholder here is to convey the format of the input and an example of the input. For the Article list, Article 1 2 3 convey the format(each on new lines) but doesn't give an example. To not look like we are advertising an article, we can use some generic article titles like Sun, Moon, House. For Invitation list name, we can leave it as My Event Invitation List. For the Event page, the label may already be confusing because it doesn't state what exactly you should input, is it the event name or url. In this case it is actually the Event page title you are inputting which may not be the same as the Event name. Perhaps the placeholder can be use instead to give a hint such as "Enter the title of your event page". In summary my suggestions are:

Invitation list name
My Event Invitation List

Event page (optional)
Enter the title of your event page

Article list
Sun
Moon
House

In T362897#9844377, @Daimona wrote:

In T362897#9841785, @cmelo wrote:

Regarding the use of JSON blobs or structured storage, I think data analysis is something we want, based on what was shared about aggregate analytics, in order to be able to create reports like the ones below that will also be seen by organizers, if I understood correctly:

It's not whether we want these reports or not, but whether JSON makes it more difficult to generate them. To give a concrete example: if the data is pulled from the database and then processed in say a python script, it shouldn't make any difference whether the input data is structured or not, as you can easily decode the JSON in the script itself.

Yes, indeed, it is about whether JSON makes it more difficult to generate them or not.
Given the two scenarios I think we may need, I believe JSON will make it more difficult.

Hi @ifried, We talked about this on our Design > engineering meet, and we mention that option 3 would be the best option to go with, so users can select more than one.

In T362897#9840573, @Daimona wrote:

In T362897#9840362, @cmelo wrote:

• cewa_id: ID links the user to the article of the worklist

Would this be useful? Without an indication of how strong the link is (i.e., how much someone has contributed to a given article), we probably wouldn't want to use this for analytics purposes or anything.

I think this may be useful to get data like:

• Which articles retuned this user
• This user is present in how many articles on my worklist

I get that, but as I was hinting above, I don't think it would be very useful without also storing how strong the user <-> page link is. The simple example is someone who contributed to lots of articles but only made really tiny edits (e.g., copyedits) to all of them. Saying "this person appeared in 123 articles" wouldn't really be significant for statistical purposes I assume.

@Daimona, @MHorsey-WMF The revised db schema would look like below: [...]

Seems OK at first glance, but I would also want to be reassured about the first two things I mentioned in my previous comment (need for structured storage, global vs local) before calling this done.

In T365380#9825193, @gonyeahialam wrote:

@vaughnwalters I think we should have a specific message for blocked users, something like:
You do not have access to view this or You are blocked from viewing this or any other similar messaging used on Wiki for such scenarios.

In T362897#9826911, @Daimona wrote:

I've reviewed the schema again given all the conversations that happened recently, but I still feel like there's a lot I don't know and/or we haven't talked about and that makes it difficult to tell whether something would work.

First of all, I'm still not entirely certain that JSON blobs aren't an option for either the worklists or the user lists. There's no doubt that not using blobs allows for more flexibility going into future iterations, but it also adds complexity. Given the current requirements, it feels like the only reason not to use blobs is data analysis (T362897#9808688), but is this something we're sure of? As in, have we confirmed that JSON blobs would not be compatible with the tooling used to generate these reports (or at least would make it more cumbersome)?

Second, there were conversations about invitation lists being global vs local, but I'm not finding anything on phab and I forgot what the decision was on that. This would need to be documented somewhere, and then the schema may have to be updated accordingly. I'll highlight (some of?) these changes below.

In T362897#9776364, @cmelo wrote:

• ce_worklists:
  • cew_name: varchar(100) worklist name

Might be worth making this longer, in case of events with long names. A standard tinyblob (255 B) would do.

Yes, I agree

• cew_edited_at: timestamp
• cew_deleted_at: timestamp

I agree with you that we need answers to whether these features will ever exist before making a decision on these fields.

Also, if this table will be in the shared database, I assume we'll need to store the wiki where this worklist was created.

• ce_worklists_articles:
  • cewa_article_url: varchar(100) worklist name

Yes, indeed, I will include them

s/worklist/article/? Also, we never store URLs into the database. This should either be a page ID, or two fields for namespace and title; maybe not the namespace if we'll ever only have pages in the mainspace. Additionally, we will need to store the wiki of the article, assuming we will at some point allow external pages. This would be similar to the campaign_events table.

• cewa_created_at: timestamp
• cewa_edited_at: timestamp

What would "create" and "edit" be in this context?

These I added by mistake, they are not needed, I will remove them thanks

• cewa_deleted_at: timestamp

I think hard deletion should be fine here?

Yes, I agree, I don't think we need to restore it not even generate reports on it, I will remove it

• ce_worklists_user_by_article
  • cewuba_username: varchar(100) worklist name

Storing usernames is problematic. Firstly because it adds a lot of redundancy, and MW has been moving in the opposite direction for a few years now with the introduction of the actor table and related fields. Secondarily because usernames are not stable identifiers--people get renamed all the time, and tracking that is possible but cumbersome. We should only store the central user ID, like in other places.

Yes, thanks I added it by mistake, will remove it

• cewa_id: ID links the user to the article of the worklist

Would this be useful? Without an indication of how strong the link is (i.e., how much someone has contributed to a given article), we probably wouldn't want to use this for analytics purposes or anything.

I think this may be useful to get data like:

• Which articles retuned this user
• This user is present in how many articles on my worklist

In T356679#9838830, @gonyeahialam wrote:

In T356679#9836963, @cmelo wrote:

Hi @ifried and @gonyeahialam, there are 2 things that come up on code reviews, that I need your feedback on:

• The default behavior of OOUI is to add * for required fields, and not for optional fields, so it was suggested to remove the word "(optional)" from the sentence below:
  • Event page (optional) this is how it is on the prototype, I agree that for OOUI we should remove the "(optional)" part since this is the default

The design follows the Wikimedia style guide form guidelines for this. If it is a challenge to do it this way then go with the defaults.

• The placeholders are in the design specs only, and not in the AC. Can we confirm whether they should be included, and if their texts have been reviewed?

They should be included. I don't know if @ifried has reviewed them. Here they are for easy reference:

Invitation list name
e.g WIki Loves Wiki 2024 Invitation List

Event page (optional)
e.g WIki Loves Wiki 2024

Article list
e.g
Jean Pliya
Chanceline Mevowanou
Benoît Dato

In T356508#9819198, @ifried wrote:

Thank you, @Astinson!

@cmelo & @Daimona, see comment from Alex above.

Hi @ifried and @gonyeahialam, there are 2 things that come up on code reviews, that I need your feedback on:

The event address is also shown on both event details special page and event details modal on the event page, I think we should also hide them

For the special wikis, I am not sure if we should display them or not. Here is the list of all special wikis returned by the Sitematrix API:

I don't think we should. Or maybe with exceptions. Many of these wikis are not even SUL wikis and wouldn't work in our current setup.

Yes, I agree, we can check with @ifried if we can exclude them all of if there is some exception.

Based on what was shared about aggregate analytics, it sounds that a more structured database is needed in order to be able to create reports like:

• Last year, you organized three events and 10% of the people you invited ended up joining your events
• This year, you organized three events and 20% of the people you invited ended up joining your events

I did a bunch of tests using the Sitematrix API, and other related APIs I found to get the list of wikis, here are my findings:

Recommendations
So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

cc @VPuffetMichel @ifried @MHorsey-WMF @Daimona @cmelo