From c2e82696d1a5056cf5451ded6a3da5e7cfbdb267 Mon Sep 17 00:00:00 2001 From: toadlyBroodle Date: Sat, 25 Mar 2023 12:49:56 +0900 Subject: [PATCH] add clarifying requirements for voting- tallying-clients --- 69.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/69.md b/69.md index 11ece7cd..456eadd7 100644 --- a/69.md +++ b/69.md @@ -65,6 +65,7 @@ A voting client: * SHOULD NOT allow submission of zap events with amounts greater than `value_maximum` (when specified) * SHOULD NOT allow submission of zap events with amounts less than `value_minimum` (when specified) * SHOULD NOT allow submission of zap events after `closed_at` time (when specified) +* SHOULD hide tally results, until after a user has zapped the note ## Zap vote format @@ -109,8 +110,8 @@ A tallying client: Additionally, a tallying client: * MUST display the distribution percentages, from the tally total, for each vote option tally * MUST display the `consensus_threshold` (if specified) relative to the winning vote percentage -* SHOULD publicly blind results until after a user's vote has been received -* SHOULD publicly display results after the `closed_at` time has passed (if specified) +* SHOULD show tally results to all note zappers, even if they haven't voted on an option +* SHOULD publicly show results after the `closed_at` time has passed (if specified) * MAY display the counts of zap events received for each option, along with other poll statistics Strict adherence to these requirements should enable a standardized means of quantitatively assessing the distribution of opinion regarding a poll's content amongst poll participants, determining a winning outcome, and possibly achieving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.