MSC3381: Polls (mk II)

[turt2live]

Rendered

Element Web Implementation:

• https://github.com/matrix-org/matrix-react-sdk/pull/7088 (rendering)
• https://github.com/matrix-org/matrix-react-sdk/pull/7166 (limits)
• https://github.com/matrix-org/matrix-react-sdk/pull/7158 (voting)
• https://github.com/matrix-org/matrix-react-sdk/pull/7202 (complexities of multi-device voting)
• https://github.com/matrix-org/matrix-react-sdk/pull/7233 (above part 2)
• https://github.com/matrix-org/matrix-react-sdk/pull/7269 (mechanics of showing results)
• https://github.com/matrix-org/matrix-react-sdk/pull/7305 (ending polls)

Element iOS Implementation:

• https://github.com/vector-im/element-ios/pull/5202 (rendering)
• https://github.com/matrix-org/matrix-ios-sdk/pull/1295 (mechanics)
• https://github.com/vector-im/element-ios/pull/5100 (creation)
• https://github.com/vector-im/element-ios/pull/5378 (undisclosed and edits)

Synapse implementation:

• TBD - needed for push rules.

Further work:

• events-sdk: https://github.com/matrix-org/matrix-events-sdk/pull/1
  • Element Web: React, JS

Preview: https://pr3381--matrix-org-previews.netlify.app

[jfowl]

I don't have deep knowledge about the spec as a whole, so please excuse if this is redundant:

What about lenght limits for the fields? e.g. id and answer? I can imagine, that this could break something clientside.

[turt2live]

@jfowl Opening line comments on the diff are best so feedback can be captured and responded to.

Length limits aren't yet in this MSC, but should be before it's ready for FCP.

[turt2live]

@skolmer can we get that posted as threads on the diff please? It's hard to provide feedback from the comments here.

[turt2live]

The core concepts of this MSC have been implemented in Element Web, iOS, and Android. I've linked the PRs for web and iOS as those are what I have handy.

[turt2live]

putting this back in needs-implementation to ensure the push rules are viable.

[peter-scholtens]

• Once multiple selection is added, I suggest also to implement Ranked Choice Voting. This could be defined by the following order in the GUI, like 1st choice, 2nd choice etc. but it also require an undo option or at least modifying the previous made ones to change the order. This makes the outcome more agreeable for everyone.

• Another wish would be to make a planning option: a group of voters choose for each option if they have time in their agenda or not. If Alice wants to lunch on Mon- / Tues- / Wednesday and Bob wants to lunch on Tues- / Wednes- / Thursday, then they agree on two options, Tuesday and Wednesday. The final option can be set if one of them withdraws an already made vote on a option of the current outcome (optionally only the original poster ca do this?).

[turt2live]

This MSC got implementations back before extensible events changed to using content blocks instead of subevent types - I'm counting those implementations as valid because there's no major functional difference between that draft and the latest draft.

Of course, SCT members are welcome to disagree and require implementation anyways. The earlier draft can be seen here.

[turt2live]

This MSC has also been open for quite a while, and it's dependencies have all landed. I'm very inclined to push it through the next stages onto FCP, though because it relies on Extensible Events it cannot be merged to the spec yet. Clients can use stable prefixes once the MSC passes FCP though.

If folks have objections/concerns, please raise them urgently. It'd be nice to have this collecting checkboxes in the next week or so before we forget to call FCP on it again :)

---

FCP on this also unblocks some dependent MSCs, like https://github.com/matrix-org/matrix-spec-proposals/pull/3930 and https://github.com/matrix-org/matrix-spec-proposals/pull/4013.

[turt2live]

As previously mentioned, this MSC already has its blockers cleared and hasn't received any feedback on some of the outstanding items.

I'm putting this forward for being accepted (but not merged, as per Extensible Events generally):

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• [x] @dbkr
• [x] @uhoreg
• [x] @turt2live
• [ ] @ara4n
• [ ] @anoadragon453
• [x] @richvdh
• [x] @erikjohnston
• [x] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[mscbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

will update the MSC text with the minor (non-blocking) changes before merge.

[uhoreg]

will update the MSC text with the minor (non-blocking) changes before merge.

@turt2live it looks like this got forgotten?

[turt2live]

It's not forgotten, but heavily delayed 😭 I'm hoping to take a look in the short term, or at least before the year ends.

[turt2live]

2ff98703398d1cc871147bb26683b573b0ce6a49 addresses the minor review feedback which came up during FCP discussions. As it didn't block FCP and the threads appear to have conclusions, I've incorporated those conclusions into the proposal text.

Merging otherwise per https://github.com/matrix-org/matrix-spec-proposals/pull/3381#issuecomment-1657264640

[turt2live]

Like https://github.com/matrix-org/matrix-spec-proposals/pull/3930#issuecomment-1686756885 , this is blocked on the wider system actually landing in the spec itself.