Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clubhouse management of email lists #812

Open
wsanchez opened this issue Jan 25, 2021 · 8 comments
Open

Clubhouse management of email lists #812

wsanchez opened this issue Jan 25, 2021 · 8 comments
Labels
Feature New feature/functionality
Milestone

Comments

@wsanchez
Copy link
Member

It would be spiffy if the Clubhouse could sync emailed list memberships (currently that means in Google Groups) with Clubhouse data such that team lists correspond to team roster in the Clubhouse, and email addresses in the Clubhouse are used, so we can map list membership more readily back to actual Rangers.

@wsanchez wsanchez added the Feature New feature/functionality label Jan 25, 2021
@wsanchez wsanchez added this to the Later milestone Jan 25, 2021
@wsanchez
Copy link
Member Author

I'm pretty sure we can find an API to apply a membership list to Google Groups periodically or on demand for this. In this scenario, I would not want to allow editing on the Google Groups side, since that would presumably get overwritten.

@wsanchez
Copy link
Member Author

I would want to be able to say everyone in position X is on list Y, but we also have oddballs like like Allcom (opt in), -announce (all active Rangers), and the like.

@Roslyn-gh
Copy link

Roslyn-gh commented Jan 25, 2021

I would want to be able to say everyone in position X is on list Y, but we also have oddballs like like Allcom (opt in), -announce (all active Rangers), and the like.

I'd like to think through how we can keep Allcom opt-in, but either only using the email address used in the Clubhouse, or with Display Name = handle. I suppose we can periodically go through the list and request anyone with a wacky display name to update it, but if this is something we can do automatically as part of this project, that would be easier. The problem that I'm trying to solve here is preventing Ranger Choochy from signing up to Allcom five times under different email addresses, and then being impossible to kick off.

@wsanchez
Copy link
Member Author

My thinking there is that you check a box in the Clubhouse and then you get added with your Clubhouse email and, if possible, with your handle. Google Groups may not give us much control of the display name, though. But you shouldn't have to look at Google Groups at that point any more, because the Clubhouse with have the authoritative list memberships.

@Roslyn-gh
Copy link

Yep, that would solve it.

@flwyd
Copy link
Contributor

flwyd commented Jan 26, 2021

Some thoughts:

  • Group membership sync would be valuable, particularly since the new Groups UI doesn't let admins set member display names.
  • Google Groups API is at https://developers.google.com/admin-sdk/directory/v1/guides/manage-group-members
  • I'd rather not conflate Clubhouse positions (primary purpose: scheduling permissions) with mailing list membership (primary purpose: communication).
    • There are mailing lists that don't have matching positions, e.g. cadres and cross-team lists.
    • There are mailing lists that permit people without a corresponding position in special circumstances, e.g. retired vintage rangers can stay on Allcom, a Council member might be on a team's list without holding that team's position, an emeritus member of a team might be welcome to remain on the mailing list to provide historical wisdom…
    • Rangers can be removed from a mailing list but still retain the position (maybe this just applies to Allcom).
    • Are there any Ranger lists that allow non-Ranger members? I think ranger-tech-team-list had some, though maybe the ones still on the list have a Clubhouse account by now.
  • This might be a good opportunity to introduce the "Team" data model that I've considered in the past. A team has a roster and has managers (e.g. cadre members) who can add people to the team. Positions can be configured to be granted to all current members of a particular team (streamlining, e.g., the "Bucket just passed Green Dot mentorship, give them all the right positions" challenge). Maybe a team can have an associated email group.
  • Some folks may use a different email address for Clubhouse access and for mailing lists. (For example, I use my @burningman.org address for email but my @trevorstone.org address to sign in to the Clubhouse.) We want everyone to use their Org account for Ops Team and cadre group memberships; do we also want to force new cadre members to switch their Clubhouse login?
  • If someone changes their email address in the Clubhouse should we automatically change their list subscription address? Is this what people expect?
  • Do we want to let folks use different addresses for Allcom vs. Ops lists? Subscribe to Allcom from multiple addresses? (I have two addresses subscribed to allcom, since I didn't unsubscribe my old one after getting an Org account.)

@mikeburg
Copy link
Contributor

Some thoughts:

  • This might be a good opportunity to introduce the "Team" data model that I've considered in the past. A team has a roster and has managers (e.g. cadre members) who can add people to the team. Positions can be configured to be granted to all current members of a particular team (streamlining, e.g., the "Bucket just passed Green Dot mentorship, give them all the right positions" challenge). Maybe a team can have an associated email group.

Phil and I were chatting about a team concept a few weeks back when we were trying to determine who should retain the Login Management Year Round role versus relocating to LM On Playa. My vote would be have a Clubhouse team also include a mailing list association.

  • Some folks may use a different email address for Clubhouse access and for mailing lists. (For example, I use my @burningman.org address for email but my @trevorstone.org address to sign in to the Clubhouse.) We want everyone to use their Org account for Ops Team and cadre group memberships; do we also want to force new cadre members to switch their Clubhouse login?

@wsanchez you were complaining about Ops members not using their BM accounts in the Clubhouse the other day. Perhaps Council should consider a new policy of asking Ops members to avoid using their personal accounts.

  • If someone changes their email address in the Clubhouse should we automatically change their list subscription address? Is this what people expect?

Yes, people do expect their mailing list subscriptions to be updated as well. Text was included on the Personal Info page to alert folks to the fact the Clubhouse will not update their subscriptions when the email address is updated in the Clubhouse.

  • Do we want to let folks use different addresses for Allcom vs. Ops lists? Subscribe to Allcom from multiple addresses? (I have two addresses subscribed to allcom, since I didn't unsubscribe my old one after getting an Org account.)

Other than laziness/forgetfulness, what would be the purposes of having multiple addresses for the same mailing list?

One edge to keep in mind - the use of Plus Addressing / Subaddressing email accounts.
https://en.wikipedia.org/wiki/Email_address#Subaddressing

@wsanchez
Copy link
Member Author

OK yeah I think of positions as teams, because they associate with people, but I can see that in the Clubhouse, it's about scheduling, so I agree that introducing a concept of teams, and positions associate with team instead of or in addition to people would be an improvement.

I think the org email thing is a separate matter. It's related, but I don't want to rathole on it here.

I don't think we need to support multiple emails on lists, or this email for one list and that one for the other, etc. We should keep this simple and solve that problem only if there is a compelling and at least somewhat common use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature/functionality
Projects
None yet
Development

No branches or pull requests

4 participants