Talk:Event Center/Registration

Renamming?

@IBrazal and IFried, shouldn’t this page be moved to Event Center/Registration, given the way “Event Center” is written in the first line of the page? -- Pols12 (talk) 15:20, 5 November 2022 (UTC)

Hi Pols12,
Thank you for noticing this very important detail. The team agreed to move the page to Event Center/Registration instead. Again, Thank you for your continued support.
Best,
Imelda (WMF) ( talk) 14:22, 7 November 2022 (UTC)

Viewing all events

Is there any way to see a list of all events in the Events: namespace created with this extension? This might be a future thing y'all will work on. I'm just being curious. :) Chris Koerner (Wikimedia Foundation) [he/him] (talk) 22:14, 6 February 2023 (UTC)

Hello, @CKoerner (WMF)ǃ Thanks for asking this question. Yes, we are actually already working on this (see T353382), and we hope to have it released in the next few weeks. When it is released, there will be a list of all events that use event registration. In the meantime, you can find all events on Meta-Wiki in the Event namespace via SpecialːAllPages > Event namespace (here's the direct link). Thank you againǃ IFried (WMF) (talk) 17:02, 27 February 2024 (UTC)

Yay! Thanks for getting back to me. :) Chris Koerner (Wikimedia Foundation) [he/him] (talk) 18:23, 27 February 2024 (UTC)

How does the tool work on a translated page?

I'm translating the Event:¡Alto! Mujeres haciendo historia/es to portuguese and noticed that the banner does not work on traslated pages. Is there a way to overcome this? We are organizing a multilingual campaign, it would be important to centralize the registrations (instead of creating another page in Portuguese). ❋ CalliandraDysantha (✉︎) 21:14, 26 February 2024 (UTC)

Hello, @CalliandraDysanthaǃ Thank you for bringing up this question. Right now, an organizer can enable a separate event registration for each translated subpage, but you cannot yet use the same event registration header for all translated subpages. However, we know that this is an issue for organizers, so the team is currently discussing how to do this in the scope of T357716, and we hope to begin the engineering work for this improvement this week.

In the meantime, there are two main options for your eventː

1. You can have separate event registrations for the translated subpages (so, in the case of your event, an Event Registration for English and for Brazilian Portuguese).

2. You can have one main event registration (which I see is on the Spanish version of the page), and then you can include a 'Join' or 'Participate' link as a header above the page and/or in the content of the event pages, and it would link to the Spanish page with event registration. As for what users would see, the event registration information would show in the interface language of the user. So, for example, if my language preference is set to English, I would see the event information (such as event date, time, the 'register' button) in English, even if I am on the Spanish page. Note that the user can set their interface language by selecting the language link next to their username (which should usually be at the top right of the page) or via Preferences > User Profile > Internationalisation.

We apologize for this inconvenience, and we're trying to fix this issue as fast as we canǃ You can follow our progress in T357716, and thank you again for raising this issue. IFried (WMF) (talk) 16:58, 27 February 2024 (UTC)

Thank you for bringing up these two solutions @IFried (WMF). I'll attend to that. And I'm eager to following up with the progress in T357716. ❋ CalliandraDysantha (✉︎) 20:49, 27 February 2024 (UTC)

Thank you for your response, @CalliandraDysanthaǃ Also, I forgot to mention a third solution, which is to use the direct event registration link for your event, which is Special:RegisterForEvent/308. You can share this with people for them to register directly and it should also be translated into their interface language of choice. And, yes, we will update the related ticket in Phabricator soon with our progress on the work. Thank you againǃ IFried (WMF) (talk) 11:16, 28 February 2024 (UTC)

Dashboard integration for privately subscribed users

Hello!

Using the Registration tool for [event], we had users who registered "privately".

They then didn’t appear on the corresponding program on Programs & Events Dashboard. I can understand that, were they on the public list on the Dashboard, it would defeat the utility of the private subscription.

But as far as I know, it breaks some of the Dashboard function, as they can’t select an article and do not appear anywhere as attendees, even from the facilitator point of view. Have I missed something? Nivopol (talk) 14:43, 13 April 2024 (UTC)

@Nivopol Thanks for the questionǃ Yes, the current implementation is that, if someone is privately registered, their username is not added to the dashboard (since, like you wrote, that would make their name public and defeat the purpose of private registration). In that case, I have a question for youː How would you like this situation to be handled instead? We are certainly open to exploring different approaches if they would be an improved experience while still respecting user privacy, so we are curious to hear what suggestions you may have. Thank you in advanceǃ IFried (WMF) (talk) 15:35, 15 April 2024 (UTC)

@IFried (WMF) I don’t feel I’ve any silver bullet covering all cases. What I was intuitively expecting was that the relevant attendees would appear on the Dashboard being only visible by the registered facilitators. It would be a direct translation of them being only visible to the event organizer on the Registration tool. But I get the feeling that multiple level of view rights isn’t implemented in the Dashboard yet. So it’s an all or nothing at the moment.

Moreover, obviously the event organizers and event facilitators don’t have to be the same person, and to have the same rights. So this behaviour would probably have to be an opt-in at the event organizer choice.

Let’s consider first we do not change the Registration tool form and someone (let’s call her A) registered privately. The tool registers her username and the organizer knows it. Then what could be envisioned as far as I can think:

(current behavior) A doesn’t appear anywhere on the Dashboard, her case must be handled manually by organizer warning the facilitator, at least of the number of privately registered people, facilitator then accounting for them at event. So facilitator knows 1 person more is attending, kind of blindly welcome any unidentified attendee hoping she is A, and manually accounts for her in article attribution, statistics and all Dashboard features. Some of the features are usable by impersonating A with the facilitator own account, but not tracking for instance. By the way, at this point, either A refuses to disclose her username, and must manage her participation autonomously as facilitator can’t even look at what she does, or A discloses her username to the facilitator simply by appearing in edited page history.

We could picture A having a username (of course, she registered) but not logging in during the event, then the facilitator can try to help without knowing more than a IP address. The same problem arises in relation to other attendees, if it is known that Article Yadayada is attributed to "someone" and A edits with her username, then any attendee can just look at page history and break privacy.

(hypothesis: global use of a temporary pseudonym) A doesn’t appear anywhere with her username on the Dashboard. A appears in the lists as a masked user, like Attendee #14, and all her contribution tracked by the Dashboard (which could be any edit on any wiki) are registered using Attendee #14 on the corresponding wiki, so as her pseudonym is never trackable, even by page history. Basically equivalent to A creating a sock-puppet for the sake of registering and attending the event. Her puppet name could be showed to A at registration time, so that she can identify herself on the tools and communicate as Attendee #14 with the facilitator.

Not disclosing her real pseudonym is a responsibility of her (obviously) and the event organizer (who could or could not have the name association showed to him by the Registration tool, to be discussed). At this point, we can even let A choose her puppet name at registration time.

Personal comments on the relevance of the discussion: I feel like, at this point, if A really wants to register to an event and attend to it without disclosing her pseudonym, we could perhaps simply warns her that "the pseudonym used for registering will be disclosed to the event organizers and attendees, if you don’t want that, please create a throw-away sock-puppet account and register and attend with it". And let her handle it. Because at this privacy level, why would her trust the event organizer by registering with her main username anyway? So all in all, I do not see the use case of the current private option.

I must say I’m in the situation where events are in-person meetings. So anonymity and privacy are in any case limited by the context: at some point we see each others and exchange at least pseudonyms to be called during the event.

As far as I understand, the private option has no sense for a tracked event with a Dashboard, save for participating to the event virtually from another location and not showing any of the work done to any other participant or facilitator. At this point, have you really participated? Or at least what was the point of the registration? I can see, for a remote event, the point of getting access to documents, video or chat communication, anonymously, with a facilitator, knowing that you should be careful to not show your username anywhere, so it’s simple for a "read-only" event, where you would at most ask question to the lecturer.

But really, I do not think that level of constraints is clear for users in the Registration tool, having a simple checkbox to check for "privacy" doesn’t cut it. So we should explicitly states what the checkbox implies and the behaviour the user must maintain to stay impossible to identify.

How we handled the current situation: well, I was quite dumb, so I proposed to add my users who had checked the box as co-facilitator on the Dashboard, as I couldn’t bypass the automated subscription and registered them as simple attendees. Obviously the best way would have been to ask them to modify their registration and make it public, and voilà, Dashboard problem solved. It can be done by explaining to them all the consequences of doing so at the beginning of the event. To be brutally honest, I would find a lot easier to just be able to disable the "private option" from the registration form as an event organizer, if I know that the event activities make impossible to maintain this privacy. Nivopol (talk) 12:36, 20 April 2024 (UTC)

PS: by the way, we already advise people registering at our events to create Wiki accounts with a pseudonym that can’t be linked to their real identity, and that using part of their names is taking a risk if they contribute on touchy subjects. And that we can’t guess what will become touchy in the future.Nivopol (talk) 12:41, 20 April 2024 (UTC)

Feedback e sugestões

Olá!

Recentemente testamos a Registration tool para averiguar a possibilidade de seu uso para os eventos temáticos que nós do Projeto Mais Teoria da História na Wiki ofereceremos ao longo do ano.

A ferramenta é realmente prática e simples de ser utilizada. Entretanto, dois fatores tornaram seu uso inviável para o nosso projeto:

Primeiramente, as informações requisitadas no formulário de inscrição são pré-definidas pela ferramenta. Não podemos modelar as perguntas para atender as necessidades especificas do projeto, como por exemplo, a obtenção de dados como nome completo, e-mail, identificação étnico-racial e de orientação sexual, entre outros.

Ademais, a ferramenta não permite a inscrição em atividades especificas dentro de um mesmo evento, o que impossibilitaria seu o uso para eventos que, como os nossos, oferecem a possibilidade de inscrição em mais de uma atividade.

Por tal razão, deixamos a sugestão de uma ampliação ou flexibilização dos dados coletados através do formulário, para que possam abranger uma maior variedade de informações das pessoas inscritas, bem como eventos que ofereçam múltiplas atividades em sua programação. Ana Vitória Farion (Projeto Mais+) (talk) 21:36, 17 April 2024 (UTC)

Event organizers should be able to register to their own events.

Hello!

Related to the lengthy discussion above about the interaction between Registration tool and Programs & events Dashboard, it made me realize that the Registration tool’s event organizers and the Dashboard’s facilitators are not forced to be the same people. And it underlines another limitation.

Namely: the event organizers can’t register to the event, so they can’t be basic attendees to their events. Why not? Nivopol (talk) 17:29, 22 April 2024 (UTC)

Actually it's possible . If we go direcly to the registration page by copying the link of the registration the user who manage the event can also register as an attendee.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 06:51, 23 April 2024 (UTC)

Ooohh! Thanks a lot! Special:RegisterForEvent/<eventIDnumber> for whoever would look for the page name. Nivopol (talk) 10:10, 26 April 2024 (UTC)