​​熟議の流れについて
​​

​​フロー

  1. ​​提案者は、500DAIの供託とともに「Problem」と「Type」を記述したleglangファイルをブロックチェーンへ提出する。Problemは文字列であり、Typeは「通常(normal)、任命(assignment)、罷免(dismissal)、変数変更(variableUpdate)」がある。また、通常提案が国庫のうちの予めブロックチェーンに設定された比率(例: 0.25%)を上回る場合は自動的に「大規模熟議」となる。
  1. ​​ブロックチェーンは、予めブロックチェーンに設定された人数の審議員らを抽選し、提案に登用する。
  1. ​​審議員らは、その提案を審議するに値するか決議を取る。
  1. ​​議決がTypeに依存した閾値を大きく下回るなら供託没収と熟議停止。
  1. ​​審議するに値すると判断された提案には、予めブロックチェーンに登録されたファシリテーターらからランダムに1名登用される
  1. ​​ファシリテーターは提案にジャンルタグを任意の数だけ付与する
  1. ​​ジャンルタグに対応した、予めブロックチェーンに登録された専門家らがランダムに登用される
  1. ​​参加者らは提案にModreq(Modification Request)を提出し、任意の数の「Proposal」を提案に記述する。
  1. ​​Modreqの型は「problemId, proposalIndex, docIndex, List<Map<Map<CMD,string>,Map<targetLine,uint>,Map<newlineURL,URL>>>, quorum」である。つまりModreqは多数決によりマージされる。
  1. ​​Proposalは、どのサブセットにいくら予算を注入するかを示す「Headerクラス」と、どのような法令を追加するかを示す複数の「Lawクラス」を持つ
  1. ​​HeaderとLawは同じ「Docクラス」を継承しており、Docクラスは「List<Map<uint, URL>>型」である。つまり各行の文章をIPFSに保存したURLを持つ。
  1. ​​一通りModreqとQuorumが繰り返され、ProblemのProposalsが整ったところで、任命熟議は「ボルダルールに基づく投票」を行い、通常熟議と変数変更提案は「中央値ルールに基づく投票」を行い、大規模熟議と罷免熟議は多数決を行う。FinalJudgeTxが投票を担い、Proposalそれぞれに順位をつけることとなる。順位に対応したスコアがProposalに蓄積する。
  1. ​​最もスコアの高いProposalが採用され、Header情報を参照して予算が指定のサブセットに届き、対応するLawはLawViewerから参照される対象となる。
​​
​​

​​「決め方」について

​​ボルダルール

​​複数の性質の異なる選択肢から「多数派ではなく全員のために選ぶとき」に有効。合議的で、ある地区やジャンルの政治家を候補者から選ぶときに良い。
​​→任命熟議
​​

​​中央値ルール

​​グラデーションのある複数の選択肢から一つ選択するのに良い。合議的。政策の具体化に好相性。
​​→通常熟議, ​+変数更新提案​ 
​​

​​多数決

​​二択によい。全体のためというより多数派のための選択になるため、マイノリティはあえて黙殺される。正解のない究極の二択によい。
​​→Modreq,大規模熟議,罷免熟議, ​+Citizen Revision Proposal (国民増減提案)​ 
​​
​​

​​参考

​​ProposalDSL,LawDSL,LawViewerの原型について: ​+LVM​ 
​​UI要素およびラフ案参照: ​+熟議UIプロト​
​​