Update voting icons and terminology

[Floppy]

Currently the -1 icon is a block, and the hand is a -1, and it's all a bit confusing depending on how you enter the symbols. Perhaps we oculd use some others.

Maybe ✅ for a positive vote, 🛑 for a block, and ⌛️ for an abstention.

This should probably be configurable somewhere in the app settings.

[tmtmtmtm]

I think some of this is down to what the votes actually mean, not just the symbols. For 'abstain' to score -1 rather than 0 is rather unexpected, and not what abstention usually means. A sensible set of defaults probably needs to offer the four options of +1, 0, -1, and complete block, and individual projects could disable any they don't want.

[Floppy]

Yes, that's a good point, that naming is confusing as well.

It's more like "upvote", "downvote" and "block", perhaps. I've never been convinced that formal abstention is necessary, but perhaps it could be a fourth.

[Floppy]

• yes: 🔼
• no: 🔽
• block/veto: 🛑 or ⛔️
• abstain: difficult, but perhaps 😑

[Floppy]

@philipjohn @openpolitics/core I imagine you will have opinions on this

[philipjohn]

I've been giving this a lot of thought and have some ideas.

To start with I think we should make 👍 == +1 and 👎 == -1 as that seems like the most simple and straightforward way to vote.

For the "veto" I think we should do several things;

• Use :stop_sign:
• Only contributors with X amount of accepted proposals can veto
• The veto is worth -10% of the number of contributors with voting rights (currently 4, based on 42 contributors)
• The veto should never be worth more than -10 to ensure its effective with a small bunch of contributors

What do folks think?

[Floppy]

Wikipedia has a list of consensus-building models, which look close to what we're doing here. I'm guessing that one of them is the same or very close, and we should try to match the proper terminology for what we're doing.

[Floppy]

Interesting idea @philipjohn to limit veto to higher-level contributors, and to auto-weight by contributor pool. That would auto-scale to the long tail. But if the limit was -10%, below 10 contributors, a veto will be the same as a downvote, and basically useless.

[Floppy]

Perhaps grant veto rights to the top x% of contributors, set per-project. Then you could adapt it to the shape of the participation tailoff and would be more effective at countering entryism.

[Floppy]

Oh, and my only concern with reusing the thumb symbols is that it would mean that old proposals in the existing manifesto wouldn't get counted the same way, and there wouldn't be a solid record. I'm more inclined to deprecate them, but still count them the same. Reckons?

[Floppy]

Reading wikipedia, I think we're doing almost exactly this one: https://en.wikipedia.org/wiki/Consensus_decision-making#Blocking, but with the ability to downvote as well, and a threshold for agreement that doesn't require unanimity.

[philipjohn]

Nice find on the Wikipedia list!

below 10 contributors, a veto will be the same as a downvote, and basically useless.

It'd be -10 because of this rule, no?:

The veto should never be worth more than -10% to ensure its effective with a small bunch of contributors

[philipjohn]

my only concern with reusing the thumb symbols is that it would mean that old proposals in the existing manifesto wouldn't get counted the same way

We already have this though, right? There are proposals that had a thumbs down but went in because at that point it wasn't a veto?

[Floppy]

I'll have to go back and look. At the moment I think it's still backwards compatible. In the early days we still tried to avoid downvotes; it was never a straight vote up or down with equal weight.

[Floppy]

@philipjohn on the minimum veto weight, I think I've misread something... can't quite parse what you mean, but I think we're on the same wavelength.

The veto should never be worth more than -10% to ensure its effective with a small bunch of contributors

So if you had 5 contrubutors, and one vetoed, how much would that veto be worth?

The veto is worth -10% of the number of contributors with voting rights (currently 4, based on 42 contributors)

So it would be worth -0.5, and can never be worth more than that. How can it be, in fact, anything other than -0.5?

[philipjohn]

Ohhh I see what's happened - it's my mistake. Where I said

The veto should never be worth more than -10% to ensure its effective

It should have said

The veto should never be worth more than -10 to ensure its effective

So, to use your example, with 5 contributors the veto would be -0.5, which is more than -10. Therefore, the veto would be readjusted to be -10.

A better way of saying it might have been;

The veto has a maximum of -10

Or even;

With fewer than 10 contributors, the veto is fixed at -10

Here's some more examples;

Contributors = Veto value 5 = -10 10 = -10 50 = -10 150 = -15 500 = -50

[philipjohn]

Also, the veto doesn't become less than -10 until we get 100 voters

[Floppy]

OK that makes a lot more sense :)

[Floppy]

I'm working on a branch to renaming all this stuff. If you think the public view is confusing, you should see the shit I've got in the code. I'm standardising on

• Agree (currently +1)
• Disagree (currently -1, known as "abstain" but really not)
• Block (currently -1000)

Abstain will be removed as a term, for now, as we don't support actual abstention. We can reintroduce it later if we want to.

[Floppy]

This will then make it easier to update to new icons, deprecating the old confusing ones.

Incidentally, abstention was cost-free for about a year - the upvote offset was added in https://github.com/openpolitics/votebot/commit/6b6f7c887b218e224ca5201047c39488fd6eb7d8

[Floppy]

Actually. In the code, I'm going to use:

• Yes
• No
• Block

because disagree would be moving from one meaning to another, and that's confusing as fuck. Yes and No are perfectly adequate.

[Floppy]

I could standardise on

• ✅ Yes
• ❎ No
• 🚫 Block

Those would work across both the votebot app (using fontawesome) and GitHub (using emoji).