-
Notifications
You must be signed in to change notification settings - Fork 388
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
MSC 3381: Added new attribute show_participants #4022
MSC 3381: Added new attribute show_participants #4022
Conversation
…ticipants Update 3381-polls.md: Added new attribute show_participants
@@ -41,6 +41,7 @@ To start a poll, a user sends an `m.poll.start` event into the room. An example | |||
"m.poll": { | |||
"kind": "m.disclosed", | |||
"max_selections": 1, | |||
"show_participants": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature generally seems valuable to me but I think we might need to reconsider naming – possibly holistically – because the meaning of this option seems easy to confuse with the function of m.disclosed
/ m.undisclosed
. It's already slightly confusing to me right now that m.undisclosed
also "discloses" results but only once the poll is ended and I feel like adding another option related to visibility into this might cause further confusion. @turt2live curious what you think about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Johennes the naming definitely needs work on the MSC. "Disclosed" and "undisclosed" were what the MSC settled on after many hours of discussion, but do indeed still feel 'wrong' in many respects.
If folks have ideas on better naming to match the semantics, please leave them as comments on the MSC.
Thanks for the suggestion! Thinking about this sort of change ended up being more involved/complicated than I originally thought - I've moved it to a thread on the MSC itself to get wider input from people who might be subscribed to that MSC specifically. Largely, my concern here is that the MSC leaves this as an implementation detail, but that might not be the correct way to approach this. The leading question being whether it's a "problem" if some clients show per-voter results while others don't, in the same room. For many environments this might not be a concern as they control the clients being used, but for a general purpose room there could be dozens of different clients and therefore dozens of different behaviours. I'm going to close this for now, but please feel free to comment on the thread. I'd generally encourage implementing this change regardless of the outcome on the thread to help build some potential use cases (when it feels important to know who voted for what, and when it feels important to not know). If the thread ends up wanting this feature, we'll incorporate this PR or something like it. |
Added a new attribute informing clients that they not only present the result of polls but also how each individual participant has voted. This can be very useful in many situation where room members will start a vote.