Governance of Trustmetric Voting

[allancto]

Benefit to RChain

Consensus seeking and voting systems are crucial to distributed governance. Improving Trustmetric label guiding and voting benefits our Cooperative by improving our Bounty system and providing a model for governance in our Cooperative as a whole.

Description

1. During the July voting period (ending Aug 8) a “mutation” was introduced into the voting system rewards.rchain which allows all voters, including Observers (for instance new members voting with 0 weight), to participate in the quorum condition for voted budgets and rewards. There’s been some discussion suggesting that allowing all voters to at least participate in a quorum extends an appropriate amount of trust to all voters. A slightly more conservative approach would require a quorum of three AND at some minimum total voting weights.

2. During the July voting period we had a mini “constitutional crisis” over a large negative vote cast as a signal of disapproval of a particular issue being voted. Objections were raised that a negative “budget” doesn’t conform to a commonsense interpretation. Should negative votes be allowed? What about large positive budgets, should there be an upper limit on any particular budget?
   NOTE it’s possible we may want to introduce a separate issue to investigate the mathematics of weighted voting systems, particularly in terms of whether conditions like this may be necessary in order to reduce the possibility of gaming the voting system. If anyone wants to tackle that issue I would vote a significant reward for a thorough job.

3. In discussions during voting the statement was made that it’s a requirement that label guides vote a “guiding” budget within 5 days to signal their support or lack of support of the issue. These early votes are of course guidance and subject to revision, since all voters, are allowed to change their votes at any time before voting, based on factors such as the project came out worse or better than expected, and so on. Is this a good idea, and if so should we make it an explicit duty of guides?

For these three issues, do we have a governance process for deciding them? Do we come to consensus by posting comments and having a judge declare what the consensus is? Do we hold a meeting? What process should we use that will be not too costly and arrive at a consensus “most of us” agree on?

Budget and Objective

HelpWanted: Cannot really decide budget until we agree on what process we will use.
Estimated Budget of Task: $[? (depends on process chosen)]
Estimated Timeline Required to Complete the Task: [in time for last 10 days of this voting period?]
How will we measure completion? [?]

See CONTRIBUTING.md for details on budget and reward process.

References

HelpWanted: there have been many discussions of these and related topics here in github (and also elsewhere). Please feel free to add them here.

Legal

Task Submitter shall not submit Tasks that will involve RHOC being transacted in any manner that (i) jeopardizes RHOC’s status as a software access token or other relevant and applicable description of the RHOC as an “asset”—not a security— or (2) violates, in any manner, applicable U.S. Securities laws.

[dckc]

See also:

• rewards don't freeze due to trust metric interactions #799 "rewards don't freeze" issue where the mutation was introduced;
• Bounty Progress Report: Quarter 2 #850 Q2 report, where the retroactive impact on May accounting was noticed
• review of July pay period (201807) rewards by TAC + guides #847 review of July, where the impact on July was accepted
• how many apprentices, journeyers, and masters should there be? #785 how many apprentices? where I suggested following up on future handling for "at least three"

[dckc]

For these three issues, do we have a governance process for deciding them?

It seems reasonably clear, to me:

• The board decided Apr 6 that there shall be a Task Approval Committee
• The Executive Committee decided Jun 19 that the committee is @dckc, @PatrickM727 , and @deannald , who delegate to guides via a trust metric (ref Task Approval Committee and Terms of Service (TOS) #616 (comment))

So it's up to @PatrickM727 , @deannald , and myself to decide how the trust metric works, since it's the mechanism by which we delegate. Of course,we'd be silly to make any changes without support of the guides, since then we'd have nobody to delegate to and we'd have to do a ton of work.

the statement was made that it’s a requirement that label guides vote a “guiding” budget within 5 days to signal their support or lack of support of the issue. ... Is this a good idea, and if so should we make it an explicit duty of guides?

It's already an explicit duty:

Guides should provide feedback on issues in their area within a few days and initiate the process of Task Approval: either support a task by adding budget and reward votes or provide negative feedback ... -- Bounty Task Guides

3. Within five (5) days of receiving the Task Identification Form, the Committee will provide written notice to the submitter of the Task Identification Form (the “Task Submitter”) of the Committee’s approval or rejection of the Task Submitter’s Task Identification Form -- Apr 6 Board records

We carry out the process as follows:
...
The issues with a non-zero budget as a result of at least three trusted votes are approved. Bounty Task Guides should provide feedback on new issues in their area within a few days, both in the form of github comments and budget votes. -- Task Approval

[barneycinnamon]

Under Budget and Objective, the budget is explained as TBD, but the objective is not mentioned. Allan, was the objective to trigger a review of the current structure of the trust metric system? It seems like pondering the governance of the system would be a logical precursor to engaging that governance mechanism to consider modifying the system. Dan seems to have responded as if he interpreted the objective as such, and my read of his comments is that there is an understood source of the authority for setting up the trust metric design and parameters, and that the system has been reviewed recently and deemed adequate by those currently vested with the power to make changes.

Dan, do you believe the correct way to propose a change to the trust metric is to submit a proposal to the Task Approval Commitee making a case that an alternative arrangement would be superior to the current one, in the view of the proposal submitter?

[dckc]

... do you believe the correct way to propose a change to the trust metric is to submit a proposal to the Task Approval Commitee... ?

Yes, more or less.

That is: I hope proposals will get submitted is issues here so everybody can see them, not just the 3 members of the TAC. Plus, the scope of proposals can drift from being strictly about how the TAC delegates through the trust metric into related topics where the stakeholders and decision-makers may differ.

[barneycinnamon]

Thanks, Dan. So let's revisit Allan's questions. I'll add provisional responses.

[For issues that arise with the bounty system]...

Do we have a governance process for deciding them?
Yes. Currently the decision would be in the hands of the Task Approval Committee. The TAC members might solicit community input, particularly from members active in the bounty system, but individual issues would be handled by the TAC on a case by case basis.

Do we come to consensus by posting comments and having a judge declare what the consensus is?
Yes. But the judge is the TAC, and it is the consensus of the TAC that will be declared, not the consensus of a wider community.

Do we hold a meeting?
Possibly. Affected members could assemble to discuss the issue and forward an opinion to the TAC as a group, or the TAC could invite members to participate in a meeting, but these would be optional at the discretion of the TAC on the one hand and members or non-member participants in the bounty system on the other.

What process should we use that will be not too costly and arrive at a consensus “most of us” agree on?
Vesting authority in the TAC reduces the cost of arriving at consensus. The goal is not necessarily for "most of us" as defined by the broader community to agree on the individual judgment made by the TAC, but it would be good for the TAC to solicit and accept comments where possible, in public (e.g. in issues) where possible. Further, there should perhaps be a process by which a group of members can submit a proposal to the TAC, or to the Executive Committee if they follow some procedure.

With all this said, I think maybe Allan's original issue could be rephrased as "We should develop a procedure whereby members can submit a proposal that would govern the way the TAC resolves some type of issue." Perhaps that fits into a more general class of problem, which is an intermediate step between chatting on Discord or commenting on GitHub issues on the one hand and submitting a member resolution to the annual member meeting on the other. I always assumed the Executive Committee could serve as a recipient of such a proposal, but we don't have a process in place. There was the old idea of using the Proposals channel for things like this, but I think it stalled out.

[barneycinnamon]

Since the proposal was never fleshed out, and the TAC appears to fit within the current governance structure of the Coop, I am going to say that addressing problems with the larger governance structure is the real issue to the extent there is one. I will close this issue for now.