Hello! & Bridge Troll issues from Chicago

[Lauren Scott]

Hey all,

Nice to meet you!  I'm Lauren, one of the lead organizers for RailsBridge Chicago.  I'm a poet-turned-programmer by way of Dev Bootcamp, now a Rails developer at Brad's Deals.  I am SO EXCITED about our new Chicago chapter, and we're working on our second workshop at the moment!

I managed most of our Bridge Troll tasks for the last workshop, and I have a lot of feedback that I think could be really valuable for people.  I know some of our organizers here are interested in helping write the code for fixes to these!  So prepare for a fairly exhaustive list of Bridge Troll issues and requests, written with the aim to be actionable and kind. :)

1.  This one's the biggest, and the most nebulous: I had a weirdly large amount of both students and volunteers tell me they had signed up for our workshop when they hadn't.  In the case of the volunteers, some were adamant they'd done it twice.  I think either something is off in the UX that's making them think they've completed the process when they haven't, OR there's a bug.

2.  After a frazzled email from me, Lillie was awesome enough to get some changes made in that now we can see the RSVP form the students will receive.  Heck yes!!!! But I would love to be able to change the form, or add extra fields.  There are things that each chapter or each workshop might want to add in order to get the best information for them.

3.  On that note, I'd also love to be able to see all of the submitted information on the survey-answers CSV form.  Last time I had absolutely no idea what we had asked them (or where to see that information, which is not really anywhere except for in the section picker tool) so I wrote my own form and sent it out.  If you want to be able to access the form responses outside of the section picker, you're plain out of luck at the moment.

4.  We really need to be able to limit the number of volunteers.  Last time I actually had to strategically hide the fact we were having an event from a lot of people because I knew too many of them would want to sign up.  It's an awesome problem that we have here!  But once you get to a 2:1 student-to-volunteer ratio, adding more more volunteers hinders instead of helps.  Also, having a set number helps with budgeting for and ordering food.

5.  We had a lot of issues last time with both volunteers and students telling us they couldn't make it via email and not updating their rsvp's.  Asking them to update it once is fine, but we don't want to have to hound them.  Some people would rather ask you to do it and then not have to worry about it anymore.  So: I think it's pretty important to have the ability to remove someone. I guess we'd have to assume that organizers would not be malicious with this tool?

6.  Can the email form handle html?  Markdown?  I honestly was so scared of that completely blank box with no notes about what it can handle that I patently refused to use that tool and did all of the communication with students and volunteers via email.  A preview would be awesome, but even something saying "this can interpret html" or what have you would be fine.

7.  Another problem I ran into was figuring out who was a new rsvp (or had gotten in from the waiting list) since the last email I sent.  For example: on Monday, you send out an email with important information about that week's workshop. By Wednesday, 10 people have gotten in off the waiting list.  You want to send them the first email, but you're not sure which 10 students they are.  You don't want to re-send information to other people and annoy them or make them think your emails aren't important and can be ignored.

     Last time, I was meticulous about this: I was legit pasting all of the emails of the current students into sublime where I could easily keyboard-shortcut them into strings in an array, then doing the same with the emails of the students I had sent the previous email(s) to, and then slapping them both into IRB where I ran some code to see which students were in the current students recipients list but weren't on the list for the last email.

     Suffice it to say, this is a pretty silly use of precious organizing time.  So here's my proposal: if you send an email via RailsBridge to your current attendees, you can optionally check a box to have that email sent out to any new attendees upon RSVPing.  Worry-free!

And that's it!  Hopefully that was helpful for you all.  Thanks to everyone for caring about stuff like this, which is what makes RailsBridge such a great organization.  You all rock.

Let me know if you have any questions about any of this!

All my best,

Lauren Scott

@devdame

[Clara Raubertas]

Being able to manually edit student RSVPs seems pretty high-priority! And limiting the number of volunteers sounds both useful and like it shouldn't be a big technical challenge?

Megan, I'm happy to work with you on any of these!

On Tue, Feb 24, 2015 at 9:18 PM, Megan Gaebler <megan....@gmail.com> wrote:

THANKS LAUREN. This is really helpful! What are you hoping is fixed by the time we open registration for the next workshop? 

Alright, folks, we have our work cut out for us. So how do we want to do this? Some of these issues seem large enough to warrant at least two people working on them. Most of them seem like they have creative solutions and it could be fun to work together! 

[Lillie Chilen]

A few thoughts, and some questions (mostly for Lauren), but any other organizers are welcome to chime in!

People Not Being Signed Up

I wonder how much of this was a result of having a Meetup page and also a Bridge Troll event. In SF, once we had enough people in Bridge Troll, we stopped cross-posting events to Meetup, because it did cause a lot of confusion, even though people weren't actually able to RSVP on Meetup itself. I don't see any particular Bridge Troll feature that we could add — if someone received the email confirmation that they RSVP'd, then they're signed up. It would definitely be awesome for anyone to do some UX research on the RSVP process, and maybe I've done it too many times myself to actually appreciate the complexity, but I feel like it's pretty straightforward.

Freeform RSVP Questions

What specific things did you want to change? I think having uniform data across workshops is really useful, and although it's certainly technically possible to add freeform RSVP questions, I'm not sure it's a direction I'd like to see the app moving in. I'd love to know more about what specifically is missing from the questions that are there.

Email Issues

There are fields on the event (Volunteer Details and Student Details) that get emailed in the RSVP confirmation. What information were you including, Lauren, that didn't make sense to put there, that you wanted to send out to the newly-included folks off the waitlist? I'd love to know more about what specific emails you were sending out to groups of volunteers; I think rather than adding more complex email behavior, we should first make sure we're leveraging the current functionality.

Volunteer Limit

I think that product-wise, we should have a conversation about the best way to handle volunteer RSVP capping. My main question is whether it should just be a hard cap or if there should be waitlist functionality like student RSVPs. I don't know if volunteers want to come badly enough that being let in on a waitlist would result in them actually showing up.

Manually Editing RSVPs

I think this is a good idea in general; I would recommend anyone who wants to implement this be sure to look into how removing someone hooks into the waitlist code, so that the next person's spot is taken automatically.

Features that I'm totally in favor of that probably don't need a lot of product thought

• CSV download that includes all of the questions and answers for students and volunteers
• Text on the email form that says what you can include (just text, I think, but someone should look at the code)

--

Lillie Chilen
@lilliealbert
('li-lee shuh-'leen)

[Clara Raubertas]

So, we're tentatively opening registration for our next event on March 16th. Can we try to have manually editing RSVPs and volunteer limit ready by then? I can write code but I want to make sure that everyone's on board with the changes.

[Lillie Chilen]

I think that it's definitely doable, but getting the code written soonish is important, since there is usually feedback / code review changes that need to go in before PR's are accepted. Also: write tests; don't break the build :D :D :D 

(If it doesn't look like you're going to have time, Travis knows the codebase super well and can definitely help add these features, but it would be much cooler if you were able to contribute!)

Features-wise, editing RSVPs seems like a straightforward additional interface from the organizer console, so total thumbs up there from me.

I am still not sure exactly what kind of volunteer limit you're thinking about implementing — a hard cap that doesn't allow anyone to volunteer after a certain limit, or a waitlist-style limit similar to how student RSVPs are structured? Seems like a hard cap is easier / more MVP-ish, but the code is all there for waitlists, so that would also be a viable route as well.

[Clara Raubertas]

That sounds good to me! Next week I can try to work on the ability for admins to edit RSVPs.

On Sat, Feb 28, 2015 at 4:35 PM, Megan Gaebler <megan....@gmail.com> wrote:

I agree that a hard cap will be easiest to implement, but I'd love to see wait-list style for volunteer cappage and know who to next call if some volunteers can't make it for whatever reason or who to reach out to for future events. Maybe we could implement something that, when you're creating an event, lets you set whether or not there will be a hard cap on volunteers.

I'm gonna get started on the volunteer capping/waitlist this weekend if this all sounds okay!

[Lauren Scott]

Hey, sorry for the delay—it's been a constantly-on-the-verge-of-panic kind of busy week for me, so I'm trying to catch up with stuff now. :)  Let me answer Lillie's questions!

People Not Being Signed Up

This was definitely a Bridge Troll thing (whether ux or bug, not sure) and not Meetup confusion.  The cases I'm talking about are when someone told me they signed up on Bridge Troll, and in some cases, when I told them to try again, said they signed up a second time on Bridge Troll and still weren't rsvp'ed.  What might be happening here is that they *think* they're rsvp'ing for the workshop but they're really just signing up for the chapter? Worth some exploration!

Freeform RSVP Questions

Last time I did my form and the class sorting by hand, and there were a couple of fields that were really helpful for me—one was having people describe their experience, and another was having people say what other languages (if any) they know if they're new to Ruby.  Some people grossly over or underestimate their experience levels, so the describe your experience field could be useful even if you're using the Bridge Troll class organizer (which I assume most people are).  Then you could just skim the descriptions of each girl in a group and see if there are any that clearly chose the wrong experience level and move them accordingly, thus eliminating some of the mismatches and switching that might happen at the workshop.  The other languages thing was great for figuring out if there's a TA whose group they'd do well in because they could say, "You know how in Java it's like this?  Well, in Ruby, it's like this."

Email Issues

The emails I sent out followed your email guide from the Cookbook for both updates/reminders and for survey stuff, which won't apply in the future.  But some of them are just more detailed information about the day of—the schedule, directions, details about the after party, etc.  If I just changed those in the description when we got more info, the already signed up students wouldn't know.  And it would make for a not-very-consise description. In terms of the blank box, though, I would love love love if that could parse html or if I could include a link or bold lettering or whatnot.  Otherwise I know at least I will continue to do it through our gmail account so I can have that.

Volunteer Limit

I like the idea of a wait list!  Why not?  That way if someone quits a few days before you don't have to scramble for more help.  But I think it would also be fine to have an MVP without it.

Thanks so much everyone for all the thought and effort!  You rock!!

Cheers,

Lauren

On Sat, Feb 28, 2015 at 4:35 PM, Megan Gaebler <megan....@gmail.com> wrote:

I agree that a hard cap will be easiest to implement, but I'd love to see wait-list style for volunteer cappage and know who to next call if some volunteers can't make it for whatever reason or who to reach out to for future events. Maybe we could implement something that, when you're creating an event, lets you set whether or not there will be a hard cap on volunteers.

I'm gonna get started on the volunteer capping/waitlist this weekend if this all sounds okay!

[Clara Raubertas]

Hey folks!

I made changes so that organizers can move people on and off the waitlist, and sent in a pull request for this (it's also on the RailsBridgeChi org's fork). Let me know what you think!

cheers,

Clara

[Clara Raubertas]

OK, we now have the ability for organizers to delete RSVPs! Megan, did you get anywhere with creating a waitlist system for volunteers?

[Clara Raubertas]

Awesome! Thanks Megan!

On Tue, Mar 10, 2015 at 12:26 PM, Megan Gaebler <megan....@gmail.com> wrote:

Yes, I've been adding waitlist code to the backend & expect to finish it up with views this weekend!

[Megan Gaebler]

I agree that a hard cap will be easiest to implement, but I'd love to see wait-list style for volunteer cappage and know who to next call if some volunteers can't make it for whatever reason or who to reach out to for future events. Maybe we could implement something that, when you're creating an event, lets you set whether or not there will be a hard cap on volunteers.

I'm gonna get started on the volunteer capping/waitlist this weekend if this all sounds okay!

[Megan Gaebler]

Yes, I've been adding waitlist code to the backend & expect to finish it up with views this weekend!

[Megan Gaebler]

THANKS LAUREN. This is really helpful! What are you hoping is fixed by the time we open registration for the next workshop? 

Alright, folks, we have our work cut out for us. So how do we want to do this? Some of these issues seem large enough to warrant at least two people working on them. Most of them seem like they have creative solutions and it could be fun to work together! 

On Tue, Feb 24, 2015 at 8:20 PM, Lauren Scott <wiscon...@gmail.com> wrote:

[Megan Gaebler]

Hey,

I've added a TON of logic to the models for supporting volunteer waitlisting and limits, but for the life of me I cannot figure out how to implement this in the views - I just don't know which views are the right ones. Can anybody meet up with me this week to help figure it out? 

Thanks!

- Megan

ps. Sorry that this is taking longer than anticipated - I just started a new job and it is kind of kicking my ass.

[Lillie Chilen]

Hi Megan,

Since waiting lists already exist for students, I'm not sure why you would need to add a ton more logic to the models for them. Have you looked through the code for student waitlists? 

Maybe you could open a provisional PR or send us a link to your fork so we could take a look.

Thanks,

Lillie

[Megan Gaebler]

Sorry, I misspoke. I should've said that I've adapted the logic to incorporate volunteers and students. I just need help figuring out where volunteer limits and waitlists can be set. 

[Lillie Chilen]

Cool — we can definitely help with that. The student limit is on the event new/edit form, so I imagine the volunteer limit should go there, as well:

​Opening a PR or sending the link to your updated fork on GitHub would definitely be an efficient way to get pointed in the right direction!

[Lauren Scott]

One added issue from today:

I was updating the event from the organizer console and changed the max number of student RSVPs from 60 to 65, then clicked save.  Instead, it took all 10 people off the waitlist and 70 students are now RSVPed.

I went back to make sure I had selected 65, and I had, and when I tried to save the event again it gave me an error and wouldn't let me save since I have 70 people RSVPed.  The weird part is that if I go back into the console and click "edit event" it auto-populates with 65 as the limit, which leads me to believe it's set at 65 in the database (if that's how the auto populate works on that page), and if I try to save the event without changing anything it gives me the same error.

For this workshop we'll hopefully get some no-shows and the 70 RSVPs will be fine (can't really take them back!  I assume the students have been contacted) but something in there must be awry.  If you want to check the database for troubleshooting purposes, it's workshop id 157.  I haven't updated the rsvp cap again so you can check to see if it's actually at 65 or what.

Thanks! :)

-Lauren

[Travis Grathwell]

The event is definitely set at 65 in the DB, so it's some kind of bug.

Good thing it happened with only 5 extra students and not 30, I guess...

I'll try to take a look later to reproduce this situation in test so as to get it fixed.

--
You received this message because you are subscribed to the Google Groups "Bridge Troll" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bridge-troll...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Travis Grathwell]

I looked into this and so far haven't been able to find a satisfactory explanation.

I downloaded the database backup from the time before you updated it from 60 to 65, and did so on my local machine. It bumped up just the expected five people, no problems. There didn't seem to be any inconsistencies in the counter columns for the event, either.

The algorithm for de-waitlisting is:

1. Calculate the amount of free slots (student_rsvp_limit - student_rsvps_count (non-waitlisted))

2. Grab that number of waitlisted students from the DB

3. Remove them from the waitlist and email them, one by one

4. Renumber the waitlist so the remaining people have waitlist positions 1..n

Near as I can figure, the problem might be some race-y or cache-y thing, like maybe:

* Two transactions run at the same time, and both succeed, meaning double the normal people get de-waitlisted. But that kind of goes against my idea of what a 'transaction' is.

* Some of the counter columns like student_rsvps_count aren't getting updated right, causing weird math. But if this was true it should've been visible on the event before increasing the account; it would've said "55/60" or somesuch.

I've added a little extra code in https://github.com/railsbridge/bridge_troll/commit/9663b104e34bf3dad836f1d47550f39271a36384 that tries to make it less likely than an event will become over-full. But it still fundamentally relies on student_rsvps_count having the correct value, so if that's the problem then the flaw may still manifest.

Is there anything else you remember about the situation when you updated those RSVPs? Were you updating other fields too? Did you get caught in a freak lightning storm?

Promoting students from the waitlist is such an important role for this software to do correctly and I hate to feel that it's unreliable :'(