扱いにくさの原因になっているところを分解する

[yu23ki14]

インターフェースの親しみやすさとは別の軸として、使い方が想像できない部分がある。
これを解消するにはいくつかのユースケース・ケーススタディ・テンプレートを提示して掴んでもらう必要がある。そのために現状扱いにくさの原因になっている概念と、その解決策などを議論する。

貢献の定量化に用いられる以下にフォーカス。

• アシストクレジット
• 従事期間
• 役割係数
• 役割の抽象度（タスクでないなら、どのように定義すべきか）

[yu23ki14]

これまで論点になっているもの

アシストクレジット

• どれぐらいの量を送ったらいいのか相場感
• アシストクレジットの初期値10,000が足りなくなった場合どうするか
• どういう意味でアシストクレジットを送るのか？役割に紐づく助けをもらったとき？より汎用的に感謝を伝えたいとき？

従事期間

• どれぐらいの頻度で一時停止判断をするべきか？

役割係数

• どのように役割ごとの係数を決めるべきか

役割の抽象度

• 義務・権利の欄はどういうものを書くべきか
• 役割はだれがどのように定義・作成するのがよいか

[yawn-c111]

なかなか難しい問題でまだまだ考え中なのですが、一つのディスカッションの軸として…

コントリビューター（つまり、唯一実際にトークンを送信する人たちともいえる）が「あ、トークン送ろう」と思った時から、送信ボタンを押して送信済み画面が表示されるまでの間の、コントリビューターの認知的負荷を可能な限り下げるような方向性はありかなと思って、この路線を考えてみています！

（例えば、初期値10,000がボトルネックなら、初期値0にして送信の度にミントされて増えるようにする等）

[yawn-c111]

やっぱり、

• ユーザーからみた分かりやすさ
• 正確な貢献の計測・可視化

は、ある程度トレードオフの関係にありそうですよね…

[aowheel]

課題

• アシストクレジットとは何者か
• ワークスペースの終着点を定義しない中で、役割を先に切り出しても機能させる方法
• 役割保持者が複数人いる場合、各Wearerに対して正しい割合が降りてこないと正当な評価ができているとは言えない（従事時間だけでは足りないかもしれない）

アシストクレジットの定義とソウルクレジット（仮）の導入

ワークスペースの作成時にリーダーはまず役割を大きく切り出し人を割り当てる。役割保持者は自分の役割を遂行する中で、助けてもらったときにアシストクレジットを送る。これは大雑把に割与えられてしまった役割の重みをレトロスペクティブに修正する機能を果たす。

• アシストクレジット
  • 各役割保持者に最初に10,000ずつ配られる
  • お助けをもらったときに個人のアドレスに対して送る
  • 送る量は自分の役割に対してどれくらいの重みを担ったかという割合
  • 配り切ってはならない
  • 自分がその後も役割を続けるとその時のお助けの効果は薄まるので、役割保持者は自分で追加発行して調節できる
  • Wearerに降りてきた値に対してその最終的な分配を計算するための比率として用いられる
• ソウルクレジット（Named by takerunさん）
  • ワークスペース参加時点では0？（いくらかあってもいいかもしれない）
  • 参加しているといつの間にか増えている
    • 裏では、持っている役割の個数、役割への従事期間、アシストクレジットを送った量、受け取った量、によって日々計算され追加されていく
  • 感謝したいときにWearerに送る（つまり、HatIdとAddressのハッシュであるTokenIdに紐づく値になる）
    • どの役割にも当たらない感謝の場合は個人のアドレスに送れてもいいかもしれない
  • 配り切っていい
    • 自分にありがとうを送ることはないので、自分以外の報酬分配に影響を与えることになる
    • 持っていても配らない場合は分配の比率に影響を与えられないだけ
  • 受け取った量は、同じ役割でもそれぞれの頑張りが違うときにそれを正当に評価できるような、従事期間に新たに加わるパラメータになる

解決しうること

• アシストクレジットは与えられた役割に対して自分が担った比率をもくもくと評価すればいいだけなので、意味が明確化する。
• 役割を２つ持っていると１つの人に比べて単純に報酬が２倍になるという問題があった。ソウルクレジットを導入すると、ソウルクレジットは同様に２倍になる（計算式にもよる）が、それは自分以外の分配比率に影響を及ぼすものなので、報酬分配時の役割の数の影響は下がる。
• Tobanのミニマムな機能はアシストクレジットだけで、でも実は裏でソウルクレジットが溜まっていて、配っても配らなくてもいいけど配ると自分の感謝が評価の比率として届くし、楽しい、というような構造が期待できる。関さんがおっしゃっていた、Notionは誰でも使い始められるくらい簡単だけど、実は多機能なのでユーザーを離さないといったことができるかもしれない。

[aowheel]

@yawn-c111 あの後も色々考えていたら超長くなってしまいました笑

[yu23ki14]

参加しているといつの間にか増えている裏では、持っている役割の個数、役割への従事期間、アシストクレジットを送った量、受け取った量、によって日々計算され追加されていく

これはいいアイディアですね、TotalSupplyが徐々に増えていくということだったら計算式だけで表現できるからいちいちmintしなくていいので。

感謝したいときにWearerに送る（つまり、HatIdとAddressのハッシュであるTokenIdに紐づく値になる）どの役割にも当たらない感謝の場合は個人のアドレスに送れてもいいかもしれない

Wearerに送るのと個人のアドレスに送るの違いって、単純に個人のアドレスとは違って、「開発のHaruki」への感謝ということですかね？

[aowheel]

@yu23ki14 そうです！
現時点では同じロールを持つ2人に対する分配の差分は従事期間にしか依らないと思うんですが(アシストクレジットによって最終的な分配量は変化する)、Wearerに送ることにすれば従事期間に加わるパラメータになるのかな、と思いました。

[yu23ki14]

メモ 感謝トークンについて

制限できる要素

• 回数 (1日X回)
• 量 (1日100、1回あたり10まで)

貢献定量化でのマルチプル

• 長くコミュニティにいる人からの評価のほうが高い(シビル耐性になる)
• 感謝を送ってる側にも加点 (単純回数でいいかも、感謝を送るインセンティブになる)

[yu23ki14]

提案

• アシストクレジットを「Role Share」の概念に変更
• 感謝するときに送る「Thanks Token」の概念を追加

Role Share

ロールシェアは実態としてはERC1155トークン。大まかに割り振られた役割を遂行するにあたって、誰かに一部をお願いしたり、複数人で一つの役割を遂行する際の貢献量の差分を調整するために用いる。頻繁に送り合うようなものではない。

• 人から受け取ったものを横流しすることはできる。
• Transfer関数は持ち主のみができるので慎重に配る必要がある。（株式を後から返してもらうということが簡単にはできないのと同じ）
• Roleを与えられると初期値10,000固定で、役割保持者は1000,000枚まで後から追加発行することも可能。※100万枚にしているのは暗号資産不該当にするためが大きい。

Thanks Token

コミュニティで活動している中で感謝を伝えたいと思った時に送るトークン。送れる総量は役割の従事期間や担っている役割などによって変わる。たくさん貢献している人ほど、人にたくさん送れるようになる仕組み。Thanks Tokenを送るときにはmint関数で送るようにして、自分のアドレスに対してはmintできないようにする。

各メンバーのTotal Mintable Amount（他人に送れる量）決定に用いられる変数の候補

• 役割従事期間
• 過去受け取ったThanks Tokenの量

貢献定量化+報酬分配

2つのパートによって決まり、この2つをそれぞれどの程度重要視するかはコミュニティが決める。例えば、役割ベースを70%、Thanks Tokenベースを30%にするというように。

1. 役割ベースの変数: 「各役割の重み」、「√従事期間」、「役割シェア保有率」によって決定される
2. Thanks Tokenベースの変数: Thanks Tokenの「保有率（受け取った量）」、「流動性供給率（送った量）」に応じて決定される。保有率と流動性供給率は「95:5」とか？

このあたりはコミュニティエコノミクス設計になる気がする。難しく考えてほしくないが、沼れる要素にもなっている。

概念図

ユーザーにとってクリアになった点・よい点

• 感謝を示すためにアシストクレジットを送るときに、自分の持分のことも考えないといけないという複雑性・違和感をなくした。Role Shareという株式に限りなく近い概念に寄せ、感謝を示す目的にそったThanksTokenを導入。
• Thanksトークンは自分に送ることはできないが、「人に送る(新たにMint) = しくみを活性化」という流動性供給もひとつの貢献として、受け取るだけではなく、送ることへのインセンティブもつけた。
• ユーザーが報酬を得るためにやるべきことは
  • 役割をもらって遂行する
  • なるべく長く役割を続ける
  • 他の人が担っている役割の一部を担う・責任を共同で持つことでシェアをもらう
  • 役割で定義されていないものでも積極的に助けて、Thanks Tokenをあつめる
  • 助けられたら積極的にThanks Tokenを送る

検討事項

• 自分のサブアカウントに送るもしくは、サブアカウントから送るというのをどのように防ぐか。
  • 役割を持っている人がおくれるようにするということなら、そもそも役割を与えないという制限をコミュニティでかけられるのでよさそう。
• 各メンバーの他人に送れる量を変更をどのように実行するか。（例: 常にリアルタイムに計算されるようにする / Update関数をつくって誰かがそれを実行することで、全員の配れる量がアップデートされるようにする）
• 期間を区切ってリセットしたいという要望があるので、それをどう実現するか。Thanks Tokenをリセットする、RoleShareをリセットする、などなど。

[takerunakao]

まず質問です。

• Thanksトークンの「人に送る(新たにMint)」とは、他人から受け取ったトークン総量はそのまま（減らない）に、新たに市場にトークンを増やすというイメージでしょうか
• 「Role Share」は（追加発行ルールがあるので）「誰のRole」及び「どのRole」のトークンか、報酬分配フェーズでそれらの区別が重要になる
• 他方「Thanksトークン」は、誰が送ったかの区別は重要ではない、という理解であってますか？

[takerunakao]

• giveとThanksで回るコミュニティの構図はとても良いと思います。Role Shareによるコミュニティへの参加しろの提供（送る側）と巻き取り（受け取る側）やThanks Tokenによる当事者間の貢献度評価&調整で、長期運用によるThanks送り合いが習慣になったとき、現実に近しいコミュニティ貢献の可視化ができ得るものと感じます。
• 「RoleShare」は各コミュニティの各プロジェクト（またはさらに小さく各ロールごと）の任期終了時点でリセット=判断はTobanを運用するコミュニティ側、「Thanks Token」リセットは時限式（四半期、１ヶ月単位など）でも良いと思いました。
• その流動性もコミュニティ活性化の一つの指標となり得る「Thanks Token」は、ある期間で送った人、受け取った人がランキングのようなノリで評価されても面白そう。競争心を煽る訳ではないですが。

[yu23ki14]

@takerunakao

新たに市場にトークンを増やすというイメージでしょうか

そのとおりです

「Thanksトークン」は、誰が送ったかの区別は重要ではない

はい、貢献定量化や報酬分配時には重要でなくなります。ただ、新規mint量が各メンバーの役割や従事期間によって決まるようにしており、重要な役割を長くやっている人の意志が相対的に強く働きやすいようになっています。シビルアタックを防ぐ効果も期待しています。