Eurofurence Information > Feedback

registration feedback

<< < (5/5)

Zefiro:

--- Quote from: Nosnibor on 23.01.2019, 00:19:35 ---Notice how Eurofurence tries hard to have nothing to do with the hotel bookings: they do not know who wants a room, they do not know who got a room or who is on the waiting list. They can only control (via the booking codes) who gets a chance to book a room (and when).
--- End quote ---
This is correct, and even for multiple reasons, including legal, data protection, financial, risk, on our side as well as what the hotel is able, willing and allowed to work with, for the same list of reasons on their side.


--- Quote from: Kulze on 23.01.2019, 04:55:52 ---within the limitations given.
--- End quote ---
Yes, indeed, that is the biggest blocker and reason why most of your suggestions, as well as many of our own ideas so far, in the end cannot be implemented. And I can assure you that we, too, are very unhappy about this, but short of not doing a con anymore at all, we have to choose one of the feasible options, even if none of them are what I'd call perfect.

*sigh*

Nosnibor:

--- Quote from: Reshi on 22.01.2019, 00:27:45 ---Personally I think last year was perfectly fine when it came to hotel reservations, comparing 2017, 2018 and 2019.
--- End quote ---
I agree that out of those three 2018 was the smoothest, i.e. everything worked as expected. The server didn't crash, probably because handing out registration numbers is less work for the server than producing hotel reservation forms, for which people have to log in first. And hotel reservation was stretched out over time, because people had to have their registration manually confirmed first, so no stress there for the server.
But there were still some disadvantages:
 - people had to wait several hours for their registration confirmation and then react quickly, if they wanted a room
 - the Estrel had to have staff in the office at a rather unusual time
This year's procedure would have gotten rid of both points, if it had worked (i.e. if the server had not crashed). The interesting problem now is to find a room booking procedure that does not have these disadvantages and does not put too much stress on the server.

Kulze:

--- Quote from: Zefiro on 23.01.2019, 17:06:30 ---
Yes, indeed, that is the biggest blocker and reason why most of your suggestions, as well as many of our own ideas so far, in the end cannot be implemented. And I can assure you that we, too, are very unhappy about this, but short of not doing a con anymore at all, we have to choose one of the feasible options, even if none of them are what I'd call perfect.

*sigh*

--- End quote ---

That's quite understandable, and if it weren't frustrating then I would be fairly surprised and definitely not trusting the least into the orga anymore.
What I find fairly boggling though is that there's no feedback coming from official channels about the options presented, which ones are absolutely impossible to do? What's the issue they would cause? Which ones are at least close to the realm of possibilities? Since you're already asking feedback, meaning you clearly need every possible help there is to solve the problem as quick and with as little issues as possible, wouldn't it then be good to let people know where those issues exactly are instead of generally saying 'it's legality issues'. Nobody here can give a proper solution or something which can be made into one if they have to do guesswork out into the blue, simply because everyone lacks a fundamental understanding of how those things work in the background.

Would a lottery be feasable?
Is a token even doable?
Can a template for the booking be handed out far in advance to only attach the codeword at the respective time?
Has the codework to be a single one for the hotel, or is a personalized one possible?
Is a priority for specific groups besides helper and fixed con-staff even relevant?

All those and surely many more are unanswered, and while a week seems like a long time for someone edging on hearing news for possible solutions, it at least would be possible to inform us about the things which have been pushed out as feedback already. Nobody knows if you're swimply twindling your thumbs in the background (unlikely) if there are solutions up for discussion or you're still stumbling completely in the dark. Knowing that would at least allow to work on without letting the threat - and issue - once again die down.

And yes, last year was clearly the best solution of the trio of years, which is sad to hear that causing a ton of stress for everyone involved was actually better then having a streamlined (dumbly implemented to say though) system in place.

Nathalias:

--- Quote from: Nosnibor on 23.01.2019, 23:27:47 ---This year's procedure would have gotten rid of both points, if it had worked (i.e. if the server had not crashed). The interesting problem now is to find a room booking procedure that does not have these disadvantages and does not put too much stress on the server.

--- End quote ---
Or just throw enough server capacity against it. With the big cloud services you can rent that capacity just for the occasion. But you need someone who can prgramm the app for a cloud service, you just can't throw your excisting one in and let it magically scale ;-)

Equinn:

--- Quote from: Nosnibor on 23.01.2019, 00:19:35 ---Notice how Eurofurence tries hard to have nothing to do with the hotel bookings: they do not know who wants a room, they do not know who got a room or who is on the waiting list. They can only control (via the booking codes) who gets a chance to book a room (and when).

--- End quote ---

Okay, so this is exactly what would change. And it still wouldn't mean EF has to "deal" with the bookings, Estrel would still be handling that obviously. What gave anyone the impression otherwise? The difference is that EF would control who's application is sent to the Estrel, based on a lottery result. Doing this, legally, should be no different than flooding the Estrel with thousands of emails and leaving the random choice up to them (because yes, due to the fact that those emails will NOT arrive in order, its already a random choice, this has been stated by EF staff as well). I thought this would be quite clear to everyone. Instead of telling a group to charge at Estrel, you take their applications and select , randomly, the amount that matches the free spots in the Estrel, and send THAT to them (to the Estrel). If it's such a legal issue to handle (more) personal data, to autofill and autosend the emails to Estrel after the lottery, then just send the notification to the winners of the lottery and ask them to fill out an email template (the part with their personal info), as it is done now. The difference being that everyone who sends those emails, gets a room. This would be simply admitting to the already random nature of the whole process and consolidating it into a system that is a LOT less stressful to everyone. (Yes I did simplify the random selection part, since obviously it would need to take into account pairings, and room types requested, maybe even alternative choices, etc, because that's just a matter of coding the logic for it, and it's not exactly rocket science especially for experiences backend devs)

Again, I don't understand how this leads to concerns from the EF staff such as voiced by Zefiro, in this thread....


--- Quote from: Zefiro on 23.01.2019, 17:06:30 ---Yes, indeed, that is the biggest blocker and reason why most of your suggestions, as well as many of our own ideas so far, in the end cannot be implemented. And I can assure you that we, too, are very unhappy about this, but short of not doing a con anymore at all, we have to choose one of the feasible options, even if none of them are what I'd call perfect.

This is correct, and even for multiple reasons, including legal, data protection, financial, risk, on our side as well as what the hotel is able, willing and allowed to work with, for the same list of reasons on their side.

--- End quote ---

Sorry but I don't see where this is coming from (how these are concerns in this case). Again you'd not be handling bookings, you'd simply be pre-filtering the applications based on a lottery system, and that has nothing to do with the Estrel. The only information required from the Estrel is the actual number (and types) of free rooms to start with, and that data is already available.
Honestly I can't believe that handling personal data, to auto send the booking emails to Estrel, would translate to such a huge challenge that the only other option is to not have a con....But even so , as stated above, there is a way around even that.

Navigation

[0] Message Index

[*] Previous page