ssbc / scuttle-poll

3 stars 1 forks source link

Data types / scheme questions #7

Closed mguentner closed 6 years ago

mguentner commented 6 years ago

Since everything is still in flux here, here are some thoughts how the data model might be improved before integrating scuttle-poll into applications.

I suggest to move most of pollDetails into a seperate objects. So instead of writing choices = [ 'one', 'two', 'three' ]

creating

choiceOne = {
  poll: '&mwILr7kd1Tug/4vX5nW6YRRhyununwwO5cF6jbiSyoA=.sha256',
  value: 'one'
}

choiceTwo = {
  poll: '&mwILr7kd1Tug/4vX5nW6YRRhyununwwO5cF6jbiSyoA=.sha256',
  value: 'two'
}

choiceThree = {
  poll: '&mwILr7kd1Tug/4vX5nW6YRRhyununwwO5cF6jbiSyoA=.sha256',
  value: 'three'
}

where each vote then votes for a choice blob instead of the actual choice value.

myVote = {
  choice: '%56noaVSxaiDyBa7EVjMk3sGb87LL9lKjFtR5R46y3PA=.sha256' // choiceThree
}

The application / the user would then decide which choices are valid choices, in the simplest form all choices that the creator of the poll created or even all choices found that reference the poll.

This method also allows for suggestion / option / proposal gathering with a suggestion and a voting / decision period.

During the suggesting period users can add suggestions to a question / poll, i.e. "What projects should be funded in the next grant cycle"

So users might add the suggestions "A rust server", "A go server", "Colorful drawings". Once the suggestion period is over, users then vote for another time span (the voting period) on all suggestions gathered during the suggesting period with whatever voting method is used. This could be choose one, majority vote, dot vote or systemic consensus.

(@mixmix already suggested something similar in #4)

Full disclosure: I had the idea of implementing the systemic consensus method using ssb and then found scuttle-loomio / scuttle-poll in the making. More information on the method: https://systemicconsensus.blogspot.com

pietgeursen commented 6 years ago

@mguentner Thanks heaps for your input. Who are you on scuttlebutt?

Just to loop back on what I'm hearing from you:

Am I missing anything?

My initial responses:

This method also allows for suggestion / option / proposal gathering with a suggestion and a voting / decision period.

I'd rather not wrap this into the data model just yet. We do this already by proposing + discussing in post messages.

I think there are some weird subjectivity problems you get as well. If many people in a wider network create choices, not all of them will be visible to everyone. Maybe out of order messages helps with this, I think it does. Still I like the idea that if you have the poll message, you have all you need to vote on it.

This isn't a no, it's a maybe later. We've got a lot of ground to cover and I think this adds some complexity I'm not sure is needed for a first pass.

I'll definitely keep your proposal in my head as we're designing and see if / when it makes sense to slot it in.

Thanks again, Piet

mguentner commented 6 years ago

users should be able to add options to a poll during a suggestion period and that should be supported in the data model.

Yes, if the poll (I will stay within the terminology of scuttle-poll) allows it.

You (as the author) could also create a new poll with closesAt = Date.now() + 7.days. As an option you do not check

Then you create your choices and let people vote.

But there is also:

You (as the author) can also create a new poll with closesAt = Date.now() + 7.days. But you do check

and I add a fourth choice.

For both cases:

When someone is viewing the poll, scuttle-poll will remove invalid choices (not allowed) or invalid votes (not within the range of valid choices, too early, too late) when calculating sums and percentages.

This is basically the extended, more versatile version of the current behavior of scuttle-poll.

My intent is to have a suggestion period where users can create new choices / proposals and then a second voting period. As ssb is append only, I suggest the above to make something like this possible.

your proposed solution is to move choices out into separate objects that can be referenced by a poll or voted on by a participant.

No. The choices reference the poll, the votes in turn reference the choice.

Badass UTF8 / ascii UML diagram where A <--- B means B references A by its content / hash:


                       ↙-------- [ vote, signed by joe ]
[ POLL ] ←----- [ choice A ] ←-- [ vote, signed by jane ]
  ↑     ↖ ----- [ choice B ] ←-- [ vote, signed by dave ]
  |------------ [ choice C ] 

Results of POLL:

I'd rather not wrap this into the data model just yet. We do this already by proposing + discussing in post messages.

So you are suggesting to first talk about all the options in an open context without a workflow and then someone who feels obliged / is designated summarizes all possible options into a fixed set of choices?

I think there are some weird subjectivity problems you get as well. If many people in a wider network create choices, not all of them will be visible to everyone. Maybe out of order messages helps with this, I think it does. Still I like the idea that if you have the poll message, you have all you need to vote on it.

Hmm...I get your concern but I feel that people who decide on important matters (not do you like :cat2: or :dog2: ?) should know and therefore follow each other. I am thinking more in a community decision (think village) context and not necessarily in the current global scale with multiple sub-networks / pubs joined together by luck :)

This isn't a no, it's a maybe later. We've got a lot of ground to cover and I think this adds some complexity I'm not sure is needed for a first pass.

Sure. I get the issue with complexity. I still haven't figured out what loomio offers and what scuttle-poll managed to "transfer" from a data model perspective. Loomio uses a traditional DBMS with rails, so I guess that authors are able to do CRUD operations on their polls / choices. With the current data model only CRUD is possible. With my addition the author / others can at least add new choices.

I don't want to over-complicate things but changing things once they are used in e.g. Patchwork might be way more stressful. Since ssb requires a whole different data model (append only, crypto instead of server authority etc.) we could also do user stories to properly set up the model.

edit: "I am the author and I want to add another vote" will never work cleanly with the current model. "I am the author of the poll and I want to add another choice" will never work cleanly with the current model.

crypto magic (disregard): ccc72e7f305706f29006b9951deec2b2a4d729dea5ca0ac21cb8e939ebacd313

pietgeursen commented 6 years ago

"I am the author of the poll and I want to add another choice" will never work cleanly with the current model.

This is intentional. I was talking with @mixmix about this. Loomio has the strong opinion that once a poll is created, the only thing that is editable is the closing time. If a poll is editable then looking back on conversations and other people's votes can be really misleading.

If you messed up and left out an option then you scrap the old one and start a new one.

So you are suggesting to first talk about all the options in an open context without a workflow and then someone who feels obliged / is designated summarizes all possible options into a fixed set of choices?

Yes. Having an engaged human acting in a facilitator role is a good thing.

mguentner commented 6 years ago

Sounds good. Thanks to you and @mixmix for the explanation. Let's leave this for now. The suggestions above can be added later as well. :+1: