Skip to content
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

[gui/www/d] Add multiple choice mechanism to select competing proposals #966

Open
marcopeereboom opened this issue Aug 6, 2019 · 7 comments
Assignees
Labels
Projects

Comments

@marcopeereboom
Copy link
Member

@marcopeereboom marcopeereboom commented Aug 6, 2019

Outline

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.

  1. A single proposal that has multiple options that the users can select. This issue is NOT going to solve this particular type of proposal. These proposals can be human-managed within the comments and common sense. This type will be added in the future.
  2. A proposal that links to other proposals where said proposals are the options. Thus there exists a master proposal that links to other proposals and the "others" are the voting options. This issue is going to propose a solution to this type.

The process to create a master proposal and create links in a fair and transparent way is complex and will include many steps.

Process

  1. Create the master proposal which we will call the RFP (Request For Proposals). This proposal can be distinguished from normal proposals by an additional optional field called LinkBy which is a timestamp that delineates the date by which links to it must have been completed. Fail to meet this deadline and the linked prop shall be rejected.

The proposal shall be stored in d with the LinkBy field set in the normal metadata. Since this field is optional if it isn't set it shall be considered a regular proposal. This will require several changes to the www and d API.

The RFP shall be published before it can be linked to.

  1. Create a regular proposal and link to the RFP token by setting the optional LinkTo field. The proposal is otherwise normal but can not be voted directly on. In d create a new metadata stream on the RFP that stores what proposals are linking to it.

The LinkTo field shall be set prior to the proposal being published and it shall be stored in the regular metadata stream as an optional field.

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.

  1. The admins or authors of the RFP can now accept or reject the link to the RFP. The acceptance/rejection of the link process shall be recorded in a new metadata stream that is a journal that keeps track of all linking actions over the lifetime of the process.

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.

  1. Voting can commence only after the LinkBy date has been reached and the RFP author authorizes the vote. Once authorized by the RFP author the Pi admins can in turn authorize the actual vote to commence.

Authors of linked proposals have up to the LinkBy date to retract their proposal. This shall be recorded in the journal.

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 No option so that users can reject all options.

  1. Once a vote completes the winner is determined by the quorum rules and the majority vote. All votes are counted towards the quorum. The option with the majority votes wins. This means that a vote can pass with, let's say 30%, of the total vote count.

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.

Notes

  • When displaying the RFP, version information of the linked proposals shall be displayed in the GUI. The GUI shall inform the users that there may be potential changes to the linked proposal.
  • The GUI shall display a prominent link to the RFP from linked proposals.
  • It may be a good idea to flip the linked proposals to read-only in order to simplify the UX.

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.

@lukebp

This comment has been minimized.

Copy link
Member

@lukebp lukebp commented Aug 6, 2019

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.

Building blocks:

  • Voting proposals
  • Non-voting proposals
  • RFP proposals
  • Ability to link proposals

Use cases:

  • Proposal authors giving updates.
    TeamA had a proposal approved by the stakeholders where they would be delivering work in milestones. They've completed a milestone and want to update the stakeholders with their progress and request that the milestone payment be unlocked. They would submit a non-voting proposal that linked back to the original proposal that was approved.

  • Proposal authors requesting additional funds.
    TeamA had a proposal approved where they would be delivering work in milestones. They've completed a milestone, but they went significantly over budget due to unforeseen complications. They want to request additional funds from the stakeholders that were not approved in the original proposal. They would submit a new voting proposal that linked back to the original voting proposal that was approved. The stakeholders would then vote on whether to approve the budget increase.

  • RFP proposal where multiple submissions are competing in a single vote.
    Multiple teams are competing for a single contract from the stakeholders. Somebody (most likely an admin but could be anyone) submits an RFP proposal. TeamA, TeamB, and TeamC create non-voting proposals that link back to the RFP proposal. The RFP goes up for vote where each voting option corresponds to a non-voting proposal that was linked.

Is this along the lines of what you're thinking as well?

@marcopeereboom

This comment has been minimized.

Copy link
Member Author

@marcopeereboom marcopeereboom commented Aug 7, 2019

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.

@RichardRed0x

This comment has been minimized.

Copy link
Member

@RichardRed0x RichardRed0x commented Aug 16, 2019

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".

Once a vote completes the winner is determined by the quorum rules and the majority vote. All votes are counted towards the quorum. The option with the majority votes wins. This means that a vote can pass with, let's say 30%, of the total vote count.

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.

@lukebp lukebp self-assigned this Aug 21, 2019
@lukebp lukebp added the feature label Aug 21, 2019
@lukebp lukebp added this to In Progress in pi Aug 21, 2019
@al-maisan

This comment has been minimized.

Copy link
Contributor

@al-maisan al-maisan commented Aug 31, 2019

* RFP proposal where multiple submissions are competing in a single vote.
  Multiple teams are competing for a single contract from the stakeholders.  Somebody (most likely an admin but could be anyone) submits an RFP proposal.  TeamA, TeamB, and TeamC create non-voting proposals that link back to the RFP proposal.  The RFP goes up for vote where each voting option corresponds to a non-voting proposal that was linked.

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?

@lukebp

This comment has been minimized.

Copy link
Member

@lukebp lukebp commented Sep 3, 2019

@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.

@xaur

This comment has been minimized.

Copy link

@xaur xaur commented Sep 12, 2019

It should be possible to set LinkTo by editing the RFP participating proposal after it is published. People do mistakes. RFP can appear after its participants, or people may forget to set the LinkTo field.

Once a proposal is set as a link it CANNOT be undone.

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.

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.

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?

Voting can commence only after the LinkBy date has been reached and the RFP author authorizes the vote.

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:

  • if p.LinkBy != nil ... // this is an RFP looks awkward, how about an explicit IsRfp flag?
  • and RfpLinkBy or RfpLinkDeadline
  • LinkTo is too abstract. How about RfpToken?
@xaur

This comment has been minimized.

Copy link

@xaur xaur commented Sep 12, 2019

@RichardRed0x, in August DJ you noted that "parallel voting" gained more support than 1-of-N. I guess it happened in chats? Is it still the case?

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.

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.

Fully agree, looking at the results of the MM RFP vote seeing i2 above 60% shows that the stakeholders really want it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
pi
  
In Progress
5 participants
You can’t perform that action at this time.