Challenges with newly updated 'Email Attendees' feature

[kmolo]

With the update to the 'Email Attendees' feature that does not allow Organizers access to student + volunteer email addresses (previously an organizer used to have the ability to click 'Who?' and get a copy-able list of email addresses), there are some new challenges:

1. when you click the 'CC Organizers' checkbox, the organizers receive the email as if it was sent 'To' them, not as a CC
   • possible solution: move them to CC + send To sender (who is their co-organizer)
2. when you email a group of volunteers, there is no way to set them up to be able to reply-all
   • use case: you want to connect a group that will be teaching together, so they can discuss how to break up who is teaching which section
     • presently, you have to request that everyone reply back to the sender with their email + to give permission to share their email with everyone else
   • possible solution: would be nice to create a checkbox along the lines 'provide reply-all option'
3. when a venue wants email addresses of attendees to pre-register (possibly this isn't, even a problem)

• possibly not a problem that we want to solve

---

Is there a link to the discussion of this change when it was a work-in-progress? Would be curious to read.

[tjgrathwell]

The PR that changed the Email Attendees feature is #374.

Not sure if there's anywhere else where we specifically discussed the fact that the email addresses are no longer revealed, though it was definitely a concern and makes certain workflows harder.

So far, we go to a lot of effort not to directly reveal email addresses to anyone (including organizers), aside from the "Who?" popup. Allowing recipients to "reply all" back to the email effectively reveals everyone's email address to each other, which they've not necessarily opted into.

Some ideas we may have talked about before: ged the Email Attendees feature is #374.

Not sure if there's anywhere else where we specifically discussed the fact that the email addresses are no longer revealed, though it was definitely a concern and makes certain workflows harder.

So far, we go to a lot of effort not to directly reveal email addresses to anyone (including organizers), aside from the old "Who?" popup. Allowing recipients to "reply all" back to the email effectively reveals everyone's email address to each other, which they've not necessarily opted into.

Some ideas we may have talked about before:

• Allow organizers to see everyone's email anyway (the old "Who?" behavior). We may want to tweak the messaging on the RSVP form to let people know this will happen.
• Have attendees 'opt-in' to exposing their email with a checkbox on the RSVP. I have a feeling this wouldn't work very well.

My suspicion is that most people don't care as much about their email getting revealed as Bridge Troll thinks they do, so we should probably just implement that 'reply all' feature (if feasible) at least. But who knows!

[kmolo]

I'm less concerned about reply-all with those who sign up as students, but, for those who sign up as volunteers, there (for us) is usually a need to connect folks who will be teaching together, some who could attend the teacher training & some who couldn't.

We're still experimenting with our curriculum, so it helps to have the sub-groups chat about their plans before the day of the workshop, so they can look over code beforehand.

---

I think, if organizers/emailers are given a checkbox to turn on a reply-all option, they'll use it judiciously. A separate question is how difficult this would be to implement.

And then would it be actual emails, as it is now (I as the emailer am not anonymized, which surprised me...privacy, except for organizers)? Or would it be the two-way anonymization like Craigslist uses?

---

On the point of privacy for the organizer: previously I would send emails from our mobilebridge email, not my personal email. It would be nice to have a reply-to email, instead of having the organizer's personal email exposed. However, one can always create a junk email for Bridgetroll usage.

[kmolo]

Looking at this again (when revisiting https://github.com/railsbridge/bridge_troll/issues/438)