この記事は、Terra Classicの著名なコミュニティメンバーであるStrathCole氏（@ColeStrathclyde）が2023年11月30日に公開した提案『Pay-per-job and governance-ruled Job List』の内容を日本語訳した記事となります。
提案の要点
- 現状のロードマップと支払い計画のモデルは最適でない
- このモデルは開発者に「明確なジョブ固有の指示と報酬」を提供
- チーム/個人で提案されたジョブごとに入札（応募）することができる
提案に基づいた月額の報酬体系の問題点
過去において、Terra Classic（LUNC）のL1開発チーム「L1 Task Force」は、あらかじめ決められたレートに基づく月額の報酬体系の下で運営されてきました。
しかし、このロードマップと支払い計画のモデルは最適でないことが証明されています。
L1 Task Force（L1TF）は第4四半期に向けて「メンテナンスモード」に移行し、主に外部からのプルリクエストと基本的なチェーンの維持管理を行っていますが、Terra Classicには重要視されているタスクが山積している状況です。
この提案が承認されれば、Terra Classicでの有償ジョブに関する合意されたガイドラインとして考慮される必要があります。
月額での報酬モデルは、開発者側からすると一貫した経済的安心感を得ることができます。しかし、現状はロードマップに依存しており、四半期の進行につれて変更される可能性があります。
現在、Terra Classicには "Enterprise" や "Warp" などのツールを導入するためのインフラが不足しており、直接的な解決策が求められています。
ジョブごとのリスト・報酬支払いモデル
この提案の目的は、classic-terra GitHubリポジトリ上の公式求人リストを含め「ジョブごとに報酬を支払うアプローチを導入すること」です。
ガバナンス提案によって新しいジョブリストを提案することができ、内容として「ジョブのタイトル・詳細な説明・予算・推定期間（工数など）」を盛り込む必要があります。
チーム/個人は見積もりと推定期間を提示し、その仕事に応募することができます。チーム/個人がジョブを提案し、それを自分たちで引き受けるという入札（応募）を行うことも可能です。
その場合も、完了までの推定期間や予算など、詳細がすべて記載されていなければなりません。報酬の支払いは「支出提案を通じて完了した作業が承認された後」に行われます。
提案が承認された後、その仕事はclassic-terraのGitHubリポジトリにリストされます。チーム/個人が提案を通じてジョブの入札を申請し、承認されると、そのタスクの資金は承認されたものとみなされます。
正常に完了し、正しい実装（潜在的に必要なユニット/チェーンテストを含む）が承認されると、支出提案を通じて支払いが実行されます。
完了承認後に支払いが拒否されるわずかなリスクが存在しますが、事前の予算承認を考慮すると、そのような事態が発生した場合はTerra Classicの評判は著しく傷つくことになります。
優先順位、ジョブ内容、または予算制限を変更する場合（チームがより高いオファーを提示する場合など）も、テキストによるガバナンス提案が必要です。
支出までの流れ
例えば「チェーンをv0.47に更新したい」とします。
提案者であるチーム/個人は必要な作業量の見積もりについて開発者に相談し、Commonwealth（または同様のプラットフォーム）で提案します。
この提案には、最大予算や作業開始から完了までの最大時間、そして作業範囲の正確な仕様が含まれていなければなりません。
そして、その提案が承認されるとそのジョブはGitHubのジョブリストに登録され、入札によって請け負ったチーム/個人によってジョブが完了されるとプルリクエストが作成されます。
その後、その分野に精通した少なくとも2人または3人によってレビューを行い、承認された場合は支出提案が投票にかけられます。
ジョブと予算は提案によってすでに合意されているため、ガバナンスによる支出の承認は必須とみなされるべきです。
一定期間（例えば1週間）進捗がない場合、"claimed/in progress" ラベルは削除され、そのジョブが自由に取り組めることを他のチームに知らせる必要があります。
複数の入札（応募）
同じ仕事に対して2つ以上のチームがテキスト提案で入札（応募）し、すべてが通過した場合は「"投票率 × Yesの割合" が最も高いチーム」が承認されます。
例えば、2つのチーム/個人が応募し、1つは60%のYes、40%の投票率で通過し、もう1つは55%のYes、60%の投票率で通過した場合、2番目のチームが承認されます（60 × 40 vs 55 × 60）。
メリット・デメリット
メリット
このモデルは、コミュニティに対して資金配分をより明確にし、開発者に明確なジョブ固有の指示とそれに関連する報酬を提供します。
初歩的ではありますが、このモデルは実装が簡単であり、高度なツールが統合されればすぐに放棄することができます。
デメリット
前述しているように、ジョブが完了し承認された後、コミュニティや バリデータ が支払いを拒否するというわずかなリスクがあります。
さらに、開発者の貢献の承認や、承認されたジョブのGitHubへのリストなど、一元化に関する若干の懸念もあります。
なお、このシステムは、L1TFやボランティアの貢献者によって対処されている「バグ修正」「リリースの準備」「展開」などの継続的なメンテナンスタスクを考慮していません。
まとめ
- 誰でも提案をすることによってgithubのジョブリストにジョブを追加できる（タイトル、詳細な説明、承認要件、予算、推定期間）
- チーム/個人は、提案されたジョブに入札（応募）することができる（入札には「固定料金と完了までの最長時間」を含める必要がある）
- ジョブ完了後、PRを行う必要があり、テスト・承認されれば報酬を支払うための支出提案が出される（資金が事前に承認されているため、支払いの承認は必須）
- ジョブを遂行したチーム/個人が、そのジョブのテスト・承認することはできない
決まったチームにタスクを割り当てるのではなく、この単純なシステムに変更することによって、特定のタスクに複数のチームが参加することが容易になります。
このシステムは、統合のための開発努力を伴わず、より良いツールが導入されるまでの中間システムとして機能します。
『Pay-per-job and governance-ruled Job List』の原文はこちら