Open cpruitt opened 3 years ago
Related for some extra context #32
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
away_until
being in the past
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.