Wow, I am finally getting the time to review this investigation in detail. Thank you for your patience, @Daimona! It was sitting in my "to-do" list since we had no immediate plans to work on it, but this work is important, so I'm glad that I have carved out some time to review it in detail. I also see this work as increasingly important as we think about new ways to broaden and diversify our user base.

In T377029#10260998, @Daimona wrote:

There are two parts to this: setting (adding/updating/removing) an image, and using it; I'll discuss these separately.

Setting images

For starters, I'm going to assume that "This image would live in Commons" should actually be read as "This image would be a normal file available in the File: namespace", which includes Commons but also local files.

Yes, thank you for clarifying!

From the user's perspective, there would have to be a new field in the registration form (Special:EnableEventRegistration and Special:EditEventRegistration; plus the API) to specify the image. The exact design could be determined later, but a simple TitleInputWidget restricted to the File: namespace would probably do. We could pair this with a preview of the selected image.

The next question is how to store images in the backend. There's an easy way to do this that immediately comes to mind. We could add a new column to the campaign_events table, connect it to the input field, and voilà. Organizers can set an image. While this might be the simplest approach, it also has shortcomings, in that it does nothing to reuse the existing infrastructure. The main consequence of this is that there'd be no way to see if a given image is used for any events, e.g. via Special:WhatLinksHere or Special:GlobalUsage. In fact, the image might appear to be completely unused, if its only usages are from the registration form. In general, this problem is hard to solve unless we add the restriction that the event image must also be present in the event page (or a related page as below). Both WhatLinksHere and GlobalUsage expect each usage to be from a normal wikipage, and rightly so; it's us not following https://www.mediawiki.org/wiki/Everything_is_a_wiki_page, and not them (T322657 / MCR vibes here). So, I went on to see what we could do if the image is embedded in some wikipage.

Thanks for pointing out the shortcomings with this first approach. I agree that it would be better if images can be easily linked back to events, and if there are no straight-forward ways to do this with the first approach, then it is reasonable to look into an embeddable approach.

The first, really simple approach that comes to mind is to use a subpage of the event page. It would work something like this:

• We define the name for a subpage of the event page that will contain the image; for example, /Image.
• The page itself would be a perfectly normal page. When the page is viewed (whether it exists or not), there is a brief paragraph that explains its purpose (compare with site configuration pages like common.css or community config settings).
• The input field in the registration form works the same as above, but instead of saving the image into the database, it edits the image subpage. The new content of the page would be just the image itself ([[File:XYZ.png]]).
• Users could still edit the subpage manually if they so wish. Like for community configuration, we could add a link next to the edit link that takes you to the registration form.
  • Manual edits would go through an extra validation step to make sure that the page contains an image and nothing else. Or maybe just that it contains an image (and we could allow adding other things such as explanatory text, or using templates for choosing the image, or whatnot).

Clearly, there are lots of things that we could do differently (e.g., instead of using a fixed subpage name, it's the user who enters the subpage name), but the general idea is the same. The big advantage of this approach is that it complies with "Everything is a wiki page", and it provides all the advantages of using a wikipage (history, watchlist, etc). A disadvantage is that at the end of the day we'd have parts of the event metadata stored in a dedicated table, and other parts stored as wiki pages. We also need to consider the different restrictions that would apply to the subpage (e.g., everyone can edit it as with all wikipages).

The subpage approach sounds better. There's some trickiness in the fact that it's a wiki page -- I don't think everyone should be allowed to edit it. I think it should be protected and only editable by event organizers. Otherwise, imagine the kind of mess that people could create to an event that they didn't like/didn't agree with , just by changing to a different image.

As yet another alternative, I looked into embedding the image directly inside the event page. Regardless of the specific approach, this already has an important consequence: it would likely be hard to add/change/remove the image using the registration form; since the image happens to be in the middle of unrelated wikitext, that'd become a non-trivial parsing task at the very least. Leaving that aside for a moment, I wondered how this might work exactly. First, I looked into the PageImages extension. However, that does not allow users (or other extensions) to specify what image to use, it just picks the one it thinks is best; and that doesn't necessarily correspond to the image that the organizer would like to use to represent the event. Next I thought about using a custom parser function or tag. That might work, and allow us to store the image as a page property when you use e.g. {{#eventimage:Event pic 123.png}}. The main drawback is that parser functions/tags may not be the most intuitive thing for non-technical users, and if we also don't have a way to edit the associated image from the registration form, this might be particularly problematic. Overall, this option also has the same advantages and disadvantages as the subpage option.

Thanks for sharing this approach as well! I do have some concern about not being able to easily add an image. Would someone need to add in the image via wikitext in this approach? My thinking is that, if it's not user-friendly,, then we risk low adoption of a new feature.

Overall, I would strongly recommend choosing an option where the image is embedded on a wikipage. The subpage route might be the simplest, at least for the time being, and we could perhaps discuss it in detail to come up with a refined user flow. For the longer term though, this is another instance where we would benefit from using MCR.

Good to know! I agree that the subpage approach sounds to be the best, of the options of we have. But, yup, MCR would be beneficial in this scenario as well.

Using images

When it comes to using the image, the storage shouldn't make much of a difference. In particular:

• On the Collaboration List
  • This would be per each event (that has an image) in the Events tab
• Promotion of Collaboration List
  • As bottom header to the event page

No specific concerns.

• As a new module in the Newcomer Homepage or expansion of the existing Community Updates module (note: this probably needs feedback from Growth, but we can see if anything pops up in our investigation)

No idea about that, but no specific concerns for the time being.

• Emails
  • Confirmation emails after someone joins an event
  • Emails sent by organizers

Doable, but do keep in mind that this will only work for users who choose to receive HTML emails (no big deal, for everyone else we would just fall back to the email with no image).

• Event registration process
  • Login/account creation page for logged out users upon trying to register for event

This was last discussed in T300748. Things have changed since then. We now have the SpecialCreateAccountBenefits hook that allows us to replace the benefits section ("Wikipedia is made by people like you" etc.) with whatever we want, including an image.

For all the use cases above, I see two main risks. First, the image size. We may need to use different sizes / aspect ratios in different places. So, certain images might work better than others (both in general and for specific locations). I don't think there's much we can do about it, except for clipping the image as needed, and possibly recommending what size / aspect ratio would be best.

Yes, I was thinking we could provide some guidance on size/aspect ratio. Clipping as needed would also be nice, if people don't feel like making those adjustments.

Second, the license. Allowing non-free images would be inadvisable because of whatever specific requirements the image license might have; I also imagine (but {{cn}}) it wouldn't be too common for organizers to use a non-free image for their events. On the other hand, even if we only allow free images, restrictions might still apply. This is similar to the point I raised in T372637#10070104, in that we might have to provide an explicit link to the file page. This should be easy enough to do in all of the proposed places (considering that the event list is not using Codex cards, unlike for WikiProjects).

Ideally, we would not be responsible for handling licensing. I was thinking that the image would be added through the Commons uploader or another wiki process that handles licensing -- and, yes, it makes sense for it to be license-free or to be an image that they own the rights to.

As a final note: there are a few aspects mentioned above that might need more thought, some of the options should also be investigated more thoroughly, and I might have missed some (dis)advantages. However, I've already spent some time on this (with many interruptions) and I'm posting it as-is because I want to get the ball rolling :)

Yes! This is a fantastic start. As next steps, I have created an epic for this work (T385924), and I'm including a link to this ticket in the description. We have no immediate plans to work on this, but I would like to work on this at some point. For example, I think it could make both the Collaboration List and an embeddable version of the Collaboration List to be more appealing to users.

Thank you for this work!

Note that I am marking this work as Done, but people can of course add extra comments/responses to what I wrote if they want.