Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Equinn]

A lottery system is definitely fine as well, would be a fairly fair solution without taking into perspective bigger groups wanting to go to the convention together while also staying more or less together.

That doesn't work right now either, in the current system. The lottery would retain the ability to keep small groups (2-3 people) together though, since you'd specify your roomies in your room preference, by name/reg number. It wouldn't just spread people into rooms randomly and pair them up automatically, that would never work,instead it would spread the rooms randomly among those who requested one.

Also, 'first come first serve' system doesn't necessarily mean that it's unfair. It can't be denied that a miniscule amount of lottery is involved because of network situations, though the majority still rests at people preparing properly to follow the steps as swiftly as possible, may the best win.

Actually that minuscule is massive. Mostly thanks to how emails work. But that's a whole different topic. Suffice to say, that a ton of emails in a short time will be pretty much randomized. Also creating a competitive environment in this context is not something I personally support, but again, that's me.

So, just to hope this was a wake-up call for next year, and that the feedback is properly looked through and implemented to a degree where as many people as possible are content with, providing no more loopholes and finally leaving everyone with less frustration then the last years as well as less work for everyone. Automation for as many steps as possible is definitely mandatory to achieve this.

Honestly, ladenfurence should've been a wake-up call already...This year it was actually worse, so yes..this definitely has to lead to some major changes. I do believe those involved don't want to intentionally make anything bad,it's just the lack of experience, and thought, that might've been due to other duties, etc...not that this is an excuse. What I'm getting at is that I still hold out hope that they'll move towards a radically different, and functional solution to avoid this grief.

[Reshi]

Personally I think last year was perfectly fine when it came to hotel reservations, comparing 2017, 2018 and 2019. And I'm talking about 2018 of course, not the 2017 Ladenfurence incident. You just registered and after your registration was accepted, you were able to send the generated email. Of course there was an initial rush with the registration and it wasn't ideal for Estrel since it took place in the evening on a Saturday. But out of all of these, it felt the least stressful and it didn't take that long, comparing to the 4 hours it took me to be able to book the room at EF23 and bit over an hour to be able to send the email this year (which ended up me being waitlisted).

But this is of course just my personal opinion. If we really had to prioritize people who get to reserve rooms, it would be first staff and then maybe the people who are in the dealers den. That would require DD team to choose the people for the den before hotel reservation even starts tho, so I don't know how ideal that is in the end, for the DD team and the artists. But I fail to see why fursuiters would be prioritized just because they are fursuiters, since they are not going to the con to work like staff or sell merch at the den. It's not mandatory to fursuit at the con (or any con) in the first place. For reference, I am a fursuiter (with two fullsuits) and would prefer a room at the Estrel but this time I just wasn't lucky enough. I'll still bring my suit most likely, but just won't be suiting as much probably.

I think it would be interesting to try a full on lottery style approach to the reservation but I know it will be an issue to some people. But whatever is decided for next year, there will be atleast someone who is not OK with it regardless. Atleast having the rooms non-transferable makes it a little better since if you can't come, you cancel it and the room just goes to the next person in the waiting list. If they were transferable, the whole waiting list would be kinda pointless.. :b

[Kulze]

Another few of those many possible solutions:

For a lottery based system:

After registration a selection of possible room options (and their respective prices) is shown, every user chooses each they would be willing to take (or rather pay for).
Before the booking begins Estrel then sends their contingent of rooms to the orga, they put in a simple amount of reg numbers viable shown for the category. To stop double confirmations for several room types as soon as one number is chosen for a higher type of room it gets blocked to be chosen again for the lower type.
And last but not least there is an automatically generated mail send to the attendees with a personalized code only available for them, the hotel at the same time receiving a list of viable codes to cross-check with a single look who sends an actual proper booking mail.
As an upside, the random generator can even take over the bother of the waiting list, generating an entry for every single one wanting a room but not being able to get one, as well as informing them for which number they are in the waiting list, able to be checked upon logging in on the registration site. This way not only would it lower the amount of input needed to keep the system working for everyone, it also finally allows to see if there is an actual chance of getting a room in time.
If the booking isn't validated after a certain amount of time the spot automatically moves over to the next person, as for the amount of time needed for that, well... the orga and hotel definitely know those best.

Simple, quick, without bother.

As for another 'first comes first serves' solution:

A little extra at the EF app, a token generator. You can always generate a personal token based on your registration number and a hidden keyword which is on the registration server. At the respective booking time that keyword gets changed over to a new one for the year, as well as a list of viable codes once more send over to the hotel. This way people only have fetch a single code from the server, not putting it under a lot of pressure and allowing for a swift and painless procession of bookings. A template for the mail being available beforehand already where only the code needs to be put in.



@Reshi: At least you got onto the waiting list, that's more then (from what I'm hearing and reading) 90% of people can say. If you were sending the booking mail at the time of the official release of the code you were out of luck already. Getting an actual room was very rare and getting on the waiting list as well. Most only got 'well, screw you, search somewhere else' basically.

[Nosnibor]

Yes, but even upon registration the photo(s) are checked one by one, manually, to my knowledge (as it stands , to filter out unsuitable suits, pardon the pun). So you'd have to fool that first level at least, and once you are at the Estrel you would have a very hard time convincing anyone that you are a suiter while you don't have a suit, and you'd be banned.

I don't think a priority list is too controversial, I just don't believe it is practical.
AFAIK ticking the "fursuiter" box and uploading a photo to the registration server is just for statistics and optimization (printing fursuit badges in advance); the actual proof is showing the head at the registration desk.
Suppose I register as a fursuiter, then get a hotel room (because of fursuiter priority), and then, during the seven months somehow become a non-fursuiter (fursuit gets damaged or stolen, or maybe I intended to build my first fursuit, but didn't quite finish it in time; a lot can happen in seven months). Then of course I should cancel my room at the Estrel and find other accomodation, because at the start of the con, someone will take the time to check wether all those who got a hotel room through priority still have their priority status? That's just not practical.
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).

[Kulze]

I don't think a priority list is too controversial, I just don't believe it is practical.
AFAIK ticking the "fursuiter" box and uploading a photo to the registration server is just for statistics and optimization (printing fursuit badges in advance); the actual proof is showing the head at the registration desk.
Suppose I register as a fursuiter, then get a hotel room (because of fursuiter priority), and then, during the seven months somehow become a non-fursuiter (fursuit gets damaged or stolen, or maybe I intended to build my first fursuit, but didn't quite finish it in time; a lot can happen in seven months). Then of course I should cancel my room at the Estrel and find other accomodation, because at the start of the con, someone will take the time to check wether all those who got a hotel room through priority still have their priority status? That's just not practical.
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).

Yes, exactly, a priority for fursuiters is rather far back on the list definitely, at least that's my opinion. As to why? First, a suit can be transported fairly well at a single day and then stored in the fursuit lounge as many do, especially those from outside the Estrel. This has worked for years and hasn't stopped many from actually bringing it.

Hence why my focus was mainly on people who actually need to be in the Estrel to be able to enjoy the con decently or offer something to the con to make it better. Namely for the first impaired people who already have a hard time getting from one place to another and everyone in the dealers den as those often have quite the amount of wares sitting around, making it a nightmare to transport further then the garage and back, or to the room. Also getting something during the opening times is nigh impossible if you're outside of the Estrel, the time your table would be empty is just too long, as well as sending someone else isn't feasable usually.
I can't think of other people who might be in need for a place in the Estrel primarily, besides the helpers, which is fairly obvious and already implemented.


Also, as an important part, the orga already has a fair amount to do with bookings, after all it's impossible to get a room if you're not proving to go to the convention via the registration and the code provided, as well as cross-checking if those registrations are still viable from time to time. The problem I see is that it's - sorry for the following words, I just don't find any better - half-assed. Trying to stay out as much as possible has proven to be detrimental, hence there needs to be a way to properly work together with the Estrel to ensure everything moves without issues, working tighter together then it is the case at the moment, within the limitations given. There's still a lot of room to work in that's unused, and that part has to be taken up and used now.

[Zefiro]

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).

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.

within the limitations given.

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]

Personally I think last year was perfectly fine when it came to hotel reservations, comparing 2017, 2018 and 2019.

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]

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*

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]

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.

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]

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).

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....

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.

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.