Pay-per-job and governance-ruled Job List

Discussion on https://commonwealth.im/terra-classic/discussion/13873-payperjob-and-governanceruled-job-list This proposal, if approved, should be considered as an agreed-on guideline for paid jobs on Terra Classic. *Background* In the past, Terra Classic’s (L1) teams have operated under a monthly compensation structure based on a predetermined rate. However, this model of roadmap and payment planning has proven suboptimal. As the L1TF transitions into a “maintenance mode” for Q4, which involves primarily overseeing external pull requests and fundamental chain upkeep, there remains a collection of tasks awaiting attention on Terra Classic. *Issue* A monthly compensation model grants developers a consistent sense of financial security. However, it relies on a broad roadmap that might be subject to change as the quarter progresses. Given specific impending tasks, a more efficient model might be warranted. Currently, Terra Classic lacks the infrastructure to adopt tools like Enterprise or Warp. Thus, a straightforward solution is in demand. *Proposed Solution* The suggestion is to introduce a pay per job approach, including an official job list on the classic-terra GitHub repository, which will initially be empty. Via governance text proposals, new job listings can be proposed. Each proposal has to incorporate a job title, a detailed description, a budget, and an estimated duration (e.g., in man-days). Teams or individuals can then put up a text proposal to apply for the job, giving their quote and estimated time to complete. Of course it is also possible for a team or entity to propose (text proposal) a job and directly include their bid to take it on themselves. It still has to contain the full details, including the estimated time to complete, and price. Payment is done after approval of the completed work through a spend proposal. Upon governance approval, the job is listed on the classic-terra GitHub repository. Once a team applied with a bid for a job via text proposal, which is approved, funds for the task are deemed approved. Upon successful completion and approval of correct implementation (including potentially necessary unit/chain tests), payment is executed through a spend proposal. There exists a minor risk of payment rejection post completion, but such an occurrence would significantly tarnish Classic’s reputation, given the prior fund allocation approval. Changes to the priority, job description or budget limits (e.g. by a team making a higher offer) also require a text proposal. *Advantages* This model offers the community enhanced clarity on fund allocation and provides developers with clear task-specific directives and their associated compensations. Though rudimentary, this model is straightforward to implement and can be abandoned again once advanced tools are integrated. *Potential Concerns* There’s the aforementioned minor risk of the community or validators refusing payment after job completion and approval. Additionally, there are slight centralization concerns, such as the approval of developers’ contributions and the listing of approved jobs on GitHub. Furthermore, this system doesn’t account for ongoing maintenance tasks such as bug rectifications, release preparations, and deployment, which have been addressed by L1TF or voluntary contributors. *Conclusion* A straightforward system could facilitate the engagement of multiple teams for specific tasks, rather than compensating monthly teams with variable assignments. It doesn’t involve development efforts to integrate and can act as an intermediate system until better tools in place. *Cast Your Vote:* Yes: Support the proposal. No: Reject the proposal. Abstain: Align with the majority’s decision. No with Veto: Not applicable. *Summary* - Anyone can use text proposals to add a job to the github job list (title, full description, requirements for approval, budget, time scope) - Teams/individuals can use text proposals to bid on / apply for a job. Bid has to include a fixed fee and maximum time to complete (no spend proposal!). - After completing the job, a PR has to be done. Once that is approved and successfully tested (unit/chain tests, not deployment), a spend proposal is put up to pay out the funds. Approval of the payout is considered mandatory as funds were approved prior. - The same people getting paid cannot approve the work done. *Edge cases* Should there be two or more team applications via text proposal for the same job, in case both/all pass, the team with the highest (Turnout * Yes percentage) is approved. For example, two teams apply, one passes with 60% yes and a turnout of 40%, the other with 55% yes and a turnout of 60%, the second team is approved (60*40% vs. 55*60%).