Archived LMP - Quality Control

[PIVX Labs]

Name: LMP - Quality Team
Term: 1 Cycle
Cycle Amnt: 5,000
Total Amnt: 5,000
Author: JSKitty
Receiver: PIVX Labs
Address: DLabsktzGMnsK5K9uRTMCF6NoYNY6ET4Bb
Created: 07-10-2023
Status: Active
Vote Hash: 8bd9346acbe966fb23d40cf7244157ae75715668a9903d3224fa3585439734e7

Note: The original intended name was LMP - Quality Control, we submitted it as LMP - Quality Team to ensure the title and URL fit consensus requirements.

---

Proposal Abstract
This proposal is aimed to cover the full costs of the newly-launched Labs Quality Control process.
This process was originally devised as of September's edition of The Superblock Report, which outlined that the vast growth of My PIVX Wallet's user-base calls for a much tougher review process, both for Code (Developers) and App Quality, the latter of which is handled by the newly formed Quality Control team.

This was accelerated when various data-loss and fund-loss bugs were detected after the v1.0.0 release (Bug #1, Bug #2), concerning Proposal Submission, where we discovered and replicated multiple bugs that could cause a loss of either the proposals submission fee, or worse, the entire 'wallet' database would be lost - if such a bug hit a user that did not backup their seed phrase (as we recommend), they would have permanently lost their funds without possibility of recovery.

These bugs, although critical; were very easy to find even by non-developers, and thus we launch the Quality Control team, after now over a full month of successful trialing, which has shown to reveal far more bugs in-advance (particularly @MiguelC030 who has participated in almost every test I can remember) and this allows us to refine new additions further before merging, ensuring each new feature or improvement is fully acceptable from a user's perspective.

---

Who is the Quality Control team, and where are they?
Everyone is! Not kidding, Quality Control is an opt-in role in the PIVX Labs Discord server, in which ANY community member may opt-in to, receiving an exclusive Labs comms channel, and automated notifications upon new PRs that are ready for testing from the developer team.

The eligibility requirements to be paid on the Quality Control team are simple:

• Not already paid by the DAO (if you are already paid by proposals, then you cannot earn QC rewards).
• A max of one reward per-PR.

These rules are in place simply to prevent exploiting or double-dipping the process, which is monitored by devs for accuracy before a reward is distributed.

The Opt-in Process:

The exclusive Quality Control channel:

As of writing, there are currently 12 Quality Control team members, with an average testing activity of 4-5 members testing each Pull Request, these numbers will vary as people join and leave the team, and based on the quantity of Pull Requests submitted to PIVX Labs' projects

There is theoretically no limit to the amount of tests a Pull Request from have (per-member), the testing sessions only end when the Pull Request is merged; so some PRs may merge quickly on less tests, others may need more extensive tests and stay open longer, especially when issues are detected, or a PR needs to be redesigned from an architectural standpoint.

---

How are Quality Control rewards determined?
Each Pull Request is assigned a "complexity" or "size" marker by a Labs Team member, this is assigned based on the developer's interpretation of the complexity (or operational importance) of the Pull Request.

This proposal will be considered a single-cycle LMP for now, given that it is difficult to predict the program's expenditures in-advance, an LMP allows us to pool the funds to use as-necessary, rather than creating a multi-cycle LRP that may consume either More or Less PIV than necessary over the timespan of the next few months.

The current Labs Quality Control distribution table is:

Size or Complexity	Reward Amount	Description
Trivial	10 PIV	Trivial app adjustments, such as small improvements or bug fixes.
Small	20 PIV	Noticeable changes or UX-affecting refactors, such as Design or Functionality.
Large	50 PIV	Major app changes, such as large new features, large refactors or patches.
Critical	100 PIV	Critical and time-sensitive changes, such as patching data-loss or fund-loss bugs, large protocol changes such as Shield or Deterministic Masternodes.