Note that the help text ("Add the usernames of other organizers to give them permission to manage this event") looks differently in MediaWiki: they are below the field, and in a grey-ish color; see here for an example (you must be logged-in).

Another note: the widget shown in the prototype is a generic TagMultiselectWidget, which is fine when you're dealing with generic data. Here we're dealing with a specific kind of data, i.e., usernames. MediaWiki has its own widget for selecting a list of users, which also has autocompletion, basic validation, and a built-in no-JS fallback.

All in all, this is how it looks like:

Also: the task description does not mention several possibilities that I'm unsure how to handle:

• Should your username be in the list?
• Should you be able to remove yourself? For this question, does it make any difference whether you are the event creator or not?
• If you're not the event creator, should you be able to remove the event creator?

Good questions! I'm not sure yet, but I have written some preliminary ideas below, and I have pinged some other people for feedback.

Should your username be in the list?

It probably makes sense to include your name (as the original organizer). Otherwise, it may be a confusing user experience, since it seems to create a false division between the creator organizer and other organizers, when they are in fact treat equally in the system (at least in V1). In V2, we can revamp this section by perhaps allowing the user to assign different roles to the organizers.

Should you be able to remove yourself? For this question, does it make any difference whether you are the event creator or not?

I think every event should have at least 1 organizer. So perhaps you can only remove yourself if there is more than one organizer. If there is more than one organizer, you can remove yourself. For example, someone may realize they are busy and can no longer be an organizer, so they want the other organizers to take charge instead.

If you're not the event creator, should you be able to remove the event creator?

Not sure about this. Maybe it's safest to start by only allowing event creators to remove themselves? I would want more feedback on this.

Pinging @Astinson and @IBrazal; I would love your thoughts/feedback on the three questions above. Thanks in advance!

In T315577#8208999, @ifried wrote:

Good questions! I'm not sure yet, but I have written some preliminary ideas below, and I have pinged some other people for feedback.

Should your username be in the list?

It probably makes sense to include your name (as the original organizer). Otherwise, it may be a confusing user experience, since it seems to create a false division between the creator organizer and other organizers, when they are in fact treat equally in the system (at least in V1). In V2, we can revamp this section by perhaps allowing the user to assign different roles to the organizers.

I agree, but it's not necessarily a division between the creator and the others. "Your" here refers to whoever is editing the form, it could be the creator or another organizer.

Should you be able to remove yourself? For this question, does it make any difference whether you are the event creator or not?

I think every event should have at least 1 organizer. So perhaps you can only remove yourself if there is more than one organizer. If there is more than one organizer, you can remove yourself. For example, someone may realize they are busy and can no longer be an organizer, so they want the other organizers to take charge instead.

SGTM.

If you're not the event creator, should you be able to remove the event creator?

Not sure about this. Maybe it's safest to start by only allowing event creators to remove themselves? I would want more feedback on this.

Yeah, also: when we start talking about per-event organizer roles, we may want to assign some permissions to the event creator only. Presumably, every event would have to have a creator for that.

Not actively working on this because it seems that we need more feedback.

Talking to @Sadads, and he says:

1. Yes, we would want to show the original event organizer in the list, but we would ideally have some signal or indicator that they are the original event creator.
2. Yes, we should allow organizers to remove themselves. If the primary organizer removes themselves, they should be able to transfer who is the primary organizer. Also, it is okay if we do not have the concept of primary organizer at first pass, but it should eventually be set up (such as when we have organizer roles).
3. No. Event organizers (who are not original/primary organizer) should only be able to remove other non-primary organizers.

@gonyeahialam We will need some way of distinguishing between the original event organizer (i.e., who created the event) and other organizers who were added to the event. Also, it would be great if you could consult with engineers in the engineering + design meeting on the potential user flows of this ticket. Thank you in advance!

For more questions, please reach out to Lauren when I am on PTO.

Two ideas that came up in sprint planning today:

• Non-primary organizers do not see organizer name when clicking 'edit'
• OR primary organizer name is displayed as non-editable text above the section to add/remove organizers for non-primary organizers

I also discussed this with Danny and he agreed with our three choices.

In T315577#8221685, @ifried wrote:

Two ideas that came up in sprint planning today:

• Non-primary organizers do not see organizer name when clicking 'edit'
• OR primary organizer name is displayed as non-editable text above the section to add/remove organizers for non-primary organizers

The second idea sounds better to me.

Yes, I also agree that the second option is better since it gives more information to the user (i.e., who is the primary organizer) and therefore provides more clarity.

Proposed Design
Link to Figma
The component we are using has the property of making an input(username) default/mandatory and uneditable. Notice the x is removed from the first username and it has a different background color.

Creator View: when creator(primary organizer) is the only organizer, Creators can’t remove themselves if they are the only organizers	Creator View: when there are other organizers. Creators can remove themselves if there are other organizers	Other Organizers View. Other organisers can’t remove the creator.

@gonyeahialam If I understand correctly, the 'Creator111' is never editable? Is that correct? Or can it be changed to be editable? Can you provide more background on how this works, since:

a) We want there to be a primary organizer role. Other non-primary organizers cannot remove them.
b) In the future: If there are multiple organizers, we want the primary organizer to be able to remove themselves and then assign someone else as the primary organizer.
c) Ideally, we want it to be clear in the UI *who* is the primary organizer at all times.

Are all of these use cases covered in the example you showed above? For example, how can a primary organizer remove themselves? How can other organizers know who is the primary organizer? Thanks in advance.

In T315577#8279487, @ifried wrote:

@gonyeahialam If I understand correctly, the 'Creator111' is never editable? Is that correct? Or can it be changed to be editable? Can you provide more background on how this works, since:

If my reading of the documentation is correct, we can decide whether an element should be editable before rendering the page, and also later if need be.

a) We want there to be a primary organizer role. Other non-primary organizers cannot remove them.
b) In the future: If there are multiple organizers, we want the primary organizer to be able to remove themselves and then assign someone else as the primary organizer.
c) Ideally, we want it to be clear in the UI *who* is the primary organizer at all times.

Are all of these use cases covered in the example you showed above? For example, how can a primary organizer remove themselves? How can other organizers know who is the primary organizer? Thanks in advance.

I think it would work for a) and b), but not c).

I am in a meeting with @gonyeahialam and @Daan.L, and we have discussed the following:

• For V1, the only extra right that a primary organizer has is to remove themselves (nobody other than they can). If they choose to remove themselves, it is okay if there are other organizers. We do not need someone else assigned as the primary organizer for V1, since that one primary organizer right is just meant to protect the event creator from being kicked out of their event by other organizers.
• In later versions, if we give more rights to the primary organizer, than we will need to look into how we can support assigning the primary organizer role to someone else in the UI.
• If one person is left as the organizer, they can either stay as the organizer or choose to close registration if they no longer want to organize the event.

Overall, based on what we have determined, these designs are probably fine for V1. We just need to take note of the fact that the view will look different for primary organizers since there will be an 'x' next to their username.

In T315577#8283037, @ifried wrote:

I am in a meeting with @gonyeahialam and @Daan.L, and we have discussed the following:

• For V1, the only extra right that a primary organizer has is to remove themselves (nobody other than they can). If they choose to remove themselves, it is okay if there are other organizers. We do not need someone else assigned as the primary organizer for V1, since that one primary organizer right is just meant to protect the event creator from being kicked out of their event by other organizers.

But then there will be events created with V1 that won't have a primary organizer. For such events, any right that is explicitly assigned to the primary organizer won't be assigned to anyone in V2. For instance, let's say that only the primary organizer will be able to change the meeting link in V2. If we allow primary organizers to remove themselves in V1 and someone does that, then nobody will be able to edit the meeting link for that event in V2. I think the constraint of always having at least one primary organizer should be enforced even in V1.

@Daimona Thanks for bringing this up. It makes sense to consider the fact that, while this may work for V1, it could really complicate things in V2 and beyond. I definitely think this is something to discuss in our design + engineering meeting tomorrow. I see a few potential options for us, including:

1. In V1, create a separate and required field for the primary organizer, so if someone wants to remove themselves as the primary organizer, they must explicitly add another username to the field.
2. In V1, allow events without a primary organizer (for the use case of someone removing themselves as the primary organizer). Then, in V2, if and when we have more rights for the primary organizer, we can choose among a few options for how a non-primary organizer can become a primary organizer, such as:
   • Create a field for any of the organizers to add themselves as the primary organizer
   • If there is only one username left as the organizer, they automatically become the primary organizer

If Option 1 is not a large amount of engineering effort, it may be worth it to include it in the 'multiple organizer support' epic. Also, in the future, would it be possible for us to have more than one 'primary organizer,' if we want, at the same time?

In T315577#8284476, @ifried wrote:

@Daimona Thanks for bringing this up. It makes sense to consider the fact that, while this may work for V1, it could really complicate things in V2 and beyond. I definitely think this is something to discuss in our design + engineering meeting tomorrow. I see a few potential options for us, including:

1. In V1, create a separate and required field for the primary organizer, so if someone wants to remove themselves as the primary organizer, they must explicitly add another username to the field.
2. In V1, allow events without a primary organizer (for the use case of someone removing themselves as the primary organizer). Then, in V2, if and when we have more rights for the primary organizer, we can choose among a few options for how a non-primary organizer can become a primary organizer, such as:
   • Create a field for any of the organizers to add themselves as the primary organizer
   • If there is only one username left as the organizer, they automatically become the primary organizer

If Option 1 is not a large amount of engineering effort, it may be worth it to include it in the 'multiple organizer support' epic. Also, in the future, would it be possible for us to have more than one 'primary organizer,' if we want, at the same time?

From the conversations we have had since this comment, I assume we would be going for Option 2 for V1.
For option 2, I have already outlined the design here T315577#8279199. A new update to the design is to add the role of the primary organizer beside their username as shown below

If we decide to go with Option 1 either in V1 or V2

Idea A	Idea B
Notes: This idea appears simple to implement engineering-wise. Some challenges with it include: Users have two fields for similar inputs; More room for errors since users can easily add a username as a primary organizer while that username is still in the secondary organizer field; Users will have to delete a username from the secondary organizer field before adding them to primary	Notes: This idea lets users enter the username once; Easily switch/assign roles using the dropdown(and can accommodate more roles if needed)

A note on role names
The label 'Primary Organizer' appears like a technical term and doesn't really describe the function. I propose we use the word 'Creator' for V1 since we do not have defined roles yet and the only role of the primary organizers is to be event creators. In V2 when we define the roles we can explore more appropriate terms for Primary or Secondary organizer

In T315577#8353192, @gonyeahialam wrote:

From the conversations we have had since this comment, I assume we would be going for Option 2 for V1.
For option 2, I have already outlined the design here T315577#8279199. A new update to the design is to add the role of the primary organizer beside their username as shown below

This doesn't seem possible natively. I think we'd have to either patch the widget upstream, or write some workaround.

A note on role names
The label 'Primary Organizer' appears like a technical term and doesn't really describe the function. I propose we use the word 'Creator' for V1 since we do not have defined roles yet and the only role of the primary organizers is to be event creators. In V2 when we define the roles we can explore more appropriate terms for Primary or Secondary organizer

I agree, but "primary" is not even a technical term; in the code, we already use "creator".

Hi there, I was thinking about the options we have to be able to remove organizers, and also remove the "creator", I think that adding the creator role to another organizer is not the right way to go, because the truth is that even if we say that other organizer is also the creator, he is not, because there is only one creator, and this may be confusing in the future if we want to get the real creator of the event registration (I know we can get this information getting the username that created the event page, but it still sounds weird to me).

That said, my proposal would be:

1. There is only one creator
2. Admin role has the same permissions as a creator, the only thing an admin can not do is to remove the creator.

This way, when the creator removes himself/herself:

• If there is at least one organizer with the admin right (for V1 all organizers would be admins), then we allow the creator to remove himself/herself.
• If there is no other organizers, we do not allow the creator to remove himself/herself.
• Admins can remove other admins, and also himself/herself if there is other organizer with the admin role.
• In V2 when we have more roles, if there is no other organizers with the admin role, then the creator must choose one organizer to assign the admin role to be able to remove himself/herself.

What do you think?

@Daimona , @MHorsey-WMF ,@gonyeahialam, @vaughnwalters, @VPuffetMichel

Discussed with Gregory/Claudio/Val:

• For now we will allow all organizers to do “everything” including removing each other - there will be no logic around different permissions
• If you are the only organizer and are trying to remove yourself, we will include a warning that you need to add another organizer
• Prototype is linked on the epic: https://phabricator.wikimedia.org/T325101

Next steps:

• Gregory has already included the warning noted above in the prototype, but need to decide whether 1) organizer can remove themselves and get the warning, or 2) we prevent them from removing themselves along with the warning. Moving this back to "in progress"

@cmelo when entering a username, can we validate the username as soon as the organizer presses enter?

In T315577#8515957, @gonyeahialam wrote:

@cmelo when entering a username, can we validate the username as soon as the organizer presses enter?

Hi @gonyeahialam, I need to check it, but just to confirm, by validate, you mean check if the username is valid (is a real user)?

In T315577#8516199, @cmelo wrote:

In T315577#8515957, @gonyeahialam wrote:

@cmelo when entering a username, can we validate the username as soon as the organizer presses enter?

Hi @gonyeahialam, I need to check it, but just to confirm, by validate, you mean check if the username is valid (is a real user)?

Yes that's what i meant.