Recognized Actors For Incentives

[0x4007]

We should recognize four roles across two views (for a total of eight uniquely identifiable contributor types) and have a standardized configuration of reward amounts per action per contribution type they can take:

Definitions

Roles

• issuer = who created the issue
• assignee = the "bounty hunter" who is assigned to the issue
• collaborator = a privileged role, this is who is directly added to the repository as a "core team member"
• default = everybody else, usually referring to the public

Views

• issue = on the normal issue view
• review = on the pull request review view

Contributor Types

Views/Roles	Issuer	Assignee	Collaborator	Default
Issue	issueIssuer	issueAssignee	issueCollaborator	issueDefault
Review	reviewIssuer	reviewAssignee	reviewCollaborator	reviewDefault

Configuration Example

/*
const issueIssuerAmounts,
issueAssigneeAmounts,
issueCollaboratorAmounts,
issueDefaultAmounts,
reviewIssuerAmounts,
reviewAssigneeAmounts,
reviewCollaboratorAmounts,
reviewDefaultAmounts = { ... } as RoleIncentiveAmounts;
*/

const repositoryIncentives /*: RepositoryIncentivesConfiguration */ = {
  "issue-issuer": { enabled: true, amounts: issueIssuerAmounts, capped: true },
  "issue-assignee": { enabled: false, amounts: issueAssigneeAmounts /* capped: false */ }, // capped is N/A as it refers to the task reward
  "issue-collaborator": { enabled: true, amounts: issueCollaboratorAmounts, capped: true },
  "issue-default": { enabled: true, amounts: issueDefaultAmounts, capped: true },
  "review-issuer": { enabled: true, amounts: reviewIssuerAmounts, capped: true },
  "review-assignee": { enabled: false, amounts: reviewAssigneeAmounts /* capped: false */ }, // capped is N/A as it refers to the task reward
  "review-collaborator": { enabled: true, amounts: reviewCollaboratorAmounts, capped: true },
  "review-default": { enabled: true, amounts: reviewDefaultAmounts, capped: true },
};

const roleAmounts: RoleIncentiveAmounts = {
  comment: {
    code: 1,
    img: 0,
    h1: 1,
    h2: 1,
    h3: 1,
    h4: 1,
    h5: 1,
    h6: 1,
    li: 0.5,
    ol: 0,
    p: 0,
    pre: 1,
    table: 1,
    ul: 0,
    a: 1,
    blockquote: 0,
    i: 0,
    totals: {
      word: 0.1,
      // sentence: 0,
      // paragraph: 0,
      // comment: 0
    },
  },
  reactions: {
    received: {
      "+1": 0,
      "-1": 0,
      laugh: 0,
      hooray: 0,
      confused: 0,
      heart: 0,
      rocket: 0,
      eyes: 0,
    },
    sent: {
      "+1": 0,
      "-1": 0,
      laugh: 0,
      hooray: 0,
      confused: 0,
      heart: 0,
      rocket: 0,
      eyes: 0,
    },
  },
  reviews: {
    approved: 0,
    rejected: 0,
    leftComment: 0,
    pending: 0,
  },
};

References

• Cap All Rewards at Bounty Price #717
• Refactor Config: mdast element keys as HTML entities / ref #496 (comment)

[0x4007]

@rndquu @0xcodercrane rfc

This is a big one but I think it sets a great foundation for keeping track of every way a contributor can communicate via comments on GitHub. It also formalizes every "contributor type".

We can roll out configuration support and then worry about making use of the configuration in features later (for example, rewarding based on sent/received reactions.)

I'm skeptical about the "capped" property as it seems like an outlier specific to a specific type of reward (the assignee reward for completing the task)

---

The only other way a contributor can contribute is, of course, with code. But I think it requires a lot more research to know how to evaluate code quantitatively (I don't think it's feasible, unless we rely heavily on ChatGPT.)

---

If this is clear and a sensible plan, @rndquu please break this down into actionable tasks so that we can support fine grained incentive configuration, which I believe to be essential for:

1. moving compensation to this new system and off of salaries and
2. enabling pull request review incentives

• September 2023 Strategic Priorities #751

[0xcodercrane]

Overall Feedback:

I believe your proposal encompasses key elements such as velocity/quality/cost for effective product development.

1/ Defining key incentives.
Tbh, the idea of defining actors to incentivize contributors regarding issues and pull requests is a new concept that I've not encountered previously before I started working at Ubiquity. It is kind of a transformative shift from the conventional centralized review process to a decentralized one.

This approach allows anyone to hunt a bounty, review pull requests, and actively contribute to issue resolutions.

A couple of questions:

• Who will merge the pull requests finally? core member or reviewer?

The possibility of allowing random reviewers to merge pull requests without additional core member review raises concerns about security. This situation could potentially introduce vulnerabilities, such as sybil attacks or exploitations of established processes.

• Who will be responsible to manage emergencies if we move the current compensation?
• How could we make sure that random reviewers review the PRs for both code quality and feature?
  Perhaps the solution might be to choose the reviewer for each pull request???

Despite these potential obstacles, it is worth starting this process --- here I am gonna follow up on the quote: "Focus on improvement, not perfection."

2/ Optimizing the core eng process

I think we could cut off the salary compensation and save costs a little bit by moving to the new system.
but it's also important to optimize core members for the future of the product. Maybe @pavlovcik can decide on it based on their past contributions, key roles at the core team, emergency cases, or something like that.

I will follow up on September 2023 Strategic Priorities.

[0x4007]

Who will merge the pull requests finally? core member or reviewer?

With GitHub it is only possible to merge when added as a collaborator (those added to the repository and/or organization.)

Who will be responsible to manage emergencies if we move the current compensation?

• That's a good question! I'm hoping that with the high enough cash incentives, and the UBQ rewards, the more experienced team members will jump in to save the day.

Disincentives

Why bother caring about the project in emergencies? Although it is a continuum for most matters regarding "how employed" they are at the DAO, there are several actions that can be taken by organizations against privileged contributors. In order of increasing severity:

1. They can be removed as a collaborator which would make them ineligible for the largest rewards: e.g. privileged tasks like approving, requesting changes, and merging pull requests.
2. The project can modify the contributor's "organization XP" so that they can no longer work on the high priority tasks.
   1. Technically if we set it to a negative value, this could be a "soft ban" where they can no longer self assign to tasks, but only contribute via comments.
3. The project could ban (using GitHub) the contributor, which means that they will no longer be able to contribute to the organization in any way (and collect any money.)

If these are insufficient, then we will need to consider retainer deals (basically salaries) for "emergency staff"

How could we make sure that random reviewers review the PRs for both code quality and feature?
Perhaps the solution might be to choose the reviewer for each pull request???

Random reviewers can leave comments and collect comment incentives. Only collaborators (those added to the repository and/or organization) can "approve" or "request changes" (which we can give a much greater bonus for) and finally, merge; which automatically marks the issue as complete and triggers everybody's payouts.

[rndquu]

Current issue is already described pretty well.

So as a part of this issue we should:

1. Refactor the bot's config to support incentives for each contributor type
2. Refactor payout calculations to generate payment permits for each role (i.e. contributor type) when an issue is closed

Regarding the time estimate I would put Time: <1 week @0xcodercrane