Code:
Name: LMP - Quality Ctrl
Term: 1 Cycle
Cycle Amnt: 4,000
Total Amnt: 4,000
Author: JSKitty
Receiver: PIVX Labs
Address: DLabsktzGMnsK5K9uRTMCF6NoYNY6ET4Bb
Created: 05-12-2023
Status: Active
Vote Hash: 0f6f9c5944804f4938fe478d9e017072e414b4a3406252a07e110f698a0de37bNote: The original intended name was
LMP - Quality Control, we submitted it as LMP - Quality Ctrl to ensure the title and URL fit consensus requirements.Note: Thanks to the price increase of PIV, PIVCards QC is now cheaper, and reward priorities can be slightly dropped to account for the price increase, as such, this proposal drops from 5,000 PIV to 4,000 PIV.
Proposal Abstract
This proposal is a renewal proposal to cover the full costs of the Labs Quality Control process, this is a continuation of the previous proposal, here.
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.
How'd the last one go?
The last two months of Quality Control expenses (roughly 4,000 PIV, with 1k PIV remaining of the last 5k PIV proposal, as of writing) were primarily spent on MyPIVXWallet and PIVCards, with both services falling under vast importance of testing.
The last two months required heavy testing for the release of PIVCards Platform v1.0, in which Quality Control members were all given PIV amounts and requested to spend it on various cards on PIVCards, this helped us iron out a bunch of cases of bad delivery, payment bugs, UI/UX bugs, and ironed out the general experience before launch - PIVCards wasn't perfect, mind you, but the launch was far from a failure, it's main issues came from the inability to initially scale: which could not be tested by artificial means.
For MyPIVXWallet, deep testing was required for upgrading the app to a new Network Synchronisation model and a new TX Database system - partial porting to the Vue framework, and an i18n rewrite - the first two features were a critical change in MPW's underlying codebase, so they both had multiple testing rounds, from multitudes of QC members - the launch of the new sync model was fortunately, extremely smooth and unnoticed by users thanks to the extra polish it received from extensive testing, yeehaw to Quality Control!
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. |
In the case of other services, such as PIVCards where testing requires actual purchases, users are given a select amount of PIV between 20-100 and allowed to spend the PIV on various PIVCards items, this allows us to watch the backend during real-time tests and iron out any issues that are spotted ahead of launch, or ahead of new updates, the most important aspect of this is having MANY users participate, from different regions, which grants us a bigger testing surface area over more brands, countries, currencies and languages.
Last edited: