Thanks, @gonyeahialam!

One thing I noticed is that it is not clear that the user needs to scroll down to see the other questions, so I would make the scroll visible when needed.

In T322332#8436417, @cmelo wrote:

Thanks, @gonyeahialam!

One thing I noticed is that it is not clear that the user needs to scroll down to see the other questions, so I would make the scroll visible when needed.

Okay great.

In T322332#8436417, @cmelo wrote:

One thing I noticed is that it is not clear that the user needs to scroll down to see the other questions, so I would make the scroll visible when needed.

Noting that OOUI dialogs have visible scrollbars by default, so we should be fine. With that being said, here are some things that came to mind:

• I don't understand what "sector" is for
• There are some technical aspects related to storing the data that we will need to think about, things like free-text fields (gender, topics, reason why joining) and the "location" field, but I'm sure we're gonna have an engineer-y discussion about those at some point
• The wording on the "skill level" field could be changed: first, I'm not sure about the expression "wiki skill"; I see it used in some places, but it looks like some kind of jargon to me. Second, "wiki" should not be used as an abbreviation like in the label for the "zero experience" field. The word "wiki" is a bit overloaded around here [1], and the label should clarify what it's talking about.
• The question about chapters is also quite challenging to implement, because how do we build a list of chapters? This is also a Wikimedia-specific thing, so maybe it should not be in the extension itself, but rather specified separately via WikimediaMessages or something.
• The combination of widgets used for the chapter field (select + radio) doesn't seem to be a standard OOUI thing. Could "no organization" be the first option in the dropdown instead?

[1] - It could mean Wikipedia, Wikisource, one of the other Wikimedia projects, or a specific project in a certain language, or the underlying technology, and most likely other things (though not all of them would make sense in this context).

Oh, and also: the language selector might be a bit different than that. See https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector

@Daimona

• I don't understand what "sector" is for

Sector refers to the field in which the participant works. We are looking at using either profession or sector but it seems it would be easier to create a dropdown list of sectors than one that covers all professions.

• The wording on the "skill level" field could be changed: first, I'm not sure about the expression "wiki skill"; I see it used in some places, but it looks like some kind of jargon to me. Second, "wiki" should not be used as an abbreviation like in the label for the "zero experience" field. The word "wiki" is a bit overloaded around here [1], and the label should clarify what it's talking about.

Would look into this.

• The question about chapters is also quite challenging to implement, because how do we build a list of chapters? This is also a Wikimedia-specific thing, so maybe it should not be in the extension itself, but rather specified separately via WikimediaMessages or something.

We have a list of affiliates here https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal

• The combination of widgets used for the chapter field (select + radio) doesn't seem to be a standard OOUI thing. Could "no organization" be the first option in the dropdown instead?

This is not a dropdown list but TagMultiselect, so participants can select more than one organizations that they belong to. I don't think this idea would work with this component

Hey @gonyeahialam , the Global Data & Insights team (GDI) has recommended that we use the age ranges in the Community Insights Survey, so I've updated the acceptance criteria.

A few questions for you:

• Should we match the question copy as well? e.g., instead of "Age:" we would have "What is your age?"
• We should probably match the gender question to the Community Insights Survey as well, what do you think?:
  • Which of these categories describe your gender identity? Select all that apply.
    • Man
    • Woman
    • Transgender
    • Non-binary
    • Genderqueer
    • An identity not listed here (please state) - open text
    • I prefer not to say
• Are we going with "Sector" instead of "Profession"? And what are the list options?
• For "Do you belong to any Wikimedia chapters, organizing partners or affiliate organizations?", it looks like we are providing some kind of selection feature for picking from a list. From where are we pulling that list? I want to include in the acceptance criteria.

Thanks!

cc @Pginer-WMF in case you know of additional precedent here.

@gonyeahialam @cmelo it sounds like there are some concerns around allowing multiple selections for "what is your gender?" Are you recommending that we make these answers radio buttons, so that only one choice is permitted? If so, I will bring this recommendation to Legal/T&S for approval.

Of the remaining open questions from T322332#8561172, here's where we are as I understand it, please confirm:

• "Do you belong to any Wikimedia chapters, organizing partners or affiliate organizations?" - we are NOT building a list for participant to select from; we will make it a open text field.

What do you recommend for this one @gonyeahialam?:

• Are we going with "Sector" instead of "Profession"? And what are the list options?

Summary of design and eng meeting:

Open questions:

• Text to explain how pii data will be used: we need to ask Legal to provide guidance on what to display at the top of the form. ex: this information will only be used by organizers and is optional. (?)

• gender: if we allow for multiple choice, it will be hard to aggregate the data, meaning that the count of non-binary, male, female etc will not add up to the total number of people. We need to ask for advice on this. Do GDI /legal use that field as a multiple choice?

• wiki skill level raised a lot of questions.
  • Imelda suggested renaming it to editing skills level. we agreed that it was not possible to define what beginner/advanced etc mean. It is open to interpretation on the part of the participant.
  • Liam suggested rephrasing it to a higher level "What is your skill level in this topic?" with an open field text. Leaving it open ended for participants.
  • It seems to me that what Liam is proposing is to support organizers ahead of their event.

Hey @gonyeahialam
Can you go over the questions that @ldelench_wmf asked above and also double check the summary above!

related to wiki skill level,

Lauren brought up the precedent in https://meta.wikimedia.org/wiki/Community_Insights/2022_Survey_Questions for this that we should use if possible:

• In what year did you begin contributing to the Wikimedia movement or its projects? (dropdown menu with years)
• In what ways do you participate in the Wikimedia movement? Please check all that apply.

In T322332#8619569, @ldelench_wmf wrote:

@gonyeahialam @cmelo it sounds like there are some concerns around allowing multiple selections for "what is your gender?" Are you recommending that we make these answers radio buttons, so that only one choice is permitted? If so, I will bring this recommendation to Legal/T&S for approval.

@ldelench_wmf @VPuffetMichel My concerns around gender are:

• What is the rationale for using multiple choice?
• As stated by @VPuffetMichel

gender: if we allow for multiple choice, it will be hard to aggregate the data, meaning that the count of non-binary, male, female etc will not add up to the total number of people.

• • Would this style of collecting this data be helpful to organizers?
• GDI also recommended we localize the gender question/options as stated in this document. This was their reason:

What do you mean by localizing gender options?
YML: The way we ask for gender identity is different in different locations. For some locations, you don’t ask for transgender status at all due to the security risks. We do not ask about sexuality in most places.

• "Do you belong to any Wikimedia chapters, organizing partners or affiliate organizations?" - we are NOT building a list for participant to select from; we will make it a open text field.

Yes we can go with an open text field @ldelench_wmf

What do you recommend for this one @gonyeahialam?:

• Are we going with "Sector" instead of "Profession"? And what are the list options?

The question "What is your profession?" is better suited to capture the information that organizers seek. This question allows them to determine the general expertise of participants and identify topics that may interest them. It can also provide clues about the technical literacy and research skills of participants. In contrast, the question "What is your sector?" may provide limited information and is not necessarily indicative of a participant's skills. Therefore, asking for a participant's profession is more appropriate as it provides more relevant information for tailoring events to meet participant needs.

Thanks @gonyeahialam! I had a couple of thoughts/reactions, perhaps @IBrazal, @Wittylama , or @Astinson can help steer us towards decisions.

For the gender question, it seems we have a few decisions to make:

Whether and how to display the (optional) gender question to participants

1. Display the question for all participants - seems like this is the way to go
   1. Concerns about security risks of participants providing this data in certain regions, but the question is optional for participants to answer, and if the participant is selecting their answer from a list, we can include "I prefer not to say" as an option
2. Ditch the gender question entirely
   1. I'm under the impression this option is not available to us, per the requirement: Organizers, the Wikimedia movement, and the WMF want to collect information on the gender of people who are editing and who are attending campaign events. This way, we can track trends over time related to the gender gap in editorship.
3. Display gender question (or a variant) based on participant location
   1. This would need investigation and is likely out of scope for the MVP

How participants will answer the (optional) gender question

1. Participant may select one option from a list
   1. Not recommended per requirements and GDI consultation
2. Participant may select multiple options from a list
   1. Will be hard to aggregate the data, meaning that the count of non-binary, male, female etc will not add up to the total number of people.
3. Participant may type into an open text field (same approach as "Do you belong to any Wikimedia chapters, organizing partners or affiliate organizations?")
   1. Also harder to clean/aggregate the data

If we're unable to make a decision, perhaps we can solicit feedback from our organizer beta testers?

For the profession question, it makes sense why "profession" would provide more relevant information to organizers than "sector."
Do you envision an open text field for this one @gonyeahialam ? I haven't found a precedent for this in the wikimedia universe yet, but it seems like a dropdown list for all the professions in the world would be very long and unwieldy to maintain.

In T322332#8635335, @ldelench_wmf wrote:

---

For the profession question, it makes sense why "profession" would provide more relevant information to organizers than "sector."
Do you envision an open text field for this one @gonyeahialam ? I haven't found a precedent for this in the wikimedia universe yet, but it seems like a dropdown list for all the professions in the world would be very long and unwieldy to maintain.

I believe there are lists for this online that we can copy or related APIs cc @cmelo

Anything that requires typing in open text fields would make analysis more difficult for organizers.

I am confused by the distinction between "prefer not to say" and simply not replying to the question at all - do we treat these pieces of data differently? or, do we consider both to be a null response?

Because, by the fact of a "prefer not to say" option being available, it makes me assume that I DO HAVE to answer the question, and that we've provided this option as a way to avoid having to answer.
I would suggest we remove the "prefer not to say option in any/all of the questions where it is used - and make the fact that the questions are ALL optional more obvious (for example by adding " [optional] "after every question.
The fact of having "prefer not to say" on SOME of the questions implies that the others ARE mandatory.

IF that were done, then I would be happy to chose option 1 (display question to all participants) and input choice 1 (participants may select one option - or none at all).

I believe that the options of 'male, female, other [freetext]' is standard and best-practice, but do we have any kind of confirmation of that e.g. by asking the DEI team for a double-check of this format?

I believe that the standard to include "male, female, non-binary, and other" with an option not to be able to participate. @JStephenson may have more insight on how its being used now.

We really need to collect gender for the reason that Community Insights survey needs to collect gender: a bit theory/signal from most affiliates is that gender diversity is driven in large part by outreach activities -- and that women are more likely to participate in this events.

A. Wikimedia chapters, organizing partners or affiliate organizations

Of the remaining open questions from T322332#8561172, here's where we are as I understand it, please confirm:

• "Do you belong to any Wikimedia chapters, organizing partners or affiliate organizations?" - we are NOT building a list for participant to select from; we will make it a open text field.

I recommend using an already created list(s) of affiliates, organizing partners, chapters, as @gonyeahialam noted in this earlier comment https://phabricator.wikimedia.org/T322332#8447815, along with an open text field. A drop down list with preselected options would allow us to aggregate data and make it useful across departments. An open text field would allow persons to enter in the names of unofficial groups etc..

For example, could we have a drop down list(s) of preselected options including an option for "Other" which if selected allows persons to fill in a free text field? And could these preselected option lists grow over time and eventually live in Hive? Our canonical tables do this for country and wiki data and it's helpful for many use cases.

@JAnstee_WMF do you have a suggestion for a reliable list of affiliates and/or chapters that we can use? As far as affiliates, could we use the list of affiliates here https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal ?
@Astinson do you have a suggestion for a list of organizing partners?

B. "Profession"
As I understand, the main impetus for this item is to gather for organizers: a) participant's wiki skill level or competency level, b) a sense of the topics that a participant might be interested in and c) a sense of the tech capacity and needs of participants.
Alternate options could provide the same insights while providing the option to leverage the data (aggregate and share across departments) and ultimately giving organizers more (time saving) options.

1. wiki skill level or competency level

i. note that we are already asking a question specific to skill level
ii. we can/will identify if a participant is a new campaign editor or a returning editor
ii. we can identify participant's edit counts and set those to buckets/categories for easier reading and privacy protection
iii. we can identify types of returning editors based on previous per month edit counts
iv. note, I recall Ilana noting that "profession" would be a self reported open text field. We discussed the difficulty of aggregating this data if it were an open text field as part of discussions for T320289. Instead of profession I had suggested using education level as it might be a field for which Grants or GDI already had an assembled list of answer options.

2. topics

i. We've addressed using the topic model as a base list of options that persons can use to select their topic preferences. Would it be helpful to return to that option and the conversations in that email thread [ORES taxonomy for gathering participants' topics of interest]? With ORES data selections, for example, organizers could query by subjects to improve their worklists. I understand that there are long-term ORES taxonomy plans which will/could include further geographic breakdown to the country level which would be very helpful for campaigns. @Isaac
may be able to shed more light. Further, our use of ORES taxonomy (and feedback) could improve the list for use with non-English languages.
ii. Is there an pertinent ML option in build or planning that we should consider?

3. tech capacity and needs

i. note that we already have questions specific to this

In T322332#8636918, @gonyeahialam wrote:

In T322332#8635335, @ldelench_wmf wrote:

---

For the profession question, it makes sense why "profession" would provide more relevant information to organizers than "sector."
Do you envision an open text field for this one @gonyeahialam ? I haven't found a precedent for this in the wikimedia universe yet, but it seems like a dropdown list for all the professions in the world would be very long and unwieldy to maintain.

I believe there are lists for this online that we can copy or related APIs cc @cmelo

Before moving to this option I highly recommend consulting with GDI. We want to take care not to add in bias or concerns due to the lists that we've selected for the options offered. Further, GDI and Grants may have something which may give us similar results and which has already been vetted and tested.
pinging @JAnstee_WMF and @JStephenson

Anything that requires typing in open text fields would make analysis more difficult for organizers.

yes

C. Gender

In T322332#8619569, @ldelench_wmf wrote:

@gonyeahialam @cmelo it sounds like there are some concerns around allowing multiple selections for "what is your gender?" Are you recommending that we make these answers radio buttons, so that only one choice is permitted? If so, I will bring this recommendation to Legal/T&S for approval.

i. Using the gender options listed in the Community Insights Survey as well as the method for selection used in that survey, as noted in previous comment https://phabricator.wikimedia.org/T322332#8561172 makes sense—especially if Grants is using these options. @JStephenson may be able to confirm.
ii. I recall that GDI recommended in our consultation that we localize the options by geo.
iii. I agree that multiple selections will make this data tough to aggregate. That will mean that this data will be most useful to organizers and less to others. As I understand part of why we want to ask this is because we would like to aggregate this data for use across departments in addition to organizer utility...as @Astinson notes above.
iv. I'm concerned about how this sensitive data would be shared with organizers, especially with small numbers involved: T322751 and T329006

In T322332#8635335, @ldelench_wmf wrote:

For the gender question, it seems we have a few decisions to make:

1. Display gender question (or a variant) based on participant location
   1. This would need investigation and is likely out of scope for the MVP

This seems to align with GDI recommendations, though this option does add complexity to the data aggregating

How participants will answer the (optional) gender question

1. Participant may select multiple options from a list
   1. Will be hard to aggregate the data, meaning that the count of non-binary, male, female etc will not add up to the total number of people.

This seems to align with GDI recommendations

In T322332#8619569, @ldelench_wmf wrote:

@gonyeahialam @cmelo it sounds like there are some concerns around allowing multiple selections for "what is your gender?" Are you recommending that we make these answers radio buttons, so that only one choice is permitted? If so, I will bring this recommendation to Legal/T&S for approval.

@ldelench_wmf Please keep me looped in on the Legal/T&S discussion and approval process. I'd like to help in docs and meetings.

FYI: Here are the Event Center Requirements

+ 1 on Affiliate data portal use.

On profession, minimally we need to capture the knowledge professions:
librarian, educator, activist, museum or archive professional, academic or
researcher, non profit professoinal, etc -- there are certain groups that
we build programs for that we should be able to contact on. This could be
an optional one that is very clearly about continued connection: "Would you
be interested in programs offered for one of these sectors?"

We also want to capture topics of interest.

Thanks so much @Iflorez, @Wittylama, and @Astinson for your feedback here! I have some followup questions/comments as I'm updating our knowns/unknowns for next week's discussion/decision-making convo:

• @Iflorez appreciate your point about thresholds for aggregating and disaggregating data, and showing the data to organizers in general; I think we should get into deeper discovery on T328797, T329006 as a next step after we make decisions about the questions/answers themselves.
• We discussed that localizing the question/answer options would be out-of-scope for the MVP.
• @Sadads we had planned only the 5 questions in the description for the mvp, but sounds like topics of interest is a hard requirement for this first iteration? I don't think that should be too difficult since we can likely pull from the ORES taxonomy for the mvp, but will check with the team. cc @cmelo @gonyeahialam @VPuffetMichel
  • Previous guidance from @Isaac on this: the ORES taxonomy is derived from a community-built directory of WikiProjects so it should be relatively aligned with many of the topics that editors collaborate on. When checking if the taxonomy is appropriate, I'd pay special attention to non-English campaigns because the WikiProject directory was from English Wikipedia so is less well-tested outside of that community. The nice benefit is that the ORES taxonomy also provides a good hook to then bring campaign participants into Growth's newcomer tasks module which also uses these topics to personalize their recommendations.

@ldelench_wmf topic of interest should come later once we start picking topic domains for events themselves -- we need the topic areas to be configurable in a flexible way -- the ORES taxonomy and the WikiProjects are both highly inaccurate and not useful for newcomers, especially when trying to form multilingual, multicultural cross community activities.

A good example of this is that there are emerging communities of practice on both Human Rights and Sustainability topic areas which are impossible to map to the ORES models, and don't make sense for WikiProjects as a 1:1 especially as we get into broader multi-community activities.

Got it, thanks @Astinson ! I'll remove the "Choose some topics you are interested in editing:" question from our proposal for the MVP, and we can tackle it later. cc @cmelo @VPuffetMichel

Chiming in late but in support of not using the ORES topics for this particular use-case. The ORES topics are most useful as search/list filters because they're standardized (easy to design into interfaces) and my new model makes them available for all Wikipedia languages so we can offer the same functionality to all. They are quite broad as Alex pointed out, but when just being used to narrow down lists of articles that editors are reviewing, that broadness is not such a big deal because editors can easily skip over content that's not relevant to them. Ideally they're also used in an interface that easily lets editors select/unselect them so they can explore the other topic areas (as opposed to stating them at the start and then not easily being able to change them).

If you're trying to elicit interests from users that humans will be looking at (as I think is true for this use-case), I assume that open-text responses are going to be way better.

@cmelo @gonyeahialam @VPuffetMichel I have updated the acceptance criteria based on today's decisions, please take a look and edit as needed.

@gonyeahialam Do you think we should update the designs at this point? Our next steps will be to seek approval from Legal/Trust & Safety, and I'm happy to just share the acceptance criteria to avoid rework if they request changes.

In T322332#8662374, @ldelench_wmf wrote:

@gonyeahialam Do you think we should update the designs at this point? Our next steps will be to seek approval from Legal/Trust & Safety, and I'm happy to just share the acceptance criteria to avoid rework if they request changes.

I have begun working on design updates. I could slow down on it. When do we expect feedback from legal?

According to this guidance they triage requests in 5 working days, but it's unclear to me when the actual review would happen - though in my experience they are pretty fast. If it's reasonably simple to update with our decisions from yesterday, please go ahead - seeing the updated wireframes will probably make their reviews easier.

In T322332#8663991, @ldelench_wmf wrote:

According to this guidance they triage requests in 5 working days, but it's unclear to me when the actual review would happen - though in my experience they are pretty fast. If it's reasonably simple to update with our decisions from yesterday, please go ahead - seeing the updated wireframes will probably make their reviews easier.

Okay, thanks.

We may want to include "which languages do you plan to contribute in?" in that its both technically easy to do (use the language lists from the projects) and will improve the signals that Irene and the P&E dashboard can create in terms of metrics (one of the problems right now is that most of the tracking tools in the movement require prior knowledge of the language someone plans to contribute in). This is unlikely to be common in small events, but international writing contests this is key for tracking.

We may want to change a couple of the professions: Software engineer -> Technology professional, Mass media professional -> Communications or Media Professional and Librarian -- Library professional -- to be consistent and provide the widest possible buckets. Librarian or library worker is the more common scope of these kinds of things globally (because librarian typically implies having a degree in library work and a lot of library workers are not degreed, software engineer is hyper specific and doesn't capture the broader technologist buckets).

Also, as a note, you may run into technical complexity with the youngest bucket in the age groups -- in that it might require us to not collect additional information (working with minors and collecting data about minors is incredibly complicated when working in as many contexts as we do -- in some contexts its illegal to keep collecting data once you know there age).

In T322332#8678239, @Astinson wrote:

We may want to include "which languages do you plan to contribute in?" in that its both technically easy to do (use the language lists from the projects) and will improve the signals that Irene and the P&E dashboard can create in terms of metrics (one of the problems right now is that most of the tracking tools in the movement require prior knowledge of the language someone plans to contribute in). This is unlikely to be common in small events, but international writing contests this is key for tracking.

We may want to change a couple of the professions: Software engineer -> Technology professional, Mass media professional -> Communications or Media Professional and Librarian -- Library professional -- to be consistent and provide the widest possible buckets. Librarian or library worker is the more common scope of these kinds of things globally (because librarian typically implies having a degree in library work and a lot of library workers are not degreed, software engineer is hyper specific and doesn't capture the broader technologist buckets).

Also, as a note, you may run into technical complexity with the youngest bucket in the age groups -- in that it might require us to not collect additional information (working with minors and collecting data about minors is incredibly complicated when working in as many contexts as we do -- in some contexts its illegal to keep collecting data once you know there age).

As far as professions:
@Sadads Are you recommending the following for professions?

• What is your profession? Participants may choose multiple options from the following:
  • Artist/creative professional
  • Educator
  • Librarian -> Library professional
  • Mass media professional -> Communications or Media Professional
  • Museum or archive professional
  • Non-profit professional
  • Researcher
  • Software engineer -> Technology professional
  • Student
  • Profession not listed (participant may optionally add free text)

As far as affiliates:

1. data wise it will be easier to connect events to affiliates instead of participants to affiliates. This is due to the number of affiliates that we'll need to allow folks to select...and also for data quality, to reduce the number of data entry points.
2. In reviewing the affiliate list and in discussing with Liam Wyatt, we find that:

Chapters and user groups are two of the three types of affiliates (the other being thematic organizations). So, unless we need to group by the type of affiliate, then we could simply say “affiliate” and that’s sufficient OR we can say Affiliates (chapters, user groups, thematic organizations).
On the other hand “organizing partner” can be a separate entity.
See also this comment on the Slack #Working-with-data channel

3. How to query for affiliates, to inform an auto fill answer method which allows selection of preselected options, is still an open question. See this task on documenting methods to do so T336598

Thus the following is the tentative proposal:

• Is this event organized in association with Affiliates (chapters, user groups, thematic organizations), organizing partners, or other organizations outside Wikimedia? Participants may choose one option from the following (yes/no):
  • Yes
    • Affiliates (chapters, user groups, thematic organizations)
      • open string field; eventually allow list to choose from
    • Other organizing partners
      • open string field
  • No

@Iflorez +1 to everything you said -- make sense to me.

@Iflorez This question 'Is this event organized in association with Affiliates... ' seems to be phrased as a question for organizers, not participants, It is the organizers that would have the information about their event's affiliations. The previous phrasing was asking participants what affiliates they belong to - 'Do you belong to any Wikimedia chapters...'

In T322332#8959640, @gonyeahialam wrote:

@Iflorez This question 'Is this event organized in association with Affiliates... ' seems to be phrased as a question for organizers, not participants, It is the organizers that would have the information about their event's affiliations. The previous phrasing was asking participants what affiliates they belong to - 'Do you belong to any Wikimedia chapters...'

@gonyeahialam correct. As of April 2023 we are asking organizers about affiliates/partners, not participants. From an event data perspective, this gives us cleaner data by a) reducing the data collection to that affiliate data specifically related to the event in question and by b) allowing us to auto fill or pre-load affiliate names for selection at the time of answering this question (instead of a string open response answer)—asking organizers instead of participants facilitates the data engineering components to allow for T336598 and related work.

Why? When we ask organizers about affiliates that are supporting the event organizing, we could be collecting 5-10 affiliate names or in some cases 20 affiliate names. When we ask participants about their affiliate membership we could be collecting, in some cases, up to 100 affiliate names. Participants might be providing us the names of affiliates that they have joined over an all-time period.

Also, collecting affiliate data from organizers, could later be leveraged for event discovery.

@Htriedman and I were discussing the "What is your age?" answer ranges and were curious if it would be possible to combine the bottom two options to instead be "under 24"? Change illustrated below.

Looking at the Foundation Friendly Space Policy, organizers should still be able to know when some of the Youth Safety provisions apply, because the cited United Nations definition of youth is between ages 15–24.

If the registration process eventually had built-in enforcement of other Youth Safety provisions (like preventing registration unless a parent or legal guardian will attend too, or reminders about other requirements for participants and/or organizers), then it could make sense at that point to allow more granular options than just "under 24." Because the system at present would not distinguish between ages, then widening the answer range to "under 24" could help provide better protection for participants. (pinging @AJones in case you have additional feedback on this)

Hello @MMoss_WMF! Thanks for this update. The team has added these changes to the feature, so that it now says under 24 rather than under 18 (see T341609 for details).

@MMoss_WMF @ifried that should be okay for the MVP. I agree that since we haven't built in controls for participants between 14-24 for the MVP yet, having that broader classification will allow for privacy protection and i am also not overly concerned about child safety because we have a vetted list of organizers for the MVP. We can discuss how to build in these controls for future versions later. I will still recommend (from our previous email thread) to have a reminder statement on the Friendly space policy since that still applies to all under 24 participants.

@AJones Thanks for this comment! Can you clarify what you mean by reminder statement on the Friendly Space Policy? Is what we currently provide sufficient (see screenshot example below), or are you saying that we need to add something else?

yes, i meant what we already have here @ifried

Perfect, thank you, @AJones!

@MMoss_WMF and @AJones: We noticed that it should probably say under 25, since there is currently no option for 24 year olds. Would that be correct?

@ifried: apologies for my mistake! I think I intended something closer to "24 or under" but used the previous age buckets without altering enough. Changing to "under 25" would work!

Great, thanks for this update, @MMoss_WMF! We have updated the AC to be "Under 25" here: T321822. Much appreciated!

@gonyeahialam: This task can be closed, right?

In T322332#9192276, @ifried wrote:

@gonyeahialam: This task can be closed, right?

Since the implementation tickets are closed, we can close this.