⿻ Plural Management of ⿻ 數位 Plurality

Introduction

The ideas described in the Plurality book aim to tell the world how collaborative technology can remake how we work and govern together. The book also aims to show how these ideas can work in practice. To do this, Plurality will be built using the principles described in the book. This is a challenge because it is a book about innovation and thus the platforms for the things we want to show do not exist: we are building them as we go in the process of writing the book!

Purpose

This article aims to help users understand the who, what, why, when, where, and how of participating in the creation of Plurality. Outlined below is the ⿻ Plural management system that we will use to collaborate.

Goals

We have several interlocking goals in the design of our management system:

1. We want to recognize project contributions formally, quantitatively, and democratically. This can be contrasted to the informal and often confusing methods that are typical to open-source projects.
2. We want to avoid speculation and financialization of the devices that will be used to recognize contributions to the project.
3. We want to demonstrate the ideas of Plurality. To do this, we will aim to ensure that the direction of the project is determined democratically. Eventually, we want to turn over the maintenance of the project to the community completely.
4. We want the project to scale smoothly while also ensuring that the systems we use are secured against malicious attacks. We want to ensure that democratization and decentralization happens gradually and does not occur at the expensive of the integrity of the project’s contents or the community’s values. A key device that will be used by the community to accomplish our goals is a system of unique credits. We call these Plural credits.

Plural Credits

Plural credits (PCs) are used to formally recognize when someone contributes to the project. PCs will initially be interchangeable, quantitative, and divisible indicators of contribution. Individuals will not be able to transfer or sell credits to one another. While of no (direct) financial value, PCs will entitle holders to several social benefits:

1. Recognition: Our ledger of PC holdings will be the definitive source of information on the contributions to the book. We plan to display the ledger in in several ways. One of these ways could be to create collective image that acts as a “credit scroll” of contributors. The more significant one’s contribution is to the project, the more prominently they will be displayed in this image. Whenever we refer to the “⿻ community”, we will implicitly be referencing this ledger.
2. Governance rights: PCs will be the tool that is used to govern the project. They govern by determining the priority of work, and the changes or contributions that should be accepted. When PCs are used for governance, they also determine who will receive PCs in the future and thus who will be able to make further governance decisions. More on governance is discussed below.
3. Resources: PCs will gate access to various resources. This includes ‘@plurality.net’ email addresses, GitHub Pro coupons, and other benefits (including possibly financial compensation from funds raised by book sales, all of which will be donated to the community’s collective governance). Resources will be voted on by the community and will remain consistent with our status as being fiscally sponsored by the charitable organisation (US 501c3) Open Collective Foundation. Any compensation is to be reasonable, transparent, and consistent with this status. After introduction of quantitative PCs we plan to introduce qualitative tokens. Qualitative tokens will be able to indicate the type of contribution that an individual makes (e.g. a written, design, or technical contribution).

We will shortly release a “social capitalization table” that will make the allocation of PCs now and in the short term more clear. Future evolution of the social capitalization table will be determined collectively by the community. The social capitalization table will initially be released as a simple spreadsheet, however it will eventually live in a distributed ledger maintained by the community through the open source Gov4Git (G4G) protocol.

Gov4Git

Gov4Git (G4G) is an open-source protocol that uses a blockchain-like structure where a ledger of credits is mirrored by the git repositories of all its members. In contrast to standard blockchains G4G does not include financial incentives for maintenance of the ledger and instead relies on community members to mirror the underlying database for the same reason that they mirror the code of git projects (to participate in the community). When there is a conflict in the ledger, the governance procedures described below work to resolve these conflicts. The social capitalization table used for allocating PCs will live on a ledger that is maintained by the community through the Gov4Git protocol.

Governance

While the G4G protocol offers a foundational layer for an essentially-arbitrary range of governance mechanics, the governance mechanism that we plan to implement is the Plural Management Protocol (PMP). The PMP harnesses and combines a range of the mechanisms described in the book to allow us to achieve our goals. Full details of the PMP can be found in the Plural Management paper. With the PMP, contributors can earn credits by making contributions to the book (approval of the contributors GitHub pull requests), and by helping others triage pull requests (predicting the outcome of a pull request approval vote). Contributors can then use their credits to prioritize GitHub issues, and to approve or reject GitHub pull requests. Let’s break these processes down a bit more:

1. Prioritization: Issues are prioritized by a version of the Capital-Constrained Quadratic Funding (QF) mechanism. Contributors dynamically contribute to proposals’ priorities and are matched according to the “democratic” QF formula (e.g. small contributions are matched more than large ones, and contributions to popular issues are matched more) and the current matching funds made available by sponsors.
2. Subsidies: The matching funds are provided by sponsors, mostly likely the largest PC holders such as E. Glen Weyl and Audrey Tang.
3. Bounties and contributions: The current priorities of issues are publicly displayed and ranked, so as to encourage contributors to prioritize addressing these. A contributor who submits a PR to address an issue and has this PR accepted will receive a bounty in PCs Plural Management user doc.docx proportional to this current priority (with a small “tax” to support the process of evaluating the PR).
4. Approval votes: Contributors can vote for a PR to be accepted or rejected. PRs with net positive votes at the end of the review period (currently a week) will be accepted. The cost in credits of $v$ votes is $kv^2$ where $k$ is a PR-specific constant. This instantiates the system of Quadratic Voting (QV) described in the book.
5. Approval predictions: In addition to voting, contributors are also implicitly predicting what decision the community will make; in addition to the cost of $kv^2$ they will also pay a cost of $|v|$ and receive a payment of $2|v|$ if the community decides in favor of the direction of their vote. For someone who is purely maximizing their return, it is optimal to vote in the amount $\frac{|p-1/2|}{2k}$ in the direction that they believe it is more likely for the vote to go, where $p$ is the probability they believe the vote will be approved. This provides low PC-holding community members to gain PCs by helping those who may have more PCs but less time to review submissions to sort the wheat from the chaff.

Join us!

We hope you’ll be excited to join us! You need PCs to really get into the heart of the system. The simplest way in is to submit a PR on a currently outstanding issue. Community members can also create an issue that they fund just to get you access; if your submission is approved (if the community collectively thinks you should join) you will become a member with the bounty associated with that issue. If you wish to know the current priority of issues but are not yet a member, you can contact a current member (such as Glen Weyl). Please join our Discord channel to discuss and reach out to Petar Maymounkov if you are a translation fork or other affiliated community that wishes to use this workflow.