新城＠筑波大学情報です。こんにちは。

In article <bgnbs6$v31@utogw.gssm.otsuka.tsukuba.ac.jp>
        kuno@gssm.otsuka.tsukuba.ac.jp writes:
> > 新城案だと、nested transaction の技術を使って「議案」のグルー
> > プかが行われます。CFD は、期間を決めるためだけのものなので、
> > １つの「議案」／「選択単位」だけでなくて複数の「議案」／「選
> > 択単位」が成立する可能性がありすま。
>   えーと。これも多分同じです。もしかしたら私の「選択単位」は新城
> さんの「議案のグループ」なんだと思います。

１つの「選択単位」からは、たかだか１つのニュースグループが作
られるのでしたら、別です。新城の議案のグループだと、複数のニュー
スグループが作られることがあります。

> > 議論の進行で別によい代案が得られた時には、別の「議案」として提出する。
> > この場合、元の「議案」は取り下げてることにより不成立を確定させるか、ま
> > たは、新しい「議案」と互いに対立する「議案」として残す。
>   すごい勢いで番号が消費されそうだけど了解です。

私は実際にはそんなにたくさんの議案が公式に提出されるとは思い
ません。最近の例だと、fj.net.review は、提案者が取り下げて消
えたものでしょう。その他に、「言ってみただけ」のような非公式
の提案は、いろいろ出てくるでしょうが、公式の「議案」提出にま
でいたらないで消えていくものも多いでしょう。fj.net.watch の
例だと、watch が付く公式の「議案」としては、fj.net.watch く
らいしか残らなかったと思います。自分の出した議案が否決される
のを見るのは、そんなに楽しいものではないですから。

>   CFRなくすんですね、OKです。

議案は、提案者が取り下げれば、それで終りなので、CFR は不要に
なります。CFR を見て、作成反対の意味で objection を出すよう
な話も、なくなります。

> > 「議案」は、次のいずれかの場合に不成立が確定する。
> >     (1) 提案者が取り下げた時
> >     (2) 依存している「議案」が不成立になった時
> >     (3) 対立している「議案」が成立した時
> >     (4) CFD期間が終了した時
>   依存/対立有無の管理人認定でもめそうかなあ。もっと機械的に決め
> たらいいような気がしないでもない。まあ先に行きましょう。

「議案」を出した人が、ヒントを出して、管理人が追認する、とい
うイメージです。管理人の認定でもめることは、ないですね。管理
人の決定が、final decision です。

> > 独立した「議案」は、できるだけ同時に審議する。
>   ??? 意味不明です。独立したって、まったく無関係なのも?

はい。まったく無関係のものが独立です。少し関係しているけど、
まあ、両方アリというなら、独立にしてもいいです。議論は、独立
と認定したら、普通は並行してやりますが、独立のものでも逐次化
してもかまわないと思います。それが「できるだけ」の意味です。
数が多いとか、人間の処理する量を越えたした時には、逐次化ＯＫ。

> > 管理人は、ニュースグループの一覧表に矛盾が生じるような「議案」を別の 
> > CFD に変更することができる。管理人は、「議案」の審議の順番を分かりやす
> > いように入れ替えることができる。
>   うーん。これも管理人の権限拡大なのね。あと、順番が分かりません。
> どっかに順番が問題になることが出て来るんですか。

順番の問題はあります。最近の例では、fj.net.watch の議論と 
fj.news.from.X の議論が、逐次化されて、先に fj.net.watch を
議論するということになりました。現在の管理人も、議論の順番を
決める権限があります。私の案は、それを追認して明記したけなの
で現在の管理人の権限拡大にはなっていないと思います。

>   その点をいくらか手直しする(と自分で思う)案を出します。
> ・CFDは1つ以上の選択単位を含み、選択単位は1つ以上の議案を含む。
> ・提案者は議案を提出する際、所属CFDを明示する。管理人が採否を判断。

３階層に固定というのは、固定という意味では分かりやすいですね。
CFDの提出、議案の提出、選択単位の提出の３つがあるという意味
では複雑です。新城案は、「議案」の提出しかありません。CFDは、
自然にできるので、誰かが提出する必要はありません。

あと、問題になるのは、提出したものの取り下げができるかですね。
投票ならめんどくさいから取り下げとか。取下げが入ると、一般に
は話が急激に複雑になります。CFSの取下げとかバックトラックは、
事実上使えません。提出が１種類しかなければ、耐えられます。

以上をふまえて改訂版を作りました。状態遷移図を付けてみました。

----------------------------------------------------------------------

楽観的スケジューリング可能な次世代NGMP案(v4)


*0. NGMP について
＜後で＞

*1. 「議案」

*1.1 議案の状態遷移

                  可決
                 +----------------> [[成立]]
                 |                     ^
       提出      |    仮可決           | 対立不成立、依存成立
[初期] ----> [審議中] -----------> [確定待ち]
                 |                     | 対立成立、依存不成立
                 |                     v
                 +---------------> [[不成立]]
                 取下、否決、
                 依存不成立、満了

イベント

      提出: 形式に乗っ取った記事の投稿
      可決: CFA/CFV/CFSで承認(対立する議案、または、依存している議案がない時)
    仮可決: CFA/CFV/CFSで承認(対立する議案、または、依存している議案がある時)
      否決: CFV/CFSで不承認
      取下: 提案者が取下げ
      満了: CFD期間満了
依存  成立: 依存している全ての「議案」が成立
依存不成立: 依存している何れかの「議案」が不成立
対立  成立: 対立している何れかの「議案」が成立
対立不成立: 対立している全ての「議案」が不成立

*1.2 CFDの状態遷移

       議案提出            時間切れ
[初期] ---------> [議論中] ---------> [[議論終了]]
                           短縮

イベント

議案提出: 最初の「議案」が提出された
時間切れ: 最初の議案が提出されてから２ヶ月経過した
    短縮: 審議中の「議案」がなくなった

*1.3 「議案」

ニュースグループの一覧表に変更を加える提案を、「議案」という。「議案」
の提出は、形式を満たした記事が指定されたニュースグループに投稿され、管
理人が確認することで公式なものとなり、審議される。

「議案」を提出した人を提案者と呼ぶ。

「議案」は、提案者と内容によって識別される。同一内容の「議案」を複数の
人が前後して提出しても、それぞれ有効な２つの「議案」と見なす。提案者の
交替は、認めない。

「議案」には、次のような種類がある。
    (1) 新しいニュースグループの作成
    (2) 既存のニュースグループの削除
    (3) 既存のニュースグループの、憲章案、状態
        (moderated/unmoderated)の変更

提案者は、「議案」を取り下げることができる。

「議案」は、成立するか、不成立が確定することにより消滅する。「議案」が
成立した場合、それに基づきニュースグループの一覧表が書き換えられる。

[解説: このレベルで改名はない。改名は、依存した２つの「議案」を表すマ
クロとて扱う。]

[解説: 提出時に相互排除の機能がないので、ほとんど同時に複数の人がまっ
たく同じ「議案」を提出することはある。それは対立した議案になるが、成立
しても同じなのでそのままにしてもよい。どちらかが取り下げた方がわかりや
すい。]

**1.4「議案」の関係

ある「議案」と別の「議案」は、次のいずれかの関係を持つ。
    (1) 独立(無関係)
    (2) 依存
    (3) 対立

提案者は、既に審議中の「議案」、または、CFD と、これから提出する「議案」
の関係をヒントとして述べる。最終的に「議案」と「議案」の関係、および、
「議案」とCFDの関係は、管理人が決定する。

[解説: 議論の進行で別によい代案が得られた時には、別の「議案」として提
出する。この場合、元の「議案」は取り下げるか、または、新しい「議案」と
互いに対立する「議案」として残す。]

**1.5 「議案」とCFD

類似の「議案」を一括して審議することの呼び掛けを、CFD (Call for
Discussion) と呼ぶ。CFDのための期間を CFD 期間と呼ぶ。

1つの CFDには、複数の「議案」が属することがある。

CFD期間は、最初の「議案」が提出された時に開始される。

CFD 期間は、標準で２ヶ月とする。類似の「議案」を審議するためのCFDを開
始するには、前回の開始から３ヶ月以上開ける必要がある。

CFD期間は、属している「議案」が全て成立した場合に終了する。管理人は、
あるCFDに属している「議案」がなくなった時には、CFD期間を終了させること
ができる。

[解説: CFDを識別するために、管理人がシンボリックな名前をつけ
るとわかりやすい。最初に提出された「議案」を使ってもよい。]

**1.6「議案」の成立と不成立

提案され、審議中になった議案は最終的には成立するか不成立になる。

審議中の「議案」は、次のいずれかの時に成立する。
    (1) CFA/CVF/CFSで承認された時
    (2) CFD期間満了時に管理人がCFAを選択した時

審議中の「議案」は、次のいずれかの場合に不成立となる。
    (1) 提案者が取り下げた時
    (2) CVF/CFSにより承認されなかった時
    (3) 依存している「議案」が不成立になった時
    (4) 対立している「議案」が成立した時
    (5) CFD期間が満了した時

[解説: CFR はない。提案者が取り下げれば終わり。代りに他の人がまったく
同じ内容で「議案」を出してもよい。この場合は「議案」としては別だが、
CFDは引き継がれる。]

[解説:「議案」を出したまま提案者が居なくなることを許容する。提案者が居
なくなった「議案」は、CFD期間満了時に回収される。]

**1.7 仮可決

ある「議案」は、他に対立する「議案」や依存している「議案」がない場合、
CFA/CFV/CFV の結果により、成立、または、不成立が確定し、審議を終了する。

ある「議案」は、他に対立する「議案」や依存している「議案」がある場合、
CFA/CFV/CFV の結果により、仮に成立、または、不成立を定め、審議を終了す
る。最終的な結果は、それらの対立、または、依存しいる議案の結果による。

対立している議案は、最も支持の数(yesの数)が多いものが成立する。

対立した「議案」に関して CFV/CFS が行われる時には、期間を統一した方が
望ましい。また、形式としては、選択的投票(１通の投票用紙で複数の中から
選択する)が望ましい。

**1.8 「議案」の審議の順序

「議案」の審議の順序は、司会者である管理人が決定する。

独立した「議案」は、できるだけ同時に審議することが期待されている。

管理人は、依存した「議案」や対立した「議案」の審議を１つの CFD の中で
同時に行うことができる。

管理人は、ニュースグループの一覧表に矛盾が生じるような「議案」を別の 
CFD に変更することができる。管理人は、「議案」の審議の順番を分かりやす
いように入れ替えることができる。

**1.9 改名

改名とは、２つの互いに依存した「議案」により行われる。たとえば、従来の 
rename fj.X -> fj.Y の改名は、次の２つの互いに依存した「議案」として扱う。
    「議案」#1 fj.X の削除
    「議案」#2 fj.Y の作成

*2 例

**2.1 分割

次のようなニュースグループの分割を互いに依存した「議案」として審議する
ことができる。
    「議案」#1 fj.sys.sunの削除
    「議案」#2 fj.os.sunosの作成
    「議案」#3 fj.os.solarisの作成

**2.2 対立する「議案」

次の２つは、独立した「議案」としても対立する「議案」として扱ってもよい。
最終的な判断は管理人に任される。
    「議案」#1 fj.net.xdsl の作成
    「議案」#2 fj.net.access-line.adsl の作成

対立した「議案」と判断した場合、管理人は、できるだけ議論を同時に進める。
そして、CFA/CFV/CFS の時期を調整する。CFVやCFSが行われる場合には、投票／
署名を行う人が便利なように方法なども調整する。

**2.3 依存する「議案」

次のような「議案」は、依存したものとして扱うべきである。
    「議案」#1 fj.guide の作成
    「議案」#2 fj.guide.d の作成

ここで、「議案」#2 だけ先に成立することがある。しかし、「議案」#1 が不
成立になった場合、「議案」#2 も不成立になる。

次のような「議案」を、依存したものとしても独立したものとしても扱うこと
ができる。
    「議案」#1 fj.archives.documents の削除
    「議案」#2 fj.guide の作成

**2.4 相対解釈

次の２つの「議案」を、独立したものとして扱ってよい。
    「議案」#1 fj.lang.* -> fj.comp.lang.* (実際にには改名は個々にして解釈する)
    「議案」#2 fj.lang.ruby の作成

ここで、「議案」#2 は、「議案」#1 が先に成立した場合、
fj.comp.lang.ruby の作成と見なす。

**2.5 fj.net.watch 問題

１つの CFD「ネット上で起きている興味深い/面白いことがら」で、次の５つ
の「議案」を同時に議論することができる。

    議案１: fj.net.watch を作る
    議案２: fj.net.from.misc を作る
    議案３: fj.net.from.2ch を作る
    議案４: fj.net.from.blog を作る
    議案５: fj.net.from.slasdot を作る

この時、次の２つは対立している議案として扱う。

    議案１: fj.net.watch を作る
    議案２: fj.net.from.misc を作る

したがって、どちらかが成立すれば、どちらかが不成立が確定する。

次の議案は、依存しているものとして扱うことができる(nested transaction)。
(独立したものとして扱うこともできる。)

    議案２: fj.net.from.misc を作る
        議案３: fj.net.from.2ch を作る
        議案４: fj.net.from.blog を作る
        議案５: fj.net.from.slasdot を作る

依存したものとして扱った場合、議案２の不成立が確定したら、議案３から議
案５も自動的に不成立になる。議案３から議案５が先に成立していたとしても、
議案２が不成立が確定すれば、遡って不成立になる。

ただし、議案２が成立したとしても、議案３から議案５が自動的に成立するわ
けではない。たとえば、議案３が成立して、議案４画不成立ということはある。

*end 終り

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼