Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
There is a desire to add multiple choice proposals to politeia. First, we need to delineate that there are two types of multiple choice proposals.
The process to create a master proposal and create links in a fair and transparent way is complex and will include many steps.
The proposal shall be stored in d with the
The RFP shall be published before it can be linked to.
The Pi admins and the author of the RFP shall receive a notification of linking.
The user shall receive a censorship token indicating that it attempted to link the proposal to a RFP. This censorship token shall be user and third party verifiable to prove submission.
Once a proposal is set as a link it CANNOT be undone.
The GUI shall link to the rejected proposals so that users can see what was rejected. Note that this is the reason why proposals MUST be linked prior to publishing.
Authors of linked proposals have up to the
The RFP shall offer the linked proposals as options to vote. This means that when the vote is constructed the vote bits shall be machine created from the current status of the link journal. The vote bits shall contain a hardcoded
If there is a tie the entire vote is considered failed and human action is required to resolve this. An example of what could be done is creating a new proposal that only links the tied options and start a new vote. It is impractical to encode these rules in Pi and since this is an unlikely scenario human intervention is a fine solution.
There are a lot of moving parts in this idea but it probably is as simple as we can keep it. Let's start the debate in this issue.
I have some specific comments about the implementation, but first, I want to put this work into context of the bigger picture to see if we're on the same page since it will likely effect how the RFP proposal is implemented. This is how I imagine Politeia working eventually.
Is this along the lines of what you're thinking as well?
Yes, this is exactly what I was thinking. One thing to note is that I am not convinced we need the first two options yet but this fits exactly into what I tried to describe with the RFP type.
What I typed up is only the third option.
I hand waved the metadata streams and we will have to agree on some sort of design if we agree in principle on the process.
I think the use cases @lukebp outlines are solid.
With the RFP type proposal, it would often be the case that the RFP itself is to be voted on. This is what is happening with the MM proposals, there is an RFP proposal to determine if we should go ahead and vote to potentially select one of the candidate proposals. This is probably just an issue of nomenclature (need to be clear what an "RFP proposal" is). In the outline above it seems like there would often be a "should we do an RFP?" proposal before the "RFP proposal".
My view is that the winning proposal (one with the highest yes - no score) should still have to satisfy the usual quorum and approval requirements in terms of the votes cast on that specific proposal.
I don't understand why non-voting proposals would be used in this case -- the idea is to vote and determine the winning proposal after all. Can you please explain?
@al-maisan you would be voting on the multiple choice RFP proposal. Each voting option would correspond to a non-voting proposal. So you would vote once on the RFP instead of voting yes/no on each individual proposal that was submitted to the RFP. This doesn't seem to be the case anymore though.
It should be possible to set
What is the reason for this limitation?
An RFP participant could decide to exit the RFP (before the vote) and convert to a standalone proposal. What matters is that the RFP set is not changed after the group vote starts.
Further, what if one of the RFP participants desides to disengage? They are better allowed to remove themselves from the RFP group before voting starts, to prevent voters from accidentally voting for a dead proposal.
I don't follow why this requires linking to RFP before publishing the participating proposal. What users must be really shown in the RFP is the exact history of links, accepts, rejects and unlinks (among other historical entries). Does it matter if the link happened before or after the publish?
I really like this, it creates a stronger contract "This RFP accepts submissions until date X, and Pi won't allow us to start the vote earlier".
Speaking of identifiers:
Anyways, I think the ability to vote for multiple competing proposals is better because it yields more information and allows for analysis like yours. It's interesting to see when stakeholders are okay with e.g. "any of these two options, but not this third one".
Actually these are two very different voting dynamics that need a closer look.
Fully agree, looking at the results of the MM RFP vote seeing i2 above 60% shows that the stakeholders really want it.