Skip to content

[Meta] Async straw polls #9438

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

Open
LeaVerou opened this issue Oct 4, 2023 · 8 comments
Open

[Meta] Async straw polls #9438

LeaVerou opened this issue Oct 4, 2023 · 8 comments
Labels

Comments

@LeaVerou
Copy link
Member

LeaVerou commented Oct 4, 2023

A common way we resolve certain issues where there are several distinct alternatives is by doing a straw poll.

During a telcon, the straw poll is done by assigning each of the options a letter or number, describing it clearly, and having people type their answer into IRC. For example, here's a recent straw poll on the contrast-color() MVP.

However, it is unclear how we can do straw polls async. This would not only be useful for resolving on things, but even just as a quick way to see where everybody stands on an issue, which would be incredibly useful especially on bikeshedding issues.

One way is the awkward "For Option 1 use a 👍🏼 react, for Option 2 a ❤️ react" etc, but that's hard to parse, disconnected from the actual options, and there is no way to distinguish WG member votes from votes by people who are passing by.

Since every WG member has permissions to edit everyone else's comments, I propose the following:

One member posts the straw poll, e.g. for #9102 it could look like this ( actual poll ):

Async Straw Poll

Please edit this comment, add your at-username next to the option you support and update the count next to it. Votes have been pre-added for people that have already expressed a clear preference.

  1. Abstain (0):
  2. text-wrap-allow: wrap | nowrap (2): @astearns @LeaVerou
  3. text-wrap-mode: wrap | nowrap (2): @nt1m @vmpstr

Ideally, the heading could be a link to a wiki entry that explains this process, but for now it can be to this issue.

If we do want to allow non-members to vote, we can combine it with reaction votes. We did this in the field-sizing vs form-sizing straw poll:

Async Straw Poll

Please edit this comment, add your at-username next to the option you support and update the count next to it. Votes have been pre-added for people that have already expressed a clear preference.

If you don't have permissions to edit this comment, please add your vote using reactions (emoji indicated in the beginning of each option)

  1. 👀 Abstain (1): @vmpstr
  2. ❤️field-sizing: content | fixed (5): @LeaVerou @mirisuzanne @astearns @bfgeek @chrishtr
  3. 👍 form-sizing: content | fixed (2): @frivoal @tabatkins

I worried a bit about editing conflicts (i.e. someone else edited a comment after you clicked "Edit" and before you submitted) but it appears they are not destructive:

image

Sure, it would be annoying if everybody is trying to vote at once, but at least it's not destructive.


Edit:

Existing async poll pilots

@LeaVerou LeaVerou added the meta label Oct 4, 2023
@fantasai
Copy link
Collaborator

fantasai commented Oct 4, 2023

And maybe as an escape hatch, if someone doesn't have write permissions because of some admin error, that person can add a comment asking someone to edit their response in.

@nickserv
Copy link

How about GitHub Discussions with voting restricted to WG members?

@frivoal
Copy link
Collaborator

frivoal commented Oct 11, 2023

We should also include a link to all the open straw polls in emails announcing the agenda for the next synchronous meeting, to help make sure people notice them.

Not that we necessarily need to discuss them in the synchronous meeting, but just as a convenient place to inform/remind people of what homework they're supposed to do.

@LeaVerou
Copy link
Member Author

LeaVerou commented Oct 11, 2023

@nickmccurdy

How about GitHub Discussions with voting restricted to WG members?

If it's possible to restrict to WG members, and it's possible to see who voted, that's a great idea! From a quick search, it appears that voters are not visible? That would rule this out I’m afraid.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Review async poll results.

The full IRC log of that discussion <fantasai> Topic: Review async poll results
<fantasai> github: https://github.com//issues/9438
<fantasai> lea: We have a few more votes than we did... let me try to pull up the links
<fantasai> https://github.com//issues/7542#issuecomment-1747805436
<fantasai> https://github.com//issues/9102#issuecomment-1747785298
<fantasai> lea: One poll was about sizing form controls by contents
<fantasai> lea: we have 10 votes in that
<fantasai> lea: I'll leave up to you whether that was a success or not
<fantasai> lea: I still wouldn't say there's exactly consensus
<fantasai> s/10/11
<florian> q+
<fantasai> lea: Plus 25 votes from non-WG members
<fantasai> lea: there does seem to be a clear consensus there for `field-sizing` although ppl are proposing other names
<fantasai> lea: but from non-WG members strong preference `field-sizing`, also from poll that jensimmons posted
<fantasai> Rossen_: sounds like this suggests field-sizing
<TabAtkins> yup, field-sizing looks pretty decisive to me
<fantasai> Rossen_: Looking through comments and engagement from non-members, curious... how much additional complexity would such async polls add to us?
<fantasai> Rossen_: additional names are being suggested, this seems polls + continued conversation
<fantasai> fantasai: I think helps actually
<fantasai> https://twitter.com/csswg/status/1711816620534886464
<jensimmons> q+
<fantasai> fantasai: good to get the comments from authors, and ideas also
<plinss> q+
<Rossen_> ack florian
<Rossen_> ack jensimmons
<fantasai> fantasai: I think we got the information we needed, and higher quality than if we only had poll results themselves
<fantasai> jensimmons: Doing polls, whether ourselves or externally, these are not scientifically valid
<fantasai> jensimmons: if you study research and stats, there are so many flaws
<lea> +1, the point is to get to the best option, not to be rigid
<fantasai> jensimmons: so it means we can't lock ourselves into assuming that a poll is the truth. We still have to use our humanity. I like mixing differnet polls. We get valuable information.
<fantasai> jensimmons: we just need the quick way to get many more people involved in the conversation
<lea> q?
<Rossen_> ack plinss
<fantasai> jensimmons: very valuable in helping us get to the wisest choice
<florian> florian: voted for the minority choice, but no objection with the majority view
<TabAtkins> +1, point is to get a quick answer from a larger quorum, and see if there is a wide consensus. No different than our straw polls, which also still need interpretation.
<fantasai> plinss: one comment I saw was, why isn't this part of width/height properties
<fantasai> iank_: We covered this previously, basically lots of times when you trigger min/max content sizing
<fantasai> iank_: and lots of quirks tied into these input elements that we wanted to disable
<fantasai> iank_: so that's why we thought a switch on the algorithm was best
<florian> +1 to jensimmons
<fantasai> iank_: but we did discuss previously
<fantasai> Rossen_: Sounds like this is good input, and additional commentary although maybe distracting is also good signal
<TabAtkins> plinss, https://twitter.com/tabatkins/status/1712147099951968699
<fantasai> Rossen_: So next question is, can we take the results and resolve?
<fantasai> Rossen_: do we just accept the results?
<fantasai> florian, jensimmons, fantasai: no
<chrishtr> q+
<lea> data-informed instead of data-driven :)
<fantasai> jensimmons: the poll isn't determinitive, it's informative, we still make the decisions as usual
<Rossen_> ack chrishtr
<fantasai> fantasai: We should take each issue, and in consideration of the poll, make the decision
<fantasai> chrishtr: Yes, let's take each issue
<florian> The proposal is: field-sizing: content | fixed

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Async Polling, and agreed to the following:

  • RESOLVED: Async polls should allow emoji reactions
  • RESOLVED: Edit top comment to link to the poll
  • RESOLVED: Open polls should be listed at top of agenda / proposed agenda emails as a reminder
The full IRC log of that discussion <fantasai> Topic: Async Polling
<fantasai> Rossen_: between the two different polls, if we want to do this going forward, what would be the process? what would work best?
<fantasai> lea: I think what we did with emojis in second one worked well
<fantasai> lea: downside is we're limited to 8 options, but that's probably fine, I don't think we've needed more
<fantasai> lea: main issue is, how do we make sure that the poll is easy to find?
<fantasai> lea: adding to agenda helped, but maybe have a policy to add it to the first post, or adding a link from first post
<florian> q+
<fantasai> lea: since discussion continues (which is great) makes harder and harder to find the poll
<fantasai> lea: Counting votes is manual, so that gives an incorrect count -- but I was able to spot easily. Still can happen
<dbaron> for the record, those writing polls may find this list of github reaction emoji shorthands useful: :+1 :-1 :grin :tada :confused :heart :rocket :eyes
<Rossen_> ack florian
<fantasai> florian: I would suggest list of open polls at top of the agenda, so that people looking at agenda can see that as their homework easily
<Rossen_> ack florian
<fantasai> fantasai: agree, and for counts, we can not have counts until we close the poll. People can count.
<fantasai> github: https://github.com//issues/9438
<fantasai> Rossen_: we can continue to refine
<fantasai> fantasai: I like Lea's idea to edit top comment with a link to the poll
<fantasai> Rossen_: let's draft up the steps into the meta issue
<fantasai> lea: if we capture these as resolutions, they'll be automatically captured in the issue :)
<fantasai> RESOLVED: Async polls should allow emoji reactions
<fantasai> RESOLVED: Edit top comment to link to the poll
<fantasai> RESOLVED: Open polls should be listed at top of agenda / proposed agenda emails as a reminder

@nickserv
Copy link

@nickmccurdy

How about GitHub Discussions with voting restricted to WG members?

If it's possible to restrict to WG members, and it's possible to see who voted, that's a great idea! From a quick search, it appears that voters are not visible? That would rule this out I’m afraid.

@LeaVerou Ah yes, forgot about that. 😦 If you need to use GitHub you could use 👍 and 👎 reactions. The UI appears to truncate them, but the data may still be accessible through the API. You can also do similar reaction based polls on Discord, but it always lets you see all reactions.

@LeaVerou
Copy link
Member Author

@nickmccurdy

How about GitHub Discussions with voting restricted to WG members?

If it's possible to restrict to WG members, and it's possible to see who voted, that's a great idea! From a quick search, it appears that voters are not visible? That would rule this out I’m afraid.

@LeaVerou Ah yes, forgot about that. 😦 If you need to use GitHub you could use 👍 and 👎 reactions. The UI appears to truncate them, but the data may still be accessible through the API. You can also do similar reaction based polls on Discord, but it always lets you see all reactions.

No way to restrict reactions to members, though we do use them for non-member voting (see the second such poll). We do not use Discord, so adding another tool to the mix just for polls seems suboptimal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants