understand mechanism requirements from glen

[petar]

We need to understand all mechanisms (features) that Glen plans to add to the application (on top of the features from #31) for the public launch. These will be the last product features going into the public launch.

Let's collect the requirements and record them here.

I am pasting from emails what input we have from Glen so far:

1. Over the course of a week, the maintainer adds and removes credits from various accounts.
2. An issue is posted. Over the course of the week, various contributors add and subtract votes from it. These translate into a priority score according to quadratic funding. The current funding level is continuously pushed to the client to allow it to be viewed and ordered by priority. Then, at some point, someone submits a PR to address the issue. At this point, the current priority on the issue freezes, contributors can no longer adjust their contributions to this issue.
3. Continuing the scenario from 2, a PR poll now opens. Over the course of a week, contributors adjust their votes (via QV) on whether the PR should be approved, ahead of a deadline at the end of the week. As they do so, they also submit a number of credits they want to “bet” up to the amount of votes they have on this issue, that it goes their way. At expiry, the users are paid out 2 to 1 on the amount bet if the choice went their way; all credits committed to voting are collected and burned.
4. In the case that 3 ends in the PR being rejected, we return to stage 2 and the QF exercise unfreezes .
5. In the case that 3 ends in the PR being accepted, the person submitting the PR gets credits equal to the priority.

Questions:

• What if PRs only address an issue partially?

[pluralitybook]

I will shortly have a write-up, with Tobin South and others, of the mechanisms we are currently envisioning in math.