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

MSC 3381: Added new attribute show_participants #4022

Conversation

arnfriedgriesert
Copy link

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.

@arnfriedgriesert arnfriedgriesert changed the title Update 3381-polls.md: Added new attribute show_participants MSC 3381: Added new attribute show_participants May 31, 2023
@yncyrydybyl yncyrydybyl requested review from turt2live and Johennes May 31, 2023 10:21
@@ -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,
Copy link
Contributor

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.

Copy link
Member

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.

@turt2live turt2live self-assigned this May 31, 2023
@turt2live
Copy link
Member

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.

@turt2live turt2live closed this May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants