multi: Add RFP proposal. #1054
multi: Add RFP proposal. #1054
Conversation
lukebp
force-pushed
the
rfp
branch
3 times, most recently
from
dd11707
to
6869d13
Compare
|
This PR has been put on hold temporarily. During the process of writing the RFP code I discovered issues with two of the mdstreams, the |
Is the base entity called "proposal" and not something more abstract like "post" or "message"?
This is "Request for Proposals proposal". I suggest to use just "RFP".
What "official" means here?
This has implications. Unlike normal proposals, author no longer controls the time of discussion and Pi admins become the ones to decide it. "Submission deadline" only refers to submissions, not discussions. Imagine that late submissions are posted right before the deadline. A few days/weeks of comments may be required after the deadline but before the runoff vote starts. Which leads to a related issue: once the initial RFP vote ends, the discussion under the RFP gets locked, while new submissions may arrive (until the deadline) and get discussed. If any questions or comments about the RFP in general (not about specific submissions) appear, they are forced to go into one of the submissions or even get duplicated across all of them, as we have observed in the market makers RFP. Or worse - spill over to chats or Reddit. What do you think about leaving the RFP discussion unlocked until the runoff vote finishes? Can RFP submission proposals be edited after the RFP submission deadline?
Based on the above I wonder what you think about
|
|
Re data model, revising my comment in #966,
Why is this needed? It breaks "single source of truth" and requires error-prone data consistency. Also, this will need to be updated even after the RFP vote finishes if new submissions arrive. This adds even more ad-hoc-iness to already ad-hoccy "first line is the title" format. How about standard YAML enclosed in This allows embedding of any structured metadata in proposal header (even with lists and maps). |
|
I force push this because #1088 and #1110 changed this PR enough that is became harder to rebase than to just start fresh on a new cut of master and copy/paste over certain changes. A large part of the PR was re-written based on changes over the past 2 months. The notable changes were:
The original commit message has been updated to reflect these changes. |
This diff adds a new type of proposal called a Request For Proposals
(RFP) and a new type of proposal vote called a runoff vote.
1. Any politeia user can submit an RFP proposal. An RFP proposal must
first be voted on and approved by the stakeholders before RFP
submissions are allowed. The RFP proposal is essentially asking the
stakeholders the question, "Do the stakeholders want to open up an
RFP process and solicit proposals for this topic?"
2. If approved, new proposal submissions are allowed to link to the RFP
proposal. These linked proposals are considered to be RFP
submissions. A link is not official until the RFP submission is made
public, leaving this decision in the hands of the admins. A deadline
exists for RFP submissions to be accepted. This deadline is set by
the RFP author when they orginally submit the RFP and can be updated
at any point before the start of the RFP proposal vote (step 1). Once
the RFP proposal goes up for vote in step 1, this deadline becomes
final. RFP submissions are not accepted once this deadline expires.
3. Once the RFP submission deadline expires, an admin can start the
voting process on the RFP submissions at any time. This is a new type
of vote called a runoff vote. Whe an admin starts the runoff vote,
the voting period on all public, non-abandoned RFP submissions will
begin simultaneously. Unlike a normal proposal vote, no vote
authorization is required from the submission author. Each submission
is voted on like a normal proposal vote.
4. The results of the runoff vote are calculated as follows:
- Only one proposal can be approved.
- The winning proposal is the proposal that meets the quorum %
requirement, meets the pass % requirement, and that has the most
net yes votes.
Note: this means that it will be possible for a proposal to meet
the quorum and pass requirements but still be rejected if it does
not have the most net yes votes.
- If no proposals meet the quorum and pass requirements then all of
the proposals will be considered rejected.
Added to the `ProposalGeneral` mdstream:
- `LinkBy`: A UNIX timestamp of the RFP submission deadline. We
determine if a proposal is an RFP by checking if this field is set.
- `LinkTo`: Censorship token of an existing public proposal to link to.
This is only used for RFP submissions at the moment, but can be used
for other types of links in the future such as proposal updates.
This proposal creates the concept of a proposal data.json file. The
data.json file is part of the proposal files bundle and includes fields
that are specified by the user and that needed by politeiawww, such as
the LinkTo and LinkBy fields. They are included in a seperate json file
instead of the index markdown file to make parsing easier.
Routes added:
- `StartVoteRunoff`: start the voting process on all public,
non-abandoned RFP submissions simultaneously.
Routes with API changes:
- `VoteSummary`: a `Type` field and a `Approved` field were added to the
`VoteSummaryReply`. A runoff vote makes it much harder for the client
to calculate the vote results, it needs the results from all of the
proposals in the runoff vote to do so, so the backend now does it and
returns whether the vote for any single proposal was approved.
Routes with code changes:
- `NewProposal`
- `EditProposal`
- `AuthorizeVote`
- `StartVote`
- `TokenInventory`
The following commands can be used to test this diff. Manually editing
the allowable quorum percentage, pass percentage, and minimum duration
in politeiad is required if you want to test this in a reasonable manner.
```bash
$ piwww newproposal --random --rfp
$ piwww setproposalstatus [rfp_token] public
$ piwww authorizevote [rfp_token]
$ piwww startvote [rfp_token] 1 0 0
$ piwww vote [rfp_token] yes
$ piwww newproposal --random --linkto=[rfp_token]
$ piwww setproposalstatus [submission1_token] public
$ piwww newproposal --random --linkto=[rfp_token]
$ piwww setproposalstatus [submission2_token] public
$ piwww newproposal --random --linkto=[rfp_token]
$ piwww setproposalstatus [submission3_token] public
$ piwww newproposal --random --linkto=[rfp_token]
$ piwww setproposalstatus [submission4_token] public
$ piwww setproposalstatus [submission4_token] abandoned
$ piwww startvoterunoff [rfp_token] 1 0 0
piwww vote [submission1_token] yes
piwww vote [submission2_token] no
piwww vote [submission3_token] no
piwww tokeninventory
```
|
This is a huge PR and I'd lie if I don't think this will have a couple of buglets still hiding in it. I do think we need to move ahead and get this into master so that we can test it on testnet. There is no way we can get more eyes on it before it is deployed to testnet. |
Closes #966
This diff adds a new type of proposal called a Request For Proposals
(RFP) and a new type of proposal vote called a runoff vote.
Overview of the RFP process
Any politeia user can submit an RFP proposal. An RFP proposal must
first be voted on and approved by the stakeholders before RFP
submissions are allowed. The RFP proposal is essentially asking the
stakeholders the question, "Do the stakeholders want to open up an
RFP process and solicit proposals for this topic?"
If approved, new proposal submissions are allowed to link to the RFP
proposal. These linked proposals are considered to be RFP
submissions. A link is not official until the RFP submission is made
public, leaving this decision in the hands of the admins. A deadline
exists for RFP submissions to be accepted. This deadline is set by
the RFP author when they orginally submit the RFP and can be updated
at any point before the start of the RFP proposal vote (step 1). Once
the RFP proposal goes up for vote in step 1, this deadline becomes
final. RFP submissions are not accepted once this deadline expires.
Once the RFP submission deadline expires, an admin can start the
voting process on the RFP submissions at any time. This is a new type
of vote called a runoff vote. Whe an admin starts the runoff vote,
the voting period on all public, non-abandoned RFP submissions will
begin simultaneously. Unlike a normal proposal vote, no vote
authorization is required from the submission author. Each submission
is voted on like a normal proposal vote.
The results of the runoff vote are calculated as follows:
requirement, meets the pass % requirement, and that has the most
net yes votes.
Note: this means that it will be possible for a proposal to meet
the quorum and pass requirements but still be rejected if it does
not have the most net yes votes.
the proposals will be considered rejected.
Data changes
Added to the user defined
ProposalMetdata:LinkBy: A UNIX timestamp of the RFP submission deadline. Wedetermine if a proposal is an RFP by checking if this field is set.
LinkTo: Censorship token of an existing public proposal to link to.This is only used for RFP submissions at the moment, but can be used
for other types of links in the future such as proposal updates.
API changes
Routes added:
StartVoteRunoff: start the voting process on all public,non-abandoned RFP submissions simultaneously.
Routes with API changes:
VoteSummary: aTypefield and aApprovedfield were added to theVoteSummaryReply. A runoff vote makes it much harder for the clientto calculate the vote results, it needs the results from all of the
proposals in the runoff vote to do so, so the backend now does it and
returns whether the vote for any single proposal was approved.
Routes with code changes:
NewProposalEditProposalAuthorizeVoteStartVoteTokenInventoryTesting with piwww CLI
The following commands can be used to test this diff. Manually editing
the allowable quorum percentage, pass percentage, and minimum duration
in politeiad is required if you want to test this in a reasonable manner.