You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We might want to consider adding a per-channel ignore list for slack handles that exist in the channel but should not be part of the pairings. The use case here is someone who is acting as an administrator or facilitator who has reason to monitor questions in the channel but does not, personally, want to be part of the pairings.
I think we could potentially handle for the User model in a slightly different manner based on current usage.
Right now, we're using the slack user id as the in-db reference for a particular individual. That could end up being, at least conceptually
user_channel_visibilities
- slack_channel_id => string
- slack_user_id => string
- visibility => datatype to avoid being a boolean (hidden | visible | away)
- away_until => date
The idea with away_until is that a date could be specified for when to become visible again during the matchmaking. The visible state would be more of a virtual/implicit state based on
We might want to consider adding a per-channel ignore list for slack handles that exist in the channel but should not be part of the pairings. The use case here is someone who is acting as an administrator or facilitator who has reason to monitor questions in the channel but does not, personally, want to be part of the pairings.
From @tuxagon:
I agree with the preference for #1. This feels like we're uncovering the need for a
User
model that can be looked up by slack ID.The text was updated successfully, but these errors were encountered: