Anyone who is subscribed to the .NET Oxford Meetup.com mailing list, would have received a group email from me last week about what looked like a bug in Meetup.com. At the time of writing that email, it appeared that Meetup was taking members from the wrong end of the waiting list when places became available!
It turned out that this was a red herring due to confusing (and incorrect) data from Meetup. I thought it would make an interesting blog post to explain what happened - and also warn other Meetup organisers who might fall into the same trap / confusion.
The TL;DR version is that the
RSVPed on date shown in both the web-ui, mobile apps, and CSV download doesn't do what it says on the tin!
Next month we have our biggest meetup so far with Jon Skeet joining us to talk about the upcoming features of C# 8! When I published the event, I set the max RSVP count to 110, which thanks to Jon's insane popularity, filled up within the first day! I've never seen the RSVP count go up so quickly! Unfortunately about a week later, the venue got in touch saying that they'd made a mistake with the booking, and the room was no longer available! You can imagine the stress that would have caused if it wasn't for our awesome sponsors, Corriculo Recruitment, who immediately found an alternative venue! Infact, the new venue which is just a few doors down from our usual venue, can cater for 120 attendees - so we had another 10 slots to free up from the waiting list!
So once the new venue was confirmed, I increased the max RSVP count from 110 to 120. And all was happy in the world. For a while.
Then at our previous meetup, a member came up to me and said he thought that members were being taken from the wrong end of the waiting list! He showed me on his phone the RSVP timestamps that the Meetup.com app was showing. I couldn't look into this too much at the time as guests were arriving - but after a reminder email from him a few days later - I dug a bit deeper ...
Meetup allows event organisers to export a CSV of the attendee list. So I did this, and the two columns of interest were
RSVP status and
RSVPed on. The status is a text field - eg.
Waiting list, etc. The
RSVPed on field is a timestamp.
So in Excel, I sorted by timestamp descending, and looked at the status column. Wow - it looks like it was true! Meetup.com had taken members from the wrong end of the waiting list when I increased the max RSVP count from 110 to 120!!!
Obviously I can't put users' personal data in this blog post, but here's a subset of what I saw with names removed ...
(Remember that this is sorted by
RSVPed on descending - which is the timestamp column in the image above)
Note that the yellow highlight indicates the waiting list at the time I increased the max RSVP count. All RSVPs above the yellow hadn't happened at that point in time. All rows below the yellow are the 110 RSVPs that were already in the 'going' list.
So from that data, it appeared that the member who reported this bug was indeed correct. Note that in the image above, there's a big clue to what what the actual problem was, which I can't believe I didn't spot! Can you spot it?
So given our next meetup was with Jon Skeet, and only our second meetup which had a waiting list - this was pretty bad timing! I felt it important to be transparent. So I sent out the following email to our members ...
A bug has been found in the Meetup.com platform in the way the waiting list is handled. This was spotted by one of our regulars, who raised it with me at our meetup last Tuesday. I only had chance to look into this last night to verify this - but from what I can tell, it appears that he was correct.
Basically, it looks like for our event with Jon Skeet next month, when we changed venues, and increased the max RSVP count from 110 to 120 - Meetup.com gave those extra 10 places to the wrong end of the waiting list.
I reported this to Meetup.com last night, but haven't had a response back yet - which is a bit of a surprise given this is quite a serious bug!
I'm unsure if this bug only happens when increasing the max RSVP count, or also when anyone unRSVPs. If the latter - I'm really surprised this hasn't been noticed sooner.
This puts us in a difficult situation, as 11 people (not sure why it was 11 and not 10!) effectively jumped the queue. However, it's not fair that after those people have been told they have a place, that we take that away.
So what we're going to do, is honour those spots, and also allow in the 11 members that should have gotten in if it wasn't for this bug. We usually have a percentage of no-shows (people who have RSVP'd but don't show up) - so we'll have to assume that because of this, the additional 11 members won't cause too much of an issue on the night.
The downside is that I cannot edit the Meetup.com RSVP list / waiting list to correct for this issue. So that means I'm going to have to manually manage the RSVP list in Excel just for this meetup only. So if you have RSVPd, but can no longer make it - please reply to this email and let me know - so I can update the spreadsheet. I'll send out emails to everyone on the list to confirm their place nearer the time.
Please remember that if you've RSVPed, but don't attend - you've stopped someone on the waiting list from attending - which obviously isn't fair. So please help me ensure that the RSVP list is accurate and up to date.
I'll get in touch individually with the members that this affects.
Any questions, feel free to reply to me on this email.
Sorry about any problems this has caused,
Shortly after, I did get a reply to my support ticket from Meetup.com, saying that from their end, it looked fine. They showed this by mentioning some dates that some of the affected members RSVPd on. The thing was - the dates they gave me as an example, didn't match the dates I was seeing!
After a bit of toing and froing with the support engineer (who was actually really helpful), we realised where the confusion came from. Apparently, when a member is moved from the waiting list to the "going" list - that
RSVPed on timestamp gets updated! So this basically means that if you download the CSV and sort by
RSVPed on - this order is wrong, and it will look like members have been taken from the wrong end of the waiting list - even though this isn't actually the case.
The support engineer even said himself that this was really confusing, and he raised a support ticket with their developers to look into improving this. Apparently, the admin view that the support engineer sees shows those dates separately - so they can see the actually RSVP date and also the date they were moved from the waiting list. Unfortunately, the view that the meetup organisers sees has these dates munged together - meaning that the
RSVPed on column does not do what it says on the tin!
So, panic over - we can continue to use Meetup.com. But be aware that the RSVPed on date is incorrect. Hopefully, Meetup will improve this soon, allowing us to see the true RSVP timestamp that hasn't been overwritten by other actions that have nothing to do with when the the member RSVPd to the event.
I followed up my previous group email to our members with the following email explain what had happened ...
Following on from my previous email earlier today, I've just had a conversation with Meetup.com support, and it turns out that this was a false alarm.
The date shown in the UI and also the "RSVPed on" column in the CSV export gets overridden/updated when a member gets moved from the "waiting" list to the "going" list. So the "RSVPed on" column actually doesn't mean what it says.
A few quotes from Meetup support in the support ticket:
- "As I'm explaining this, I understand it's quite confusing."
- "on the back end in our system, I see both the original RSVP time and also the new time he joined the "going list".
- "I've gone ahead and filed a feature request to also have that information available for organizers to be able to see on the front end"
So basically, they have the correct data available, and they can see the dates in seperate columns - but in the organiser view that we see they're using the "RSVPed on" column to mean multiple things.
So whilst frustrating, and has wasted quite a bit of my time - at least this means that there isn't a bug with the waiting list - and we can continue to use the meetup.com RSVP system for next month's meetup with Jon Skeet!
Fun and games!
(ps. the clue I mentioned earlier in the image above which should have given the issue away is that those rows in red all have exactly the same date. I'm embarrassed I missed that!)