Use WP.org users for WordCamps

[pkevan]

Tie a WP.org user to a participants of a WordCamp.

Would help with ticket purchase along with additional ability to track contributor day & workshop attendance.

This may cause issues with the built in caching through WP Super cache, but could potentially get around this by turning caching on for logged in users and create an exception for anything ticket or attendance based areas within the site.

Has the potential to also help with some participation items mentioned in https://github.com/WordPress/wordcamp.org/milestone/12

[courtneyr-dev]

This would also be helpful for https://learn.wordpress.org/online-workshops as well. It is using Meetup + Zoom to power events.

[timiwahalahti]

Quick note: we don't want to force WordCamp attendees to have a wordpress.org account (I can't find the discussion right now).

[pkevan]

we don't want to force WordCamp attendees to have a wordpress.org account

Makes sense, I wasn't assuming it would be forced, but as an option.

[timiwahalahti]

Gathering the wp.org usernames could actually help in future with #639

[peiraisotta]

Hello team! We have a request and a question for both WC and Next Gen ticket form (when attendees buy tickets) and @StevenDufresne suggested to comment this issue.

• Can you please add a non-required field (non mandatory) where we ask for the attendee .org profile?

The reason behind this request is to have a way to track attendees by using their .org profiles: who they are, what they contribute to, if they're sponsored or not, etc. For the moment this information would be only internal, and we are not sharing it with anyone.

• To reach this goal do you think we should ask for the username or the link to their profile? Or do you have a better solution in mind? (The idea is to have a similar thing that we currently have when we ask for their twitter profiles, ad to be able to pull this info from some report in the future.)
• There would be the space to add a little call to action to invite them to create an account in case they doesn't have it yet?

Thanks a lot for your help! Please let me know if you need more info.

(this request is based in our need to know our attendees better. It’s an initiative of the Global Sponsorship Working group.)

[StevenDufresne]

I think this is a good opportunity to improve the ticket purchase process. I don't want to blow the scope out but I think we can separate the Account related information with the questions.

Screen 1

Screen 2/3 The questions & payment windows, etc..

@iandunn Thoughts?

[iandunn]

🤔 I think separating it like that could work 👍🏻 Register might confused with registering for an account vs for a ticket, so Get a ticket might be more clear.

If I were the user I'd want it to be clear that I don't need to login to buy one, and also how to sign up if I don't already have one. I'd also want to know what benefit there is to me if I do log in. If we're going to do that, though, we should complete #639 at the same time, so we're not telling them something that isn't true.

I don't think we should include Gravatar, since integrating with it might be complicated, and I assume the usage would be low.

If we don't want the extra complexity of adding another step to the process, then we could also integrate it into the current first step:

With both approaches, we can redirect them back to where they were before they clicked the "login / signup" links.

[CdrMarks]

In the situation where a WordCamp's tickets sell out, I often see, and have participated in this as well, manual updating of the ticket details to "transfer" a ticket to someone else. Will the connection to someone's WP.org account be permanent? Could it be updated later if I people use this process to transfer a ticket?

[iandunn]

That's a good point to raise 👍🏻

Dion raised another one on #639:

What about when a ticket is bought by an employer (as say, part of a sponsorship) and uses their Work email alias?

If we ask the ticket buyer to log in, we'd only be able to populate their name/email in the form. We'd still need to ask for the usernames of all the other people they're buying tickets for.

[iandunn]

For transferring a ticket and buying tickets on behalf of others, we could get their username by having a form field that explicitly asks for it, instead of asking them to log in. That would let folks transfer the ticket to another person, or register for someone else.

One downside is that we won't be able to verify that it's the correct username. They could make a typo, remember it wrong, confuse their w.org username w/ their personal WP site, etc.

Another downside might be that it's not as practical to auto-fill their name/email, since that'd have to be an AJAX request once they enter their username. They may start typing the name before the AJAX request completes, in which case we have to decide to overwrite their answer, or ignore the results of the request. If they go back and change the username then we have the same decision. 🤔 We could maybe make the name/email fields disabled if they type in a username, though. I think that would work.

[CdrMarks]

Is one of the goals of tying a ticket to a WP.org username to have their participation show up on their .org profile? If the username can be entered without authenticating, it's possible for this to be abused and intentionally provide another user's username.

[StevenDufresne]

Is one of the goals of tying a ticket to a WP.org username to have their participation show up on their .org profile? If the username can be entered without authenticating, it's possible for this to be abused and intentionally provide another user's username.

What would be the incentive?

[iandunn]

it's not as practical to auto-fill their name/email, since that'd have to be an AJAX request once they enter their username. They may start typing the name before the AJAX request completes

We could probably avoid that by adding a disabled attribute to the name input field once the username field is no longer empty.

[megmorsie]

This issue needs updated since this is now live on prod. :)

[megmorsie]

It's probably also worth noting or opening another issue for this, but this has caused accessibility issues on sites that are actively selling tickets at the moment - they didn't have a chance to update their site's CSS by the time this went live.

Example:

https://romania.wordcamp.org/2024/tickets/

[ruhanirabin]

There are tickets that will be purchased for others - how it is going to work with this blockage? I mean this could be enforced when the event is not too near, now it is blocking sales. I looked around the comments above, and none of them are practical or simple. Not only that, but I also got notifications from other people that creation of WP org account has a different level of difficulty.

[StevenDufresne]

There are tickets that will be purchased for others - how it is going to work with this blockage?

@ruhanirabin See: https://github.com/WordPress/wordcamp.org/issues/1393

@pkevan Can we close this?

[pkevan]

@pkevan Can we close this?

Probably, although we should monitor how having everyone logged in affects performance, but this should hold as a reference to that even if it's closed.