Page MenuHomePhabricator

[EPIC] Display data on event type
Closed, ResolvedPublic

Description

User story:

As an organizer, I want to specify the type of my event, so that people who are interested in that event type can more easily find my event and join it.

As an editor, I want to be able to view event information (on the event page or in the Collaboration List) by event type, so that I can find event types that interest me most to join.

As a Campaigns team member, I want to know the breakdown of event types that use our tools, so we can establish a baseline of event types and then try to work against that baseline to diversify the types of events that use our tools.

As a data/product analyst, I want to know what type of event is being organized, so that I can include this information in my data analysis and reports on organized activity on the wikis.

Background:

We have learned in the last year or so that people are using campaign event registration tools for events beyond campaigns. People use them for monthly meetups and trainings, which are not campaign events. See the related Slack conversation. We are also expanding our focus area so that other forms of collaboration, such as WikiProjects, can use our tools.

In order to provide accurate data, we need a way to differentiate the events so that at the time of reporting the team is able to receive data on events, which is the primary use case and goal of the tool (vs meetups and trainings).

Organizers already try to communicate event type in the titles of their events, so we are giving them a more powerful, data-driven way of doing this.

Many of these event types will map to a larger project/program infrastructure, which will be nested above event type (see T385342) and more specific tasks and goals (see T387045), which will be nested below event type.

We want to allow more than one event type, but we think allowing for 2 event types is sufficient for the MVP. We have run many examples of real events and they all seem to fall between 1-2 event types (doc with examples).

Our current list of event/collaboration types - collaboration type:
  • Contributions
    • Editing event
    • Media upload event
    • Backlog drive
    • Contest
  • Community
    • Workshop
    • Training / seminar
    • Meetup
    • Hackathon
    • Conference
  • Other
    • Other
Notes:
  • We want to encourage people to be accurate and precise when they pick event types, but we also understand that some events cover more than 1 event type. For this reason, we will allow users to pick 2 event types, except for cases when 'Other' is picked (and, such a case, the user can only pick one selection - Other). If we hear feedback that there is an interest in more event types, we may expand it to allow 3, but we want to experiment with 2 event types for now.
  • We can have definitions of each of these types for documentation (on perhaps Meta-Wiki or Mediawiki.org), and there can be links to these definitions in the UI.
  • Organizers already use event types in many of their event names, so this can be something we look into for a reference point
    • You can pull event titles to see how people are already communicating event types as inspiration
  • We will work on event type before event tasks/goals
  • We probably want to allow organizers to select more than one event type, but limit it to perhaps 2 or 3 types
  • I'm debating whether it is useful to have separate categories for 'workshop' and 'training/seminar.' Some events would fall under both, but some would be just one, so I'm inclined to keep them as separate for now.
  • We won't have an event type that is specifically for adding references (such as campaigns like 1Lib1Ref in the MVP, but we can consider it as a category in the future if there is enough interest. For now, 1Lib1Ref could fit under 'Editing event' and could fit under 'Adding references' as the task type in T387045.
  • For people who are doing editing activity as part of a course or academic program, they could choose editing event and/or training/course/seminar.
Out of scope:
  • Task types and associated goals - T387045
  • Judging criteria for contests - T387045
Decisions related to event type:
  • I removed "campaign" as an event type, since I think indicating if something is a part of a larger campaign is in the scope of T385342 - in other words, we are still thinking about the singular, one-off event for this stage of work
  • I removed "content drive," since it closely relates to "editing event." If someone wants to have a "challenge" that is a type of editing event, they can specify the details when we allow task type and goals.
  • I removed "single article collaboration," since it fits under "editing event" and a task type could potentially be single article collaboration
  • I removed "proofread-a-thon" since Proofreading will be a text under task types
  • I removed "data-a-thon" because contributing data is a form of editing, and people can find what they specifically want by searching for Wikidata events or task types such as 'adding wikidata items'
  • I removed "photography walk" since it was too specific. Organizer can choose "meetup or community call" and/or "media upload event," and then they can choose "uploading photos" as a task type

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)

Some questions:

  • In the AC of T386273 I read that the event type field would be mandatory. So, what do we do with existing events? Do they get assigned the "other" type? We can backfill those at the database level, too. I'm asking here because I need to understand where to track this work.
  • I assume that "Contributions" and "Community" are group headers and cannot be selected directly. But then, below, "other" is used as a selectable group header. UX aside, we don't have a component that allows selectable headers (especially not in conjunction with unselectable ones), so this will need to be arranged differently. For example, there could be an "Other" section with just "Other" as an option, or something like that (usual disclaimer that I'm not a designer).
  • Does Other [blank field] mean that users can select "other" and additionally enter free text? I would strongly recommend against that, for the following reasons:
    • UI bloat and missing component: we do have a "select or other" component (for example the expiry field on Special:Block), but that only allows selecting a single predetermined option. The multiple-selection use case is not supported.
    • Usefulness & free text being evil: I don't think there would be much useful data to gather from free text, for the usual reasons why free text is to be avoided unless absolutely necessary. I imagine that collecting stats on "other" would be a largely manual process regardless.
    • Backwards-compatibility: if existing events will get the "other" type, there would be no additional free text anyway.

Some questions:

  • In the AC of T386273 I read that the event type field would be mandatory. So, what do we do with existing events? Do they get assigned the "other" type? We can backfill those at the database level, too. I'm asking here because I need to understand where to track this work.

For old & existing events, let's treat them as 'Other.' However, we should let organizers change the event type at any time, including after the event has ended.

  • I assume that "Contributions" and "Community" are group headers and cannot be selected directly.

Yes, correct.

But then, below, "other" is used as a selectable group header. UX aside, we don't have a component that allows selectable headers (especially not in conjunction with unselectable ones), so this will need to be arranged differently. For example, there could be an "Other" section with just "Other" as an option, or something like that (usual disclaimer that I'm not a designer).

Yes, other section with other as an option also works. Kinda awkward, and maybe we can rework some of the wording so it doesn't feel redundant, but I hear you about not selecting the header.

  • Does Other [blank field] mean that users can select "other" and additionally enter free text? I would strongly recommend against that, for the following reasons:
    • UI bloat and missing component: we do have a "select or other" component (for example the expiry field on Special:Block), but that only allows selecting a single predetermined option. The multiple-selection use case is not supported.
    • Usefulness & free text being evil: I don't think there would be much useful data to gather from free text, for the usual reasons why free text is to be avoided unless absolutely necessary. I imagine that collecting stats on "other" would be a largely manual process regardless.
    • Backwards-compatibility: if existing events will get the "other" type, there would be no additional free text anyway.

Yeah, your concerns make sense. I was thinking we could allow a free text response so we could learn about what is missing. BUT I also wasn't 100% convinced this was a good idea because of all of the issues you mentioned. Additionally, I was worried that if we had a free text field, people would be incentivized to use that instead of the other options, since they may think, "Oh, my event is mostly a workshop, but I also think it is kinda different, so I will just make up my own event type." Then, we have lots of kinda useless data, which we actually encouraged or at least supported within the UI. So, yup, I will remove the free text field from the AC.

This also brings up the question of whether we use "Other" as a searchable event type in the Collaboration List. I guess yes? Perhaps it could help people find all of the other stuff that doesn't fit under strict definitions, rather than having that stuff invisible entirely.

Some questions:

  • In the AC of T386273 I read that the event type field would be mandatory. So, what do we do with existing events? Do they get assigned the "other" type? We can backfill those at the database level, too. I'm asking here because I need to understand where to track this work.

For old & existing events, let's treat them as 'Other.' However, we should let organizers change the event type at any time, including after the event has ended.

Of course. I filed T387495 for the backfill.

Yes, other section with other as an option also works. Kinda awkward, and maybe we can rework some of the wording so it doesn't feel redundant, but I hear you about not selecting the header.

Yeah, it is awkward, but I don't think we have much choice unfortunately.

I was worried that if we had a free text field, people would be incentivized to use that instead of the other options, since they may think, "Oh, my event is mostly a workshop, but I also think it is kinda different, so I will just make up my own event type."

Right, I shared the same concerns but forgot to mention it in my previous comment!

This also brings up the question of whether we use "Other" as a searchable event type in the Collaboration List. I guess yes? Perhaps it could help people find all of the other stuff that doesn't fit under strict definitions, rather than having that stuff invisible entirely.

Yep, I think it makes sense to make it searchable (i.e. treat it like the others). It would also be useful in figuring out what kind of events fall under the "other" category.

Thank you for the responses, @Daimona!

BTW, one other way to handle the awkwardness of 'Other' having a section header and a selectable option is to remove all of the section headers entirely. However, I do like the separation of the events into 'contributions' and 'community' because it makes the long-ish list of options less overwhelming and helps provide some clarity in what the events mean, so I'm inclined to keep the section headers. Just throwing this out there, in case other folks disagree and so I have this thought documented in the ticket as well.

BTW, one other way to handle the awkwardness of 'Other' having a section header and a selectable option is to remove all of the section headers entirely. However, I do like the separation of the events into 'contributions' and 'community' because it makes the long-ish list of options less overwhelming and helps provide some clarity in what the events mean, so I'm inclined to keep the section headers. Just throwing this out there, in case other folks disagree and so I have this thought documented in the ticket as well.

I like section headers, so I'd be for keeping them.

One more thing about "other" though: reading the current AC for the subtasks, it's not entirely clear to me whether organizers would be allowed to pick both "other" and something else for the same event. I can see valid arguments for both sides. But I think it's important to clarify this aspect because:

  • If "other" cannot co-exist with other types, we need to rethink the selector UI (I don't think there's a way to do the "select at most 3 items, EXCEPT you select 'other', in which case you can't select anything else").
  • T386278 for example says And the organizer [...] has not selected "Other"; other tasks have similar clauses. The wording is ambiguous if "other" can be chosen along with other types.

One more thing about "other" though: reading the current AC for the subtasks, it's not entirely clear to me whether organizers would be allowed to pick both "other" and something else for the same event. I can see valid arguments for both sides.

@Daimona, Hmmm, good question.

Yes, I think 'Other' can be one of the 3 selected types. The pro is that it doesn't create a confusing user experience (i..e, "Wait, why can't I pick other in some cases, but not in others?") and it allows organizers more flexibility in how they define and describe their events. The main con I see is that it dilutes the potential usefulness of 'Other' as a search category in the Collaboration List, but I already find the category to be not particularly useful, so I think that should be fine.

We can also revisit this decision with some other stakeholders too when we come back to this epic, which is currently on hold.

BUT this also does make me wonder if it is better to have a limit of 2 event types rather than 3. @Astinson and I discussed that 2 should really cover nearly all use cases, and allowing a third may incentivize people to pick 'Other' as a third because... why not?

Hello
I had created a list a long time ago in discussion with the community to establish that event deserves to be admitted for announcements in arWp's local central notice.
the list thus consisted of 43 types of events

  1. Hackathon / Editathon
  2. Writing Contest
  3. Translation Drive
  4. Translation Sprint
  5. Datathon
  6. Niche Content Drive
  7. Article Review Campaign
  8. Peer Review Initiative
  9. Content Moderation Campaign
  10. Photowalk
  11. Photo Contest
  12. Historical Documentation Initiative
  13. Educational Video Production
  14. Thematic Campaign
  15. Content Promotion
  16. Documentation Project
  17. Conference
  18. Community Meetup
  19. Community Meeting
  20. Cross-Community Engagement
  21. Cross-Wiki Collaboration
  22. Celebration/Commemoration
  23. Community Celebration
  24. GLAM Event
  25. Collaborative Project
  26. Wikimedia Conference
  27. Outreach Event
  28. Office Hours
  29. Environmental Campaign
  30. Campaigns
  31. Academic Collaboration
  32. Education Program
  33. Volunteering
  34. Research/Survey
  35. Awareness Campaign
  36. Diversity & Inclusion Initiative
  37. Privacy & Security Awareness
  38. Workshop/Meetup
  39. Advanced Editing Workshop
  40. Train-the-Trainer Workshop
  41. Capacity Building Workshop
  42. Strategy Meeting
  43. Advocacy & Policy Event

I tried to categorize them and came back to a classification by
event category there are 3

  1. community events
  2. contribution events
  3. and capacity-building events

Having said that, I realized that the list of 43 was too long.
I used several methods to try and reduce the list
and we ended up with a list of 5 main categories

  1. Editing & Writing: Hackathon, Editathon, Writing Contest, Translation Drive, Translation Sprint, Datathon, Niche Content Drive
  2. Review & Moderation: Article Review Campaign, Peer Review Initiative, Content Moderation Campaign
  3. Medias & Documentation: Photowalk, Photo Contest, Historical Documentation Initiative, Documentation Project, Video Production
  4. Community & Events: Community Meetup, Cross-Community Engagement, Cross-Wiki Collaboration, Celebration/Commemoration, GLAM Event, Wikimedia Conference, Outreach Event, Office Hours
  5. Workshops & Training: Advanced Editing Workshop, Train-the-Trainer Workshop, Capacity Building Workshop
  6. Advocacy & Awareness: Environmental Campaign, Diversity & Inclusion Initiative, Privacy & Security Awareness, Advocacy & Policy Event

This retains the main ideas while making it easier to read and navigate. Let me know if you'd like to make any further adjustments!
apart from clarity and ease of memorization, I'm introducing community-related events, and separating capacity-building events from the others.

This is so helpful. Thank you, @Bachounda! What is the difference between a community event and capacity-building event?

@ifried
Community event: All events, from organisers to participants including like : Meetup, Cross-Community Engagement, Cross-Wiki Collaboration, Celebration/Commemoration, GLAM Event, Wikimedia Conference, Outreach Event, Office Hours

Capacity building event: all events from organisers to organisers - UG members, newcomers to the user group etc. staff - all Advocacy & Awareness and Workshops & Training

Thank you for this wonderful list, @Bachounda! It could be a useful exercise to see if all of the event types you listed could fit under the list that I created in the task description -- and, if you think a selection of 3 event types would be enough to describe each of these events. Maybe we can talk about that as a task for you in a future ambassador check-in :)

Yes, of course -@ifried I don't limit events to 3 categories, I divide them into 3, which gives a clear idea of the events and what they are for - categorization can take several approaches, not only that, but what I can tell you is that you still have to decide which approach would be the most effective and easiest for the community.

ifried updated the task description. (Show Details)

Thank you so much for sharing this thorough breakdown and explanation, @Bachounda!

The options here would be to leave it as Other - Other or change the heading label as mentioned above. Some heading suggestions are: Other options, Additional options or Miscellaneous.

Screenshot 2025-03-28 at 6.46.13 PM.png (808×1 px, 88 KB)
Screenshot 2025-03-28 at 6.46.49 PM.png (1×1 px, 130 KB)

thanks all for opening up a discussion here. trying to digest the conversation, please feel free to let me know if there's anything I am missing:

→ considerations on how to visually represent the 'Other' category ('Other' header + 'Other' item, etc.)
→ up to 2 event types can be selected normally, BUT if 'Other' is selected, it must be the only selection: so 'Other' has a special behavior that breaks the pattern of multi-selection.

on the first point, some of the suggestions that cross my mind are:

  • as it was mentioned previously, having an 'Other' header with 'Other' as an option, but this can feel redundant and unclear.

menu-other-header.png (486×304 px, 31 KB)

  • I wonder how it would work if we have the 'Other' option alone, with no header. we can use a stroke/border to separate it. and we would be avoiding the awkward 'other' header + 'other' item repetition. we can have borders for the 'Contribution' and 'Community' headers as well to keep it visually consistent and also make the differentiation clear.

menu-other-stroke.png (486×304 px, 31 KB)

on the second point: I think only text can explain why the 'Other' option behaves differently (i.e permitting a single selection only). maybe we can have a description explaining that it can't be combined with other options?

copy can be:

This option cannot be combined with others.

or...

Selecting ‘Other’ means you cannot select any additional event types.

or something else :)

menu-other-stroke-description.png (526×304 px, 35 KB)

I am happy to hear any thoughts about this and/or schedule a meeting to go over this in case we see it necessary! thanks again for the discussion here.

on the first point, some of the suggestions that cross my mind are:

  • as it was mentioned previously, having an 'Other' header with 'Other' as an option, but this can feel redundant and unclear.

menu-other-header.png (486×304 px, 31 KB)

I agree that the redundancy of the header + event type name is not ideal. Seems redundant and a bit confusing.

  • I wonder how it would work if we have the 'Other' option alone, with no header. we can use a stroke/border to separate it. and we would be avoiding the awkward 'other' header + 'other' item repetition. we can have borders for the 'Contribution' and 'Community' headers as well to keep it visually consistent and also make the differentiation clear.

menu-other-stroke.png (486×304 px, 31 KB)

This is better, I think! More clear and it seems to have a visual cue that it is truly "Other" or less important. I like the idea of showing that "Other" is not the ideal choice for people (more like a last resort).

on the second point: I think only text can explain why the 'Other' option behaves differently (i.e permitting a single selection only). maybe we can have a description explaining that it can't be combined with other options?

copy can be:

This option cannot be combined with others.

or...

Selecting ‘Other’ means you cannot select any additional event types.

or something else :)

menu-other-stroke-description.png (526×304 px, 35 KB)

As I look them over, I feel like this last option is the most clear, since it clearly separates the "Other" and lets users know "This option cannot be combined with others." It is not only the most clear (to me), but it also most aligned with the behavior we want to encourage (i.e., we want Other to be the last resort option that most people do not choose). However, I do not know how much more technically complex it is to implement it this way. I would be interested in hearing the feedback from others!

Thank you for sharing these designs + ideas, @JFernandez-WMF!

Interested in engineering perspective - are all of these options equally doable, more or less? Are any of you particularly drawn to any of the options? @cmelo @Daimona @MHorsey-WMF

Thanks @JFernandez-WMF, I agree with @ifried, that the last option is the most clear, although I don't think there is a component that works like what we are planning.

So if we decide to do it this way, it means we will need to implement some customization to allow the behavior where, if the "other" option is selected, then the other options cannot be selected and should be deselected if the user had selected them before, which means that this will be a little bit more complex to do (but this is the same for the 3 options).

Thanks, @cmelo! How much more time/effort would it take to do option 3, as opposed to other options (roughly speaking)? It is my first choice, unless it would significantly complicate things. My hope is that we pick a solution that is not too complex to implement.

I have some new suggestions after discussing with other designers - see below:

  • When the user selects an event, the 'Other' option is disabled.

events-selected-other-disabled.png (455×304 px, 30 KB)

or/and,

  • When the user selects 'Other', all of the other event types get disabled.

other-selected-events-disabled.png (451×304 px, 30 KB)

I think these two options can work since 'the system' 'blocks' the selection for you, instead of the users having to reason by themselves, but it can make the UI feel a little jumpy, since options are suddenly being grayed out.

Another suggestion that came up was no headers, and items ordered alphabetically.
— This is a simpler structure and maybe easier for the user to scan an understand, especially if the list is not very long. However, if long-term we want to add more event types, this may not be the best option since it is not very scalable in that sense.
— We can also explain the 'Other' behavior in the field's helper text - where we already mention the max allowed for event types.

no-headers-alphabetical-order.png (418×304 px, 29 KB)

I think it'd be great if we could quickly test this with users to see how all of the options feel: do users prefer a 'static' list? Or do they appreciate the disabling interaction? How well do they understand the 'Other' rule? And we can start assessing feasibility. How does that sound?