Next NGMP Modification?
ku...@gssm.otsuka.tsukuba.ac.jp
NGMP改定ですが、「小改定」として取り上げてきたCFV最低票数の変
更は下限撤廃で決着し、委員信任数はアンケート結果も明確なので(別
件の問題はありますが)そのうち何とかなるでしょう。
この先、NGMPについてどうしましょうかね? 私が今回fj.net.watchそ
の他の件で気になったのは、「1つのCFDは1つのグループ」で「重複す
るCFDは許さない」という制約の強さです。まあ矛盾が生じないために
はしょうがないといえばしょうがないんですが。
それで、新城さんが前から主張されている「トランザクションを入れ
る」というのを自分なりに少し考えてみました。新城さんと私では好み
が違いますからカタチも違いますけど。
私の案としては、次のようなイメージ。
・1つのCFDは1つ以上の「選択単位」の集まり。
・1つの「選択単位」にはNG作成/削除/改名などがいくつでも含められ
る。ただしそれらの間に不整合があってはいけない(同一グループを
削除かつ改名とか)。
・CFDはCFXにより最大1個の「選択単位」を採用する。採用された選択
単位の中身が実行される。
・選択単位の追加は「管理人が認定」し、なおかつ「提案者が受諾」す
れば行える。
・管理人は追加を提案されている選択単位が当該CFDに加えるのにふさ
わしいものであるかどうかをチェックする(無関係なものは入れられ
ない)。
・提案者は追加を受諾するか、選択単位追加提案者に提案者をゆずるか
どちらかを選べる。
・選択単位追加提案者は提案者をゆずられた時引き受けるか、追加をあ
きらめるかどちらかを選ぶ。
提案者が大変すぎますかね? 久野
P.S. あと、下限撤廃になった以上、CFSを削除しますか?
IIJIMA Hiromitsu
> P.S. あと、下限撤廃になった以上、CFSを削除しますか?
CFV だと反対者が対抗案を出せないので、個人的には残したほうがいいと思います。
これも下限撤廃したいなあ。
========================================================================
飯嶋 浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp
ku...@gssm.otsuka.tsukuba.ac.jp
delm...@ht.sakura.ne.jpさん:
> > P.S. あと、下限撤廃になった以上、CFSを削除しますか?
> CFV だと反対者が対抗案を出せないので、個人的には残したほうがい
> いと思います。これも下限撤廃したいなあ。
そうですね、そういう意見もあるでしょう。対抗案を入れる手段とし
てはCFDを改造する案(私の前の記事)なんかでもできるかなと思って。
つまり「選択単位」を追加したらCFVはその選択投票に… 久野
Yasushi Shinjo
久々に、「楽観的スケジューリング可能な次世代NGMP案」の改訂版
を出してみます。第３版ということで。
In article <bcmatb$u...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> それで、新城さんが前から主張されている「トランザクションを入れ
> る」というのを自分なりに少し考えてみました。新城さんと私では好み
> が違いますからカタチも違いますけど。
この久野案との違いは、そんなにないです。
> ・1つのCFDは1つ以上の「選択単位」の集まり。
久野案の「選択単位」が、新城案だと「議案」になっています。
> ・CFDはCFXにより最大1個の「選択単位」を採用する。採用された選択
> 単位の中身が実行される。
新城案だと、nested transaction の技術を使って「議案」のグルー
プかが行われます。CFD は、期間を決めるためだけのものなので、
１つの「議案」／「選択単位」だけでなくて複数の「議案」／「選
択単位」が成立する可能性がありすま。
> ・選択単位の追加は「管理人が認定」し、なおかつ「提案者が受諾」す
> れば行える。
> ・管理人は追加を提案されている選択単位が当該CFDに加えるのにふさ
> わしいものであるかどうかをチェックする(無関係なものは入れられ
> ない)。
新城案だと、CFD には提案者は居なくなります。個々の「議案／選
択単位」に提案者が付きます。CFD は、関連した「議案／選択単位」
が自己組織化したようなものです。最終的な認定は、管理人がやり
ます。これは、今のCFDの同一性の判定と同じ仕事です。
> ・提案者は追加を受諾するか、選択単位追加提案者に提案者をゆずるか
> どちらかを選べる。
> ・選択単位追加提案者は提案者をゆずられた時引き受けるか、追加をあ
> きらめるかどちらかを選ぶ。
> 提案者が大変すぎますかね? 久野
新城案だと、提案者は、かなり気軽です。軽く提案できるし、軽く
抜けられます。
ではいきます。複雑に見えるかもしれませんが、１つの「議案」は、
最終的に成立するか不成立になるかしかないので、それが追えれば
どうということはありません。
----------------------------------------------------------------------
楽観的スケジューリング可能な次世代NGMP案(v3)
*0. NGMP について
＜後で＞
*1. 「議案」
ニュースグループの一覧表に変更を加える提案を、「議案」という。「議案」
の提出は、形式を満たした記事が指定されたニュースグループに投稿され、管
理人が確認することで有効になる。
「議案」を提出した人を提案者と呼ぶ。
「議案」は、提案者と内容によって識別される。同一内容の「議案」を複数の
人が前後して提出しても、それぞれ有効な２つの「議案」と見なす。提案者の
交替は、認めない。
「議案」には、次のような種類がある。
(1) 新しいニュースグループの作成
(2) 既存のニュースグループの削除
(3) 既存のニュースグループの、憲章案、状態
(moderated/unmoderated)の変更
提案者は、「案件」を取り下げることができる。
「議案」は、成立するか、不成立が確定することにより消滅する。「議案」が
成立した場合、それに基づきニュースグループの一覧表が書き換えられる。
[解説: このレベルで改名はない。改名は、依存した２つの「議案」を表すマ
クロとて扱う。]
**1.1「議案」の関係
ある「議案」と別の「議案」は、次のいずれかの関係を持つ。
(1) 独立
(2) 依存
(3) 対立
提案者は、既に審議中の「議案」、または、CFD と、これから提出する「議案」
の関係をヒントとして述べる。最終的に「議案」と「議案」の関係、および、
「議案」とCFDの関係は、管理人が決定する。
議論の進行で別によい代案が得られた時には、別の「議案」として提出する。
この場合、元の「議案」は取り下げてることにより不成立を確定させるか、ま
たは、新しい「議案」と互いに対立する「議案」として残す。
**1.2 「議案」とCFD
類似の「議案」を一括して審議することの呼び掛けを、CFD (Call for
Discussion) と呼ぶ。CFDのための期間を CFD 期間と呼ぶ。
1つの CFDには、複数の「議案」が属することがある。
CFD期間は、最初の「議案」が提出された時に開始される。
CFD 期間は、標準で２ヶ月とする。類似の「議案」を審議するためのCFDを開
始するには、前回の開始から３ヶ月以上開ける必要がある。
CFD期間は、属している「議案」が全て成立した場合に終了する。管理人は、
あるCFDに属している「議案」がなくなった時には、CFD期間を終了させること
ができる。
**1.3「議案」成立と不成立確定の条件
「議案」は、次のいずれかの時に成立する。
(1) CFA が成立した時
(2) CVF/CFS が成立した時
「議案」は、次のいずれかの場合に不成立が確定する。
(1) 提案者が取り下げた時
(2) 依存している「議案」が不成立になった時
(3) 対立している「議案」が成立した時
(4) CFD期間が終了した時
[解説: CFR はない。提案者が取り下げれば終わり。代りに他の人がまったく
同じ内容で「議案」を出してもよい。この場合は「案件」としては別だが、
CFDは引き継がれる。]
[解説: 時間切れで管理人による CFA/CFV/CFS/CFR の選択は、できない。自動
的に不成立になる。]
[解説:「議案」を出したまま提案者が居なくなることを許容する。提案者が居
なくなった「議案」は、時間が来たら自動的に不成立になり自動的に回収され
る。]
**1.4 「議案」の審議の順序
独立した「議案」は、できるだけ同時に審議する。
管理人は、依存した「議案」や対立した「議案」の審議を１つの CFD の中で
同時に行うことができる。
管理人は、ニュースグループの一覧表に矛盾が生じるような「議案」を別の
CFD に変更することができる。管理人は、「議案」の審議の順番を分かりやす
いように入れ替えることができる。
対立した「議案」に関して CFA/CFV/CFS が行われる時には、できるだけ期間
を同じにする。この時、最も指示の数(yesの数)が多いものが成立する。形式
としては、選択的投票(１通の投票用紙で複数の中から選択する)が望ましい。
**1.5 改名
改名とは、２つの互いに依存した「議案」により行われる。たとえば、従来の
rename fj.X -> fj.Y の改名は、次の２つの互いに依存した「議案」として扱う。
「議案」#1 fj.X の削除
「議案」#2 fj.Y の作成
*例
**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 終り
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
ku...@gssm.otsuka.tsukuba.ac.jp
y...@is.tsukuba.ac.jpさん:
> 新城＠筑波大学情報です。こんにちは。
どうも。あの～、せっかく私がリクエストして投稿して頂いたのです
が、今日から出張ですぐには検討できないので私の意見は少しお待ち頂
けますか。
他の方と議論されるのはもちろんぜひお願いします 久野
ku...@gssm.otsuka.tsukuba.ac.jp
少し時間ができたので。
y...@is.tsukuba.ac.jpさん:
: それで、新城さんが前から主張されている「トランザクションを入れ
: る」というのを自分なりに少し考えてみました。新城さんと私では好み
: が違いますからカタチも違いますけど。
> この久野案との違いは、そんなにないです。
それは楽しみ。
: ・1つのCFDは1つ以上の「選択単位」の集まり。
> 久野案の「選択単位」が、新城案だと「議案」になっています。
それは用語の違いだから。「議案」にしておきましょう。
: ・CFDはCFXにより最大1個の「選択単位」を採用する。採用された選択
: 単位の中身が実行される。
> 新城案だと、nested transaction の技術を使って「議案」のグルー
> プかが行われます。CFD は、期間を決めるためだけのものなので、
> １つの「議案」／「選択単位」だけでなくて複数の「議案」／「選
> 択単位」が成立する可能性がありすま。
えーと。これも多分同じです。もしかしたら私の「選択単位」は新城
さんの「議案のグループ」なんだと思います。
それで、複数のグループが同時に成立することはあるのないの? まあ
後を読めばいいんですけど。
: ・選択単位の追加は「管理人が認定」し、なおかつ「提案者が受諾」す
: れば行える。
: ・管理人は追加を提案されている選択単位が当該CFDに加えるのにふさ
: わしいものであるかどうかをチェックする(無関係なものは入れられ
: ない)。
> 新城案だと、CFD には提案者は居なくなります。個々の「議案／選
> 択単位」に提案者が付きます。CFD は、関連した「議案／選択単位」
> が自己組織化したようなものです。最終的な認定は、管理人がやり
> ます。これは、今のCFDの同一性の判定と同じ仕事です。
これは好みが別れるところですが、私は譲歩可能、つまり個々の議案
に提案者がつくんでもいいです。
: ・提案者は追加を受諾するか、選択単位追加提案者に提案者をゆずるか
: どちらかを選べる。
: ・選択単位追加提案者は提案者をゆずられた時引き受けるか、追加をあ
: きらめるかどちらかを選ぶ。
> ではいきます。複雑に見えるかもしれませんが、１つの「議案」は、
> 最終的に成立するか不成立になるかしかないので、それが追えれば
> どうということはありません。
はいはい。
> 「議案」は、提案者と内容によって識別される。同一内容の「議案」を複数の
> 人が前後して提出しても、それぞれ有効な２つの「議案」と見なす。提案者の
> 交替は、認めない。
なんか番号を割り振るといいと思いませんか。
> 「議案」には、次のような種類がある。
> (1) 新しいニュースグループの作成
> (2) 既存のニュースグループの削除
> (3) 既存のニュースグループの、憲章案、状態
> (moderated/unmoderated)の変更
>
> 提案者は、「案件」を取り下げることができる。
これは「議案」の間違いじゃないの?
> 「議案」は、成立するか、不成立が確定することにより消滅する。「議案」が
> 成立した場合、それに基づきニュースグループの一覧表が書き換えられる。
>
> [解説: このレベルで改名はない。改名は、依存した２つの「議案」を表すマ
> クロとて扱う。]
それは賛成です。
> ある「議案」と別の「議案」は、次のいずれかの関係を持つ。
> (1) 独立
> (2) 依存
> (3) 対立
はいはい。
> 提案者は、既に審議中の「議案」、または、CFD と、これから提出する「議案」
> の関係をヒントとして述べる。最終的に「議案」と「議案」の関係、および、
> 「議案」とCFDの関係は、管理人が決定する。
ううううむ。その決定に対する異義は認めないとしていいの?
> 議論の進行で別によい代案が得られた時には、別の「議案」として提出する。
> この場合、元の「議案」は取り下げてることにより不成立を確定させるか、ま
> たは、新しい「議案」と互いに対立する「議案」として残す。
すごい勢いで番号が消費されそうだけど了解です。
> CFD期間は、属している「議案」が全て成立した場合に終了する。管理人は、
> あるCFDに属している「議案」がなくなった時には、CFD期間を終了させること
> ができる。
なるほどね、成立とは何かですが。
> **1.3「議案」成立と不成立確定の条件
>
> 「議案」は、次のいずれかの時に成立する。
> (1) CFA が成立した時
> (2) CVF/CFS が成立した時
CFRなくすんですね、OKです。
> 「議案」は、次のいずれかの場合に不成立が確定する。
> (1) 提案者が取り下げた時
> (2) 依存している「議案」が不成立になった時
> (3) 対立している「議案」が成立した時
> (4) CFD期間が終了した時
依存/対立有無の管理人認定でもめそうかなあ。もっと機械的に決め
たらいいような気がしないでもない。まあ先に行きましょう。
> [解説: 時間切れで管理人による CFA/CFV/CFS/CFR の選択は、できない。自動
> 的に不成立になる。]
それは他の部分の設計とは独立ですね? fj参加者の皆様の考え次第と
思っています。
> 独立した「議案」は、できるだけ同時に審議する。
??? 意味不明です。独立したって、まったく無関係なのも?
> 管理人は、依存した「議案」や対立した「議案」の審議を１つの CFD の中で
> 同時に行うことができる。
それはいいですが。
> 管理人は、ニュースグループの一覧表に矛盾が生じるような「議案」を別の
> CFD に変更することができる。管理人は、「議案」の審議の順番を分かりやす
> いように入れ替えることができる。
うーん。これも管理人の権限拡大なのね。あと、順番が分かりません。
どっかに順番が問題になることが出て来るんですか。
> 対立した「議案」に関して CFA/CFV/CFS が行われる時には、できるだけ期間
> を同じにする。この時、最も指示の数(yesの数)が多いものが成立する。形式
> としては、選択的投票(１通の投票用紙で複数の中から選択する)が望ましい。
確かに私と新城さんの案に本質的な対立はないです。ただ、「議案の
グループ化」「議案のCFDへの所属/転属」に関して管理人の裁定事項が
増えているのでそれで容れられるかどうかというのが心配です。
その点をいくらか手直しする(と自分で思う)案を出します。
・CFDは1つ以上の選択単位を含み、選択単位は1つ以上の議案を含む。
・提案者は議案を提出する際、所属CFDを明示する。管理人が採否を判断。
・選択単位は議案の(排他的でない)集合であり、fjでの議論に基づき管
理人が指定する。
・どの選択単位にも含まれない議案もあってよい(提案者が逃げたり撤
回した場合)。
・選択単位のうち最大1つだけが成立(その時それに含まれる議案も成立
する)。
・選択単位をFIXした後、CFAかCFVかCFSを行う。CFAは選択単位の数が1
つの時のみ使用可能。
・CFA/CFV/CFS管理者はfjでの議論に基づき管理人が指定する。
これくらいでどうでしょう? 久野
Yasushi Shinjo
In article <bgnbs6$v...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@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 分割
**2.2 対立する「議案」
**2.3 依存する「議案」
**2.4 相対解釈
**2.5 fj.net.watch 問題
この時、次の２つは対立している議案として扱う。
したがって、どちらかが成立すれば、どちらかが不成立が確定する。
次の議案は、依存しているものとして扱うことができる(nested transaction)。
(独立したものとして扱うこともできる。)
議案２: fj.net.from.misc を作る
議案３: fj.net.from.2ch を作る
議案４: fj.net.from.blog を作る
議案５: fj.net.from.slasdot を作る
依存したものとして扱った場合、議案２の不成立が確定したら、議案３から議
ku...@gssm.otsuka.tsukuba.ac.jp
> １つの「選択単位」からは、たかだか１つのニュースグループが作ら
> れるのでしたら、別です。新城の議案のグループだと、複数のニュー
> スグループが作られることがあります。
同じですよ。1つの選択単位から複数のグループが作られることが
あるつもりです。でないと今回のfj.net.watchの新城案みたいなのが
入れられないから改良の意味がないよね。
私が「1つ」と書いたのは「選択単位のうちただ1つが成立する」とい
う意味でした。atomic transactionってそういう感じじゃないですか。
競合するものの中からは1つだけが(中のオペレーション一括で)成立す
るという。
> 私は実際にはそんなにたくさんの議案が公式に提出されるとは思い
> ません。最近の例だと、fj.net.review は、提案者が取り下げて消
> えたものでしょう。その他に、「言ってみただけ」のような非公式
> の提案は、いろいろ出てくるでしょうが、公式の「議案」提出にま
> でいたらないで消えていくものも多いでしょう。fj.net.watch の
> 例だと、watch が付く公式の「議案」としては、fj.net.watch く
> らいしか残らなかったと思います。自分の出した議案が否決される
> のを見るのは、そんなに楽しいものではないですから。
その気分も分かりますし重要ですよね。取り下げは「取り下げた」と
公告した時のみ? または返事がないとかで委員が認定もある? (それは
委員の仕事が増えるかもねえ。)
> > CFRなくすんですね、OKです。
>
> 議案は、提案者が取り下げれば、それで終りなので、CFR は不要に
> なります。CFR を見て、作成反対の意味で objection を出すよう
> な話も、なくなります。
ただねえ、CFRが入った経緯として、誰かがある案を提案していてそ
れが自分の考えてることと同じだから安心していたら直前になって提案
者が取り下げて自分が推したい選択肢がなくなったとか、そういうこと
に対する心配があるんじゃないですかね。でもそうは言っても、私も
CFRって面倒だと思うし、なくて済ませられるならそうしたいかな。
> > > 「議案」は、次のいずれかの場合に不成立が確定する。
> > > (1) 提案者が取り下げた時
> > > (2) 依存している「議案」が不成立になった時
> > > (3) 対立している「議案」が成立した時
> > > (4) CFD期間が終了した時
> > 依存/対立有無の管理人認定でもめそうかなあ。もっと機械的に決め
> > たらいいような気がしないでもない。まあ先に行きましょう。
> 「議案」を出した人が、ヒントを出して、管理人が追認する、とい
> うイメージです。管理人の認定でもめることは、ないですね。管理
> 人の決定が、final decision です。
管理人がいっそう矢面に立つことになるんでね。
> > > 独立した「議案」は、できるだけ同時に審議する。
> > ??? 意味不明です。独立したって、まったく無関係なのも?
>
> はい。まったく無関係のものが独立です。少し関係しているけど、
> まあ、両方アリというなら、独立にしてもいいです。議論は、独立
> と認定したら、普通は並行してやりますが、独立のものでも逐次化
> してもかまわないと思います。それが「できるだけ」の意味です。
> 数が多いとか、人間の処理する量を越えたした時には、逐次化ＯＫ。
うーん、そこがね、現行CFDと違うように思うのです。今までみたい
に、「独立(無関係)なら別CFD、別CFDは同時並行でもずれていても逐次
でもいい、関係しているなら一緒のCFDに入れて同時にやり同時に終る」
じゃいけないんでしょうか。
> 順番の問題はあります。最近の例では、fj.net.watch の議論と
> fj.news.from.X の議論が、逐次化されて、先に fj.net.watch を
> 議論するということになりました。現在の管理人も、議論の順番を
> 決める権限があります。私の案は、それを追認して明記したけなの
> で現在の管理人の権限拡大にはなっていないと思います。
ですから、上記のように関係があれば一緒のCFDに入れて同時にやる
から「順番」じゃなくなる、ではダメでしょうか…
: その点をいくらか手直しする(と自分で思う)案を出します。
: ・CFDは1つ以上の選択単位を含み、選択単位は1つ以上の議案を含む。
: ・提案者は議案を提出する際、所属CFDを明示する。管理人が採否を判断。
> ３階層に固定というのは、固定という意味では分かりやすいですね。
> CFDの提出、議案の提出、選択単位の提出の３つがあるという意味
> では複雑です。新城案は、「議案」の提出しかありません。CFDは、
> 自然にできるので、誰かが提出する必要はありません。
では、議案を出すとその議案だけを含む選択単位とその選択単位だけ
を含むCFDが自動的に作成されるというのでどうですか。
> あと、問題になるのは、提出したものの取り下げができるかですね。
> 投票ならめんどくさいから取り下げとか。取下げが入ると、一般に
> は話が急激に複雑になります。CFSの取下げとかバックトラックは、
> 事実上使えません。提出が１種類しかなければ、耐えられます。
やっぱり取り下げをなくということでどうですか。棚ざらしとか放置
とかの実態があればそうPRすればいいだけで、「なくす」ことは要求し
ないという。
あと新城案にある「対立」とか「依存」とかの指定は、あれはあくま
でヒントで管理人がどうするか決める、っていうんだからNGMPには入れ
なくてもいいんじゃないですかね。
> 以上をふまえて改訂版を作りました。状態遷移図を付けてみました。
思うんですけどね～、やっぱり私と新城さんとそれぞれ趣味があるじゃ
ないですか。で、並行線のまま2本提案ができてどっちか選択とかになっ
てもあまり望ましい結果にならなさそうでしょ?
で、提案ですが、新城案の文面を私が頂いて私が好きに直す、次にま
たそれを新城さんが好きに直す、というふうにして1本化してみません
か。どうしても譲れないことがあって収束しないかも知れないけど。
今の「趣味の違いで平行線」よりはいいかもよ。 久野
P.S. もしそれでよければ、v4を頂いて直すかv5を待つか教えてね。
Yasushi Shinjo
In article <bh1fs6$2m...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> ただねえ、CFRが入った経緯として、誰かがある案を提案していてそ
> れが自分の考えてることと同じだから安心していたら直前になって提案
> 者が取り下げて自分が推したい選択肢がなくなったとか、そういうこと
> に対する心配があるんじゃないですかね。
いいえ。そういう心配はありません。
ある提案者がある「議案」を取下げても、別の人がまったく同じ内
容の「議案」をもう一度提出できます。この時、「議案」は取下げ
られても、CFD はそのまま継続しています。それで実質的に提案者
の交替が可能になりますし、選択肢がなくなる心配もありません。
（最初からでも後からでも）１人で複数の選択肢を「議案」として
提出することもできます。現在のNGMPの選択投票は、新しいNGMPで
は、複数の「議案」の間での、同期をとった投票ということでしょう。
> > 「議案」を出した人が、ヒントを出して、管理人が追認する、とい
> > うイメージです。管理人の認定でもめることは、ないですね。管理
> > 人の決定が、final decision です。
> 管理人がいっそう矢面に立つことになるんでね。
どうかなあ。CFDの同一性の認定と同じだと思います。その程度の
矢面に立つのがいやなら、管理人をしなければいいんじゃないです
か。全体的に管理人は暇そうですし。矢面に立っても、プレッシャー
にはなっても暇さは今と変らないでしょう。
> うーん、そこがね、現行CFDと違うように思うのです。今までみたい
> に、「独立(無関係)なら別CFD、別CFDは同時並行でもずれていても逐次
> でもいい、関係しているなら一緒のCFDに入れて同時にやり同時に終る」
> じゃいけないんでしょうか。
現在は、別CFDは、「必ず」並行です。新しい案は、並行も逐次も
管理人が選べます。
もう１つ、現在は、同一CFDと認定していまうと、必ず逐次化され
てしまいます。こら方法は、DoS攻撃に対して脆弱性があります。
たとえば、「CFD rename fj.* x.*」 という CFD が年4回かかった
だけで、fj.news.group.* の全議論が止まります。もう１つ、今の
逐次の問題は、議論の決着がつくのに時間がかかることです。たと
えば、fj.news.from.misc.X の議論が3月遅れになります。新しい
案では、いっしょに投票して既に決着がついていたでしょう。たぶ
ん、いっしょに投票すると「作らない」という決着だったとは思い
ますが、とにかく早期に決着がついていたでしょう。
> ですから、上記のように関係があれば一緒のCFDに入れて同時にやる
> から「順番」じゃなくなる、ではダメでしょうか…
順番というよりは、最初に入れるか、後から入れるか、入れる時に
誰が入れてもいいと判断するか、その辺りが本質的な問題なのでしょ
う。今は、管理人が入れると判断して、提案者が入れないと判断し
て、その判断が分かれた時に問題が発生します。新しい案では、そ
の判断を、管理人に集中するので、そういう問題は発生しません。
そういえば、太古のNGMPでは、CFA も CFV も、CFD 出した人でな
くて誰でも出せましたね。私は、一度、自分が出した CFD のに、
別の人に別の案で CFA が出されて、それがそのまま成立してしまっ
たということがあります。今のように、CFA が提案者だけというの
は、その後の改訂でそうなったものです。いつ誰がどういう経緯で
改訂したものでしょうか。
私の案は、その改訂以前の古い NGMP と似たようなものです。
> やっぱり取り下げをなくということでどうですか。棚ざらしとか放置
> とかの実態があればそうPRすればいいだけで、「なくす」ことは要求し
> ないという。
取下げがないと、早期に収束しない可能性があります。CFV の結果
が出ても、取下げられない「議案」がある限り、CFV の結果は、仮
のままです。その後、取下げられない案でも、CFV が行われて、結
果が覆される可能性があります。取下げれば確定します。取下げず
にいなくなったら、、、まあ管理人が２週間くらい応答がない案を
ＧＣしてもいいんでしょう。
> あと新城案にある「対立」とか「依存」とかの指定は、あれはあくま
> でヒントで管理人がどうするか決める、っていうんだからNGMPには入れ
> なくてもいいんじゃないですかね。
別の項目で、管理人の仕事として明記するといいんじゃないですか
ね。プロトコルということで、イベントの話が中心になっているので。
> 思うんですけどね～、やっぱり私と新城さんとそれぞれ趣味があるじゃ
> ないですか。で、並行線のまま2本提案ができてどっちか選択とかになっ
> てもあまり望ましい結果にならなさそうでしょ?
>
> で、提案ですが、新城案の文面を私が頂いて私が好きに直す、次にま
> たそれを新城さんが好きに直す、というふうにして1本化してみません
> か。どうしても譲れないことがあって収束しないかも知れないけど。
これは、面白い試みですね。それでは、v5 を修正していただけま
せんか。他にも一言二言もっと言いたい人が出てくるともっと面白
くなるかも。
ku...@gssm.otsuka.tsukuba.ac.jp
> ある提案者がある「議案」を取下げても、別の人がまったく同じ内
> 容の「議案」をもう一度提出できます。この時、「議案」は取下げ
> られても、CFD はそのまま継続しています。それで実質的に提案者
> の交替が可能になりますし、選択肢がなくなる心配もありません。
その取り下げから別の人による提出までの間に投票開始しようと
していた場合、投票を繰り延べるの?
> 提出することもできます。現在のNGMPの選択投票は、新しいNGMPで
> は、複数の「議案」の間での、同期をとった投票ということでしょう。
で、どうやって同期を取るということでしょう?
> どうかなあ。CFDの同一性の認定と同じだと思います。その程度の
> 矢面に立つのがいやなら、管理人をしなければいいんじゃないです
> か。全体的に管理人は暇そうですし。矢面に立っても、プレッシャー
> にはなっても暇さは今と変らないでしょう。
プレッシャーがあまり増えると管理人の成り手がいなくなるので、そ
れを心配していますが。まあ大したことはないのかも知れません。
> 現在は、別CFDは、「必ず」並行です。新しい案は、並行も逐次も管
> 理人が選べます。
そこがまだ分かってないのですが、別CFDでも逐次にできるという意
味、それとも同一CFD内でも並行にできるという意味、それとも両方?
> もう１つ、現在は、同一CFDと認定していまうと、必ず逐次化され
> てしまいます。こら方法は、DoS攻撃に対して脆弱性があります。
> たとえば、「CFD rename fj.* x.*」 という CFD が年4回かかった
> だけで、fj.news.group.* の全議論が止まります。
まあ実質止まらないと思うけど、
> もう１つ、今の
> 逐次の問題は、議論の決着がつくのに時間がかかることです。たと
> えば、fj.news.from.misc.X の議論が3月遅れになります。新しい
> 案では、いっしょに投票して既に決着がついていたでしょう。たぶ
> ん、いっしょに投票すると「作らない」という決着だったとは思い
> ますが、とにかく早期に決着がついていたでしょう。
早期に決着できるようにすることは賛成ですよ。
> 順番というよりは、最初に入れるか、後から入れるか、入れる時に
> 誰が入れてもいいと判断するか、その辺りが本質的な問題なのでしょ
> う。今は、管理人が入れると判断して、提案者が入れないと判断し
> て、その判断が分かれた時に問題が発生します。新しい案では、そ
> の判断を、管理人に集中するので、そういう問題は発生しません。
それはつまり、提案者は議案を提出するだけで、CFDのくくりは管理
人が決めるということですね? それはそれでいいかも。
> 取下げがないと、早期に収束しない可能性があります。CFV の結果
> が出ても、取下げられない「議案」がある限り、CFV の結果は、仮
> のままです。その後、取下げられない案でも、CFV が行われて、結
> 果が覆される可能性があります。取下げれば確定します。取下げず
> にいなくなったら、、、まあ管理人が２週間くらい応答がない案を
> ＧＣしてもいいんでしょう。
そうです、GCすることができれば取り下げ(free)は要らないという
そういうつもりでした。
> 別の項目で、管理人の仕事として明記するといいんじゃないですか
> ね。プロトコルということで、イベントの話が中心になっているので。
管理人が決めるならそれで別に異存ないですよ。
> これは、面白い試みですね。それでは、v5 を修正していただけま
> せんか。他にも一言二言もっと言いたい人が出てくるともっと面白
> くなるかも。
まとめると、現在のところ私と新城さんの考えで明確な対立はないよ
うです。
○分からなくて質問してるところ
(1)投票の同期方法について
(2)CFDの「逐次」「並行」について
○合意できると思われる事項
(1)管理人のプレッシャー→とりあえず「ダメ」というつもりはない
(2)新出提案の早期決着について→賛成
(3)議案がどのCFDに所属するかは管理人判断→賛成
(4)提案の取り下げまたはGC→GCに賛成
(5)議案の他の議案との関係→管理人判断ないしNGMPと別途なら賛成
ではv5が出るのを待ちますね。 久野
Yasushi Shinjo
そういえば、CFSng の実験で得られた知恵がありました。
それを採り入れたものを、v5 とします。
In article <bh74rv$1h...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> その取り下げから別の人による提出までの間に投票開始しようと
> していた場合、投票を繰り延べるの?
こういう時には、投票を管理する人が自分で「議案」を提出してし
まって、いっしょに投票に掛けてしまうのが分かりやすい思います。
議論の流れによっては、繰り延べてもいいし、その「議案」なしに
先に投票を始めてしまってもいいでしょう。投票が始まっても、
CFD 期間内なら、別の投票は始められるので、同期をとらなくても
いいのですが、対立している「議案」の投票は、１度に終らせた方
が誰にとってもわかりやすいでしょう。
ただ、投票３週間として、終了直前に新しい投票が始まってもパッ
としないという話もあります。CFSng の時には、CFS の中間結果を
公開してから３週間１位を保てば即成立ということにしました。投
票も、３週間と区切りを入れる必要もなく、１週間くらいで中間結
果を公開してしまって、それが１位の状態が２週間くらい続けば即
成立にするといいかと思います。（公開した後も、CFD 期間内はずっ
と投票は受付けることにします。）
この辺りは、CFV/CFSの「成立」の条件ということにしてしまえば、
「仮成立」という怪しい状態は消せますね。これに気が付きました。
これを反映したものを v5 とします。
で、消してみたのですが、そんなに分かりやすさが改善したかとい
うと、あんまり改善した感じはいません。この部分は、v4 の方が
いいかもしれません。
> > 提出することもできます。現在のNGMPの選択投票は、新しいNGMPで
> > は、複数の「議案」の間での、同期をとった投票ということでしょう。
> で、どうやって同期を取るということでしょう?
そういう時は、管理人が出てきて、「この CFD では、これこれで
同期をとって、投票で決着をつけたいと思います、準備よろしく」
と宣言します。それに従わない人が出てきても、プロトコルとして
は、ＯＫではあります。
> プレッシャーがあまり増えると管理人の成り手がいなくなるので、そ
> れを心配していますが。まあ大したことはないのかも知れません。
そういう話は、時々見ますが、今まで管理人のなり手が居なくなっ
たことを見たことがありません。
> > 現在は、別CFDは、「必ず」並行です。新しい案は、並行も逐次も管
> > 理人が選べます。
> そこがまだ分かってないのですが、別CFDでも逐次にできるという意
> 味、それとも同一CFD内でも並行にできるという意味、それとも両方?
新しい案では、別CFDでも逐次にもできます。fj.comp.X と
fj.rec.Y を逐次にしてもいいです。
> それはつまり、提案者は議案を提出するだけで、CFDのくくりは管理
> 人が決めるということですね? それはそれでいいかも。
はい。CFDと議案の関係と、CFDとCFDの関係(CFDの順序)の話を、分
けてみました。
----------------------------------------------------------------------
次世代NGMP案(v5)
最終更新: v5 2003/08/11 新城 靖
*0. NGMP について
＜後で＞
*1. 「議案」
*1.1 議案の状態遷移
可決
+----------------> [[成立]]
|
提出 |
[初期] ----> [審議中]
|
|
+---------------> [[不成立]]
応答なし、取下、
否決、満了
イベント
提出: 形式に乗っ取った記事の投稿
可決: CFA/CFV/CFSで承認
否決: (CFR)/CFV/CFSで不承認
取下: 提案者が取下げ
満了: CFD期間満了
*1.2 CFDの状態遷移
議案提出 認定 時間切れ
[初期] ---------> [開始待ち] ---> [議論中] ---------> [[議論終了]]
早期満了
イベント
議案提出: 最初の「議案」が提出された
認定: 管理人による認定
時間切れ: 最初の議案が提出されてから２ヶ月経過した
早期満了: 審議中の「議案」がなくなった場合などに管理人が短縮
*1.3 「議案」
ニュースグループの一覧表に変更を加える提案を、「議案」という。「議案」
の提出は、形式を満たした記事が指定されたニュースグループに投稿され、管
理人が確認することで公式なものとなる。管理人は、提出された「議案」が属
する「CFD(後述)」を決定する。
「議案」を提出した人を提案者と呼ぶ。
「議案」は、提案者と内容によって識別される。同一内容の「議案」を複数の
人が前後して提出しても、それぞれ有効な２つの「議案」と見なす。審議中の
議案は、提案者の交替、および、内容の変更を行うことはできない。
「議案」には、次のような種類がある。
(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を並行に審議
するように努める。管理人は、CFDの類似性の判定を行い、類似のCFDの議論を
開始を、前回のCFD開始から３ヶ月以上開けることができる。管理人は、複雑
に入り組んだCFDを簡潔にするために、CFDの審議を逐次化することができる。
[解説: CFDを識別するために、管理人がシンボリックな名前をつけるとわかり
やすい。最初に提出された「議案」を使ってもよい。]
**1.6「議案」の成立と不成立
提案され、審議中になった議案は最終的には成立するか不成立になる。
審議中の「議案」は、次のいずれかの時に成立する。
(1) CFA/CFV/CFSにより承認された時
(2) (CFD期間満了時に管理人がCFAを選択した時)
審議中の「議案」は、次のいずれかの場合に不成立となる。
(1) 提案者が取り下げた時
(2) (CFR)/CVF/CFSにより承認されなかった時
(3) CFD期間が満了した時
(4) 提案者からの応答が２週間無かった時
[解説: CFR はなくてもよい。]
[解説: 満了時のCFA選択はなくてもよい。]
**1.7 CFA/(CFR)よる承認の条件
CFAは、ある「議案」が沈黙により承認されたことを確認することである。
次のような条件が成立した場合、CFA により承認されたと見なす。
(1) ２週間の間、異議が提出されなかった。
[解説: CFR がいるならここに定義を加える。]
**1.8 CFV/CFSによる承認の条件
CFV/CFS は、ある「議案」が投票、または、署名により承認されたことを確認
することである。
CFV/CFV では、CFD期間満了前に中間結果を発表することができる。
CFD期間満了時の結果を、最終結果と呼ぶ。管理人は、必要に応じ
て中間結果を公表させることができる。CFV/CFSで、投票、または、
署名を管理している人は、管理人が中間結果の公表を求めた場合、
それに応じなければならない。
次の条件が「全て」が満たされた時、承認されたとする。
(1) 公表された結果(中間、または、最終)において支持の数(yesの数)
が不支持の数(noの数)を上回っている。
(2) その時点で、対立する全ての「議案」の中で、支持の数(yesの数)
の数が最も多い。
(3) 過去２週間の間、(1)および(2) の状態が続いたか、また
は、最終結果において、支持の数が多かった
次の条件の「何れか」が満たされた時、承認されなかったとする。
(1) (中間)結果が公表され、不支持の数(noの数)が支持の数
(yesの数)を上回り、かつ、その状態が２週間継続した。
(2) 最終結果で、不支持の数(noの数)が支持の数(yesの数)を
上回った。
(3) 依存している「議案」が、不成立になった。
(4) 対立している「議案」が、成立した。
[解説: CFV/CFV は、中間結果も公表できる。ショートカットとし
て、２週間の間、ある「議案」の yes の数がずっと１位であり続
ければ、成立する。]
[解説: ある CFS/CFV の中間結果が公表されても、CFD 期間内なら
２週間以内にその数よりもたくさんの投票／署名を集めれば逆転で
きる。この性質から、CFS は重み付き CFA と思ってもよい。]
[解説: 対立した「議案」に関して CFV/CFS が行われる時には、同
期をとり、投票結果が同時に現れるようにした方が分かりやすい。
形式としては、選択的投票(１通の投票用紙で複数の中から選択す
る)が望ましい。]
[解説：CFV/CFS で同期を取らなかった場合、(中間)結果はバラバ
ラのタイミングで公開される。管理人は、この条件を確認するため
に、あるCFV/CFSの結果が公表された場合、２週間後に、他の「議
案」についても結果を公表させる。]
[解説: CVS/CFV の結果を公表しないという攻撃に対して、脆弱性
がある。]
[解説: CFV/CFS の提出時期に関する規制をかける必要がある。た
とえば、CFD 開始直後、議論がないままの CVV/CFS を避けるなど。]
**1.9 改名
改名とは、２つの互いに依存した「議案」により行われる。たとえば、従来の
rename fj.X -> fj.Y の改名は、次の２つの互いに依存した「議案」として扱う。
「議案」#1 fj.X の削除
「議案」#2 fj.Y の作成
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
ku...@gssm.otsuka.tsukuba.ac.jp
せっかく「NG」という言葉が入っているのでちょっとSubject変えて
みました :-)
さて、新城案v5を土台としたNGMP改定案を作成してみました。まとめ
ていて思ったのですが、今の「提案者が全部やれ」からこれくらい管理
委員会がサービスするように直さないとNGMP使ってくれない、というこ
とかなあ。そう考えるならわりといいんじゃないでしょうか。提案者優
先がなくなった代わりに提案者が気楽に使える、CFDも管理人がやって
くれる、投票管理が嫌なら逃げてもいい。サービスしすぎかも知れませ
んがいまどきはこれでいいという考えもあるかと。
あと新城さんの「2週間連続して一位」「同期取らない」は今回はか
んべんしてほしい…それをきっちり規定するNGMP的文章が作れる自信が
私にはないですし、そこまでやるとfj参加者がついて来ないと思う。だ
からCFX中は状態変更しない、としました。とりあえずこれくらいにし
ときませんか…他のことが直せるだけでも嬉しいでしょ?
と、以上は説得ですが、約束通りこれを新城さんがどのように直され
ても構いません。
ということでどぞ。 久野
---
NGMP改定案(新城・久野版)
v6 2003/08/12 久野
1. 総則
2. 管理委員会
3. ニュースグループの管理手順
3.1 総則
NGの管理手順は提案(Proposal)、議案提出(CFI)、公告(CFD)、合意確認
(CFX == CFA、CFV、CFS、CFR)、管理行為の実施の各段階を含んでいる。
(中略)
3.2 状態遷移図
3.3 提案(Proposal)
3.4 議案(Issue)
ニュースグループの一覧表に変更を加える提案を議案(Issue)と呼び、
議案の提出者を提案者と呼ぶ。
議案には、作成、削除の2種類がある。議案提出(CFI)にはそれぞれにつ
いて以下の情報および提案者が明示されている必要がある。提案者の情
報は到達可能なメールアドレスによる。これら以外の情報、理由づけな
どは要求しない。
a) NG作成: 対象NGの名称、憲章、1行英文、moderated/unmoderatedの別
b) NG削除: 対象NGの名称
CFIはNG 管理グループに投稿されるとともに、委員会あてメールで通知
されなければならない。
管理人は通知を受けてから1週間以内に、提出された議案が属するCFD
(後述)を決定する。
管理人は必要と認めた時は自ら提案者となり議案を提出できる。
議案は提案者と内容によって識別される。同一内容の議案が複数人によっ
て個別に提出された場合は別個の議案として扱う。
議案の内容および提案者を変更することはできない。
議案を取り下げることはできないが、管理人は提案者の意思や不在など
の事情に基づき、議案を不活性と宣言しCFXの対象から外すこと、また
それを取り消し旧に復することができる。
[解説] 改名、分割、憲章変更、moderated状態の変更等はすべて既存NG
(必要なら複数)の削除と新規NG(必要なら複数)の作成によって行う。
[解説] 複数の提案者が同一内容の提案を提出できるのは、誰が提案者
になるかで争いがある場合を想定している。
[解説] 議案の内容や提案者を変更したい場合は新たな議案を提出し、
古い議案を不活性化する。ただし実際に不活性化するか否かは管理人が
判断する。
[解説] 1行英文はニュースリーダなどの参照機能に使用するためのもの
であり、60文字程度に収めることが望ましい。
3.5 CFD
類似した議案を一括して審議することをCFD(Call for Discussion) と
呼ぶ。CFDは管理人が管理するが、CFDに含まれる合意確認(CFX、後述)
は管理人または提案者が管理する。
1つのCFDには1つ以上の議案が所属する。
管理人は議案が提出された時に、所属するCFDを決定する。その時適当
なCFDがなければ、新たにCFDを開始する。
管理には新たに開始すべきCFDが進行中のCFDの結果に依存すると判断し
た場合、および先行する同主旨のCFDの開始から3か月を経過していない
場合は、当該CFDの開始を適切な時期まで遅れさせることができる。
CFD期間は標準で2か月とする。管理人は必要と認めた場合CFD期間を延
長することができる。期間内であってもCFXの成立によりCFDは終了する。
管理人はCFDの開始決定、開始、含まれる議案/議案群(後述)の変更、
CFX開始決定、CFD期間変更、CFDの終了に際して、そのことをNG管理グ
ループおよび議案によって影響を受けるグループに公告する。ただし影
響を受けるグループが多い場合にはその一部への公告を持って替えるこ
とができる。
CFDの公告にはCFDを一意に識別する名称、含まれる議案、議案群の情報
が含まれなければならない。
管理人は適当と認めた場合、CFDを分割/併合したり、議案を他のCFDに
移すことができる。その際、どの議案もそれが属するCFDの満了日が変
更以前より早くなってはならない。
[解説] 旧NGMPと異なり、fj直下の変更については特別に扱うことはし
ないが、管理人はいつでもfj直下の変更を伴う議案に対して直下の変更
を伴わない代替の議案を追加提案できる。
[解説] 旧NGMPと異なり、公告は管理人が行い、公告先の判断も管理人
が行う。このため公告の範囲に関する規定は設けない。
3.6 議案群(IG)
CFDに属する議案は最終的に成立/不成立のいずれかとなる。
1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
管理人が決定/変更する。
議案群は同時に成立する可能性のある議案の集合を表す。1つの議案群
に互いに矛盾する(両立し得ない)議案が含まれてはならない。
不活性であると見なされる議案はどの議案群にも含まれなくてよい。
1つのCFDでは、議案群のうちたかだか1つだけがCFXにより成立し得る。
議案群が成立したとき、そこに含まれるすべての議案は成立し、それ以
外の議案は不成立となる。
3.7 合意方式(CFX)
成立する議案群の決定はCFA、CFR、CFV、CFS、のいずれかのCFX(合意方
式)によって行う。
CFA(call for approval)では、議案群の1つを選択し、一定期間内に異
義が出なければその議案群が成立する。異義が出た場合はCFDは継続す
る。CFAは一人が管理者となり、広報および異義の受け付けを行う。
CFR(call for rejection)では、一定期間内に異義が出なければすべて
の議案群が不成立となる。異義が出た場合はCFDは継続する。CFRは一人
が管理者となり、広報および異義の受け付けを行う。
CFV(call for vote)では、一人が投票管理者となり、すべての議案群そ
れぞれ、およびすべての議案の不成立について、賛否を問う。結果が出
た時点でCFDは終了する。
CFS(call for signature)では、複数人が投票管理者となり、それぞれ
が個々の議案群、およびすべての議案の不成立について投票を管理する。
結果が出た時点でCFDは終了する。
CFXの期間は2週間以上とする。上限は設けない。
CFXの開始日、期間、管理者/投票管理者はfjでの議論および提案者の意
見を尊重して管理人が決定し公告する。管理人がCFX管理者/投票管理者
を兼ねることを妨げない。
1つのCFDについて複数のCFXを並行して行うことはできない。複数のCFX
の希望があった場合、管理人は原則としてCFR、CFA、CFV、CFSの順で後
のものほど優先順位が高いものとして実施するCFXを決定する。
CFXの開始を決定し公告した後でも、開始までは決定をやり直すことが
できる。開始以降はCFSの投票管理者追加のみが行える。
CFXの期間中は議案群の構成は変更できない。新たに追加された議案は
CFX期間が終るまで不活性と見なされる。
CFXに関連して管理者/投票管理者がNG管理グループおよび関連グループ
に公告を行う場合は、その投稿範囲は管理人がCFDの公告を行った範囲
と一致させることが望ましい。
CFXの期間中、管理者/投票管理者は自分が管理するCFXないし投票募集
について適切な広報を行うものとする。
[解説] 旧NGMPと異なり、CFXの公告は管理人が行う。このため、告知の
投稿範囲に関する規定を廃止している。ただしCFXに関する開始/終了/
広報の投稿はCFX管理者/投票管理者が行う。
3.8 沈黙による決定(CFA/CFR)
CFA/CFRは議論の結果合意が得られたと思われる場合に投票管理の手間
を省いて合意を確認する手段であり、期間内に異論が提出されなかった
場合に成立する。
CFA/CFR管理者は管理人が指名する。当該CFDに属する議案提案者の中か
ら指名することが望ましい。
CFA/CFR管理者は開始までに異議の形式について規定しNG管理グループ
および関連グループに公告しなければならない。異議を出すのが困難な
形式を指定してはならない。
[解説] 異議の形式として慣習的に「Subject: [Objection] (元
Subject)」というものが指定されることが多い。
[解説] CFRはどの議案群も成立させないのが適当であるという合意を確
認する手段、またはどの議案の提案者も不活性となったためCFDを早期
に終了させる手段として用いることが想定されている。
CFA/CFRに対する異議の提出者は、異議をCFA/CFR管理者と委員会に
E-Mail で通知するとともに、NG管理グループで公表しなければならな
い。異議の提出者が投稿を行えない場合は管理者または管理にが異議の
文面をNG 管理グループに公表する。
異議はどのCFA/CFRに対するものか明確でなくてはならない。異議に理
由づけは必要とされない。異議を取り下げることはできない。
期間内に委員会に届かない異議、および指定された形式に沿っていない
異議は無効とする。
CFA/CFRが異議により不成立となった場合、管理にはそのことをNG管理
グループに告示する。
[解説] 委員会と管理者の両方に異議が届くことになる。事故等により
届いたかどうか定かでない場合は委員会が最終的に判定する。
3.9 投票による決定(CFV/CFS)
3.9.1 投票に関する共通事項
投票はCFDに含まれる議案群、およびすべての議案を不成立とする案(以
下、これらを併せて選択肢と呼ぶ)について、YES/NOの二者択一投票を
行うものである。
投票は参加者のE-Mailによる記名投票で各選択肢について一人一票とす
る。条件付き投票は認めない。
[解説] From:に含まれるコメントをもって記名としてよい。
指定された形式に従っていない投票は無効票とし、集計から除外する。
ただし投票期間内であれば改めて指定された形式に従った投票を提出し
直すことはできる。有効な投票の内容を変更することはできない。
投票において理由づけは要求されない。投票内容を理由にして投票者の
今後の投稿にいかなる制限も加えることはできない。
投票管理者が自動集計システムや他サイトが提供する投票箱などの機能
を利用した場合でも、投票管理および結果公表の責任は提案者が負うも
のとする。
自動集計システムや投票箱などに付随した制約は、投票の告知に含めな
ければならない。そのような制約は、投票結果に不公平をもたらさない
ものに限り認められる。
選定方法は次のとおりとする。過半数の賛成を得た選択肢の中から賛成
/反対の比率の最も高い候補を採択する。比率の最も高い候補が複数あ
る場合には、その中から賛成票の多いものを採択する。賛成票の数と比
率がともに等しい候補が複数ある場合には、管理人が選択する。この選
択に関する異議は認めない。
過半数の賛成を得た選択肢がない場合は、すべての議案を不成立とする
選択肢が過半数かつ最多の票を得たものとして扱う。
投票の途中結果の公表を行うか否か、および行う場合の形式については
投票管理者に任される。ただし虚偽の公表、投票結果に偏りをもたらす
ことを意図した公表を行ってはならない。
投票結果は委員会にE-Mailで通知するとともにNG管理グループに公表し
なければならない。
公表には集計結果に加えて全投票者の投票内容が付随しなければならな
い。
[解説] 投票期間終了後、正式な公表に先立って投票内容を公開しチェッ
クをおこなう場合が多い。
3.9.2 投票(CFV)
CFVは一人の投票管理者がCFDに含まれるすべての選択肢についてまとめ
て投票管理するものである。
議案群が1つしかない場合に限り、YES/NOを1つだけ問い、YES/NOの数値
を入れ換えたものをすべての議案を不成立とする選択肢の投票結果とし
て扱ってよい。
投票結果が公表されない場合は、すべての議案を不成立とする選択肢が
過半数かつ最多票を集めたものとして扱う。
3.10 署名(CFS)
CFSはCFDに含まれる選択肢について、複数の投票管理者がそれぞれ投票
を管理するものである。
1人の投票管理者が複数の選択肢の投票管理を行うことができる。
1つの選択肢について複数の投票管理者が投票を募集してもよい。その
場合、最終集計時にそれらの投票をYES/NOそれぞれについて合算する。
同一人による重複した投票は一票と数える。同一人がYESとNOにともに
投票している場合はその投票者の投票をすべて除外する。
CFDに含まれる議案群のうち、投票管理者が現れない議案群については
投票を行わない。投票期間中にそのような議案群について投票管理者が
現れた場合はその時点から投票を行うが、投票期間自体は変更しない。
すべての議案を不成立とする選択肢については必ず投票を行う。この選
択肢の投票管理者が現れない場合は委員会が投票管理者となる。
投票結果が公表されない場合はその議案群の投票がなかったものとして
扱う。すべての議案群の投票結果が公表されない場合はすべての議案を
不成立とする選択肢が過半数かつ最多票を集めたものとして扱う。
3.10 CFD期間の満了 (Expiration) ←旧3.8
3.11 管理行為の実行 (Execution) ←旧3.9
(旧3.10 NG管理行為の再CFD → 削除)
(旧3.11 複数議題の扱い → 削除)
3.12 管理行為への異議と差し戻し
3.13 委員会による緊急の管理行為
---
Yasushi Shinjo
NG とか、out of order とか投機とか、好きなんだけど。
In article <bhaogl$2q...@utogw.gssm.otsuka.tsukuba.ac.jp>
ku...@gssm.otsuka.tsukuba.ac.jp writes:
> あと新城さんの「2週間連続して一位」「同期取らない」は今回はか
> んべんしてほしい…それをきっちり規定するNGMP的文章が作れる自信が
> 私にはないですし、
重み付き CFA というアイディアは簡単なのに、なんで手続き的に書き
にくいんでしょうね。CFS は、重み付き CFA と同じにすれば簡単なは
ずで、全部これに統一できるはずなんです(fj大統一理論)。
> NGMP改定案(新城・久野版)
> v6 2003/08/12 久野
> 3. ニュースグループの管理手順
> 3.4 議案(Issue)
> 議案を取り下げることはできないが、管理人は提案者の意思や不在など
> の事情に基づき、議案を不活性と宣言しCFXの対象から外すこと、また
> それを取り消し旧に復することができる。
不活性は、管理人をする立場で考えると、ちょっと嫌かなあ。たと
えば、よくあるパタンは、CFA かけたら、英文憲章でスペルミスが
見つかって、objection で undo するという話です。スペルミスの
ものまでトラックするのは、大変かなあ。
> 3.5 CFD
> CFD期間は標準で2か月とする。管理人は必要と認めた場合CFD期間を延
> 長することができる。期間内であってもCFXの成立によりCFDは終了する。
１つの議案が不成立になつても、他にも議案が残っているかもしれ
ないので、この時点で CFD 期間を終りにしてはいけません。
> 管理人は適当と認めた場合、CFDを分割/併合したり、議案を他のCFDに
> 移すことができる。その際、どの議案もそれが属するCFDの満了日が変
> 更以前より早くなってはならない。
この辺り、下手に制約を付けると、３ヶ月の再提出期間などとの辛
みで解が存在しないということになるかと思います。
> 3.6 議案群(IG)
議案群の概念を、まだ理解していません。議案と議案群とCFDの関
係が。
> CFDに属する議案は最終的に成立/不成立のいずれかとなる。
^^^^ これは議案群？
> 1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
> 議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
> 管理人が決定/変更する。
議案がCFDに属しているので、あるCFDに属している議案の全体があっ
て、その全体の集合の部分集合が議案群、というのはいいとして、
> 議案群は同時に成立する可能性のある議案の集合を表す。1つの議案群
> に互いに矛盾する(両立し得ない)議案が含まれてはならない。
あ、分かった気がする。議案を atom すると、議案群は list みた
いなものか。うまくやると、再帰的な定義ができそう。
> 1つのCFDでは、議案群のうちたかだか1つだけがCFXにより成立し得る。
> 議案群が成立したとき、そこに含まれるすべての議案は成立し、それ以
> 外の議案は不成立となる。
こういう議案群の使い方をしてもいいとは思いますが、そうなると
対案が出て争っている時は、どういう扱いになるのでしょうか。
議案群Ａと議案群Ｂと分かれたとして、
> 3.7 合意方式(CFX)
> 成立する議案群の決定はCFA、CFR、CFV、CFS、のいずれかのCFX(合意方
> 式)によって行う。
..
> 1つのCFDについて複数のCFXを並行して行うことはできない。
議案群Ａと議案群Ｂは、なるべく同時に投票に掛ける必要があると
思います。逐次化しない方がいいと思います。
このような場合をどう扱うかが、複数のCFDの扱いをどうするかが残さ
れた問題ですかね。
> 3.7 合意方式(CFX)
> CFXの開始日、期間、管理者/投票管理者はfjでの議論および提案者の意
> 見を尊重して管理人が決定し公告する。管理人がCFX管理者/投票管理者
> を兼ねることを妨げない。
投票開始時期を管理人が調整するのは、いいですね。
議論期間を前期と後期に分けることにしてみました。
----------------------------------------------------------------------
NGMP改定案(新城・久野版)
v6 2003/08/12 久野
v7 2003/08/16 新城
1. 総則
2. 管理委員会
3. ニュースグループの管理手順
3.1 総則
ニュースグループの管理手順は、議案提出(submission)、議論空間設置、
合意確認(CFX == CFA、CFV、CFS、CFR)、管理行為の実施の各段階を含
んでいる。
(中略)
3.2 状態遷移図
3.2.1 議案の状態遷移
提出 承認開始 可決
[初期] ----> [審議中] ---------> [承認中] ----> [[成立]]
| |
| | 否決
| v
+------------> [[不成立]]
応答なし、
取下、満了
イベント
提出(submit) : 形式に乗っ取った記事の投稿
可決(approve): CFA/CFV/CFSで承認
否決(reject) : CFR/CFV/CFSで不承認
取下(drop) : 提案者が取下げ
満了(expire) : 審議期間満了
3.2.2 議論空間の状態遷移
設置 収束宣言 時間切れ
[初期] ----> [前期] --------> [後期] ---------> [[議論終了]]
早期満了
3.4 議案(Issue)
ニュースグループの一覧表に変更を加える提案を議案(Issue)と呼び、
議案の提出者を提案者と呼ぶ。
議案には、次の５種類がある。
(a) 作成: 新しいニュースグループの作成
(b) 削除: 既存のニュースグループの削除
(c) 変更: 既存のニュースグループの、憲章案、状態
(moderated/unmoderated)の変更
(d) 改名。(a)と(b)をまとめたもの。((e) の特別のもの。)
(e) 議案群。複数の議案をまとめたもの。含んでいる個々の議案を
要素議案と呼ぶ。
(a) から (c) を原子議案と呼ぶ。
管理人は必要と認めた時は自ら提案者となり議案を提出できる。
議案は提案者と内容によって識別される。同一内容の議案が複数人によっ
て個別に提出された場合は別個の議案として扱う。
審議中の議案の内容および提案者を変更することはできない。
3.4.1 議案提出(submit)の様式
議論期間の前期においては、提案者は、議案提出(submit)において、次
のような情報を含む記事を当該の管理グループに投稿する。
(a) 作成: 対象ニュースグループの名称、憲章、1行英文、
moderated/unmoderatedの別
(b) 削除: 対象ニュースグループの名称
(c) 変更: 作成と同じ。
(b) 改名: (a) と (b) を合わせたもの。
(e) 議案群: 要素議案を識別できる情報。
提案者の情報は到達可能なメールアドレスによる。
提案者は、議案提出記事を投稿すると同時に、委員会あて電子メールで
通知する。
管理人は通知を受けてから1週間以内に、提出された議案が属する議論
空間(後述)を決定する。
管理人は、複雑な議案群を受付けなくてもよい。
3.4.2 議案の取下げ(drop)
提案者は、審議中の議案を取下げることができる。
提案者は、承認中の議案を取下げることはできない。
3.4.3 議案の回収(collection)
管理者は、提案者に連絡をとり、１週間応答が得られない場合は、その
提案者に提出された審議中の議案を回収し不成立にすることができる。
既に承認中になった議案については、回収することはできない。
[解説] 複数の提案者が同一内容の提案を提出できるのは、誰が提案者
になるかで争いがある場合を想定している。
[解説] 議案の内容や提案者を変更したい場合は新たな議案を提出し、
古い議案を取下げる。
[解説] 1行英文はニュースリーダなどの参照機能に使用するためのもの
であり、60文字程度に収めることが望ましい。
3.5 議論空間(discussion space)と議論期間(discussion period)
類似した議案を一括して審議する場を議論空間(discussion space)と呼
ぶ。議論空間を設置することを、CFD(Call for Discussion) と呼ぶ。
議論空間には、分かりやすい名前を付ける。
1つの議論空間には0個以上の議案が所属する。
管理人は議案が提出された時に、所属する議論空間を決定する。その時
適当な議論空間がなければ、新たに議論空間を設置する。
議論空間が設置されている期間を、議論期間(discussion period)、ま
たは、CFD期間と呼ぶ。
CFD期間は標準で2か月とする。管理人は必要と認めた場合CFD期間を延
長することができる。
管理人は、属する全ての議案が成立、または、不成立するなどで議案が
含まれていない議論空間を削除することができる。
管理には、次のような場合、議論空間の設置を遅らせることができる。
・既存の議論空間の結果を確定させた後に議論を開始したい場合
・先行する同主旨の議論空間の設置から3か月を経過していない場合
管理人は、議論空間の設置、含まれる議案の変更、CFX開始決定、CFD期
間変更、議論空間の削除に際して、そのことを当該の管理グループ、お
よび、関連するグループに公告する。
管理人は、議論空間を分割したり、統合したり、および、所属する議案
を別の議論空間に移すことができる。
議論期間は、前期と後期に分かれる。管理人は、１週間前に前期の終了
を広告する。管理人は、前期では、基本的に提出された議案を受付ける。
後期では、管理人は、新たな議案の提出を受付けなくてもよい。後期で
は、管理人は、CFXを開始することができる。
[解説] 旧NGMPと異なり、fj直下の変更については特別に扱うことはし
ないが、管理人はいつでもfj直下の変更を伴う議案に対して直下の変更
を伴わない代替の議案を追加提案できる。
[解説] 旧NGMPと異なり、公告は管理人が行い、公告先の判断も管理人
が行う。このため公告の範囲に関する規定は設けない。
3.7 承認方式(CFX)
議案(作成、削除、変更、改名、議案群)は、CFA、CFR、CFV、CFS、のい
ずれかのCFX(承認方式)によって、成立する。
CFA(call for approval)では、一定期間内に異義が出なければその議案
が成立する。CFAは一人が管理者となり、広報および異義の受け付けを
行う。
CFR(call for rejection)では、一定期間内に異義が出なければすべて
の議案が不成立となる。CFRは一人が管理者となり、広報および異義の
受け付けを行う。
CFV(call for vote)では、一人が投票管理者となり、すべての議案それ
ぞれ、およびすべての議案の不成立について、賛否を問う。
CFS(call for signature)では、複数人が投票管理者となり、それぞれ
が個々の議案について、賛否を問う。
CFXの期間は2週間以上とする。CFXは、議論時間の後期に開始すること
ができる。CFXは、CFD期間内に終了する。
管理人がCFX管理者/投票管理者を兼ねることを妨げない。
管理人は、提案者の希望を尊重し、ある議案についてCFXを決定する。
管理人は、対立する議案について同時にCFXを行い同時に成立、または
不成立を確定させる。
[解説] 旧NGMPと異なり、CFXの公告は管理人が行う。このため、告知の
投稿範囲に関する規定を廃止している。ただしCFXに関する開始/終了/
広報の投稿はCFX管理者/投票管理者が行う。
3.8 沈黙による決定(CFA/CFR)
CFA/CFRは議論の結果合意が得られたと思われる場合に投票管理の手間
を省いて合意を確認する手段であり、期間内に異論が提出されなかった
場合に成立する。
CFA/CFR管理者は管理人が指名する。当該CFDに属する議案提案者の中か
ら指名することが望ましい。
CFA/CFR管理者は開始までに異議の形式について規定しNG管理グループ
および関連グループに公告しなければならない。異議を出すのが困難な
形式を指定してはならない。
[解説] 異議の形式として慣習的に「Subject: [Objection] (元
Subject)」というものが指定されることが多い。
[解説] CFRは、議案を取下げできない時に使う。
異議はどのCFA/CFRに対するものか明確でなくてはならない。異議に理
由づけは必要とされない。異議を取り下げることはできない。
期間内に委員会に届かない異議、および指定された形式に沿っていない
異議は無効とする。
CFA/CFRが異議により不成立となった場合、管理にはそのことをNG管理
グループに告示する。
[解説] 委員会と管理者の両方に異議が届くことになる。事故等により
届いたかどうか定かでない場合は委員会が最終的に判定する。
3.9 投票による決定(CFV/CFS)
3.9.1 投票に関する共通事項
投票は参加者のE-Mailによる記名投票で各選択肢について一人一票とす
る。条件付き投票は認めない。
[解説] From:に含まれるコメントをもって記名としてよい。
投票において理由づけは要求されない。投票内容を理由にして投票者の
今後の投稿にいかなる制限も加えることはできない。
投票管理者が自動集計システムや他サイトが提供する投票箱などの機能
を利用した場合でも、投票管理および結果公表の責任は提案者が負うも
のとする。
過半数の賛成を得た選択肢がない場合は、すべての議案を不成立とする
選択肢が過半数かつ最多の票を得たものとして扱う。
投票結果は委員会にE-Mailで通知するとともにNG管理グループに公表し
なければならない。
公表には集計結果に加えて全投票者の投票内容が付随しなければならな
い。
[解説] 投票期間終了後、正式な公表に先立って投票内容を公開しチェッ
クをおこなう場合が多い。
3.9.2 投票(CFV)
CFVは一人の投票管理者が議論空間に含まれるすべての選択肢について
まとめて投票管理するものである。
3.10 署名(CFS)
CFSはCFDに含まれる選択肢について、複数の投票管理者がそれぞれ投票
を管理するものである。
1人の投票管理者が複数の選択肢の投票管理を行うことができる。
すべての議案を不成立とする選択肢については必ず投票を行う。この選
択肢の投票管理者が現れない場合は委員会が投票管理者となる。
3.10 CFD期間の満了 (Expiration) ←旧3.8
3.11 管理行為の実行 (Execution) ←旧3.9
(旧3.10 NG管理行為の再CFD → 削除)
(旧3.11 複数議題の扱い → 削除)
3.12 管理行為への異議と差し戻し
3.13 委員会による緊急の管理行為
---
削除したもの
> 3.3 提案(Proposal)
NGMPの範囲外の話は書かない。
> これら以外の情報、理由づけなどは要求しない。
>
> CFDは管理人が管理するが、CFDに含まれる合意確認(CFX、後述)
> は管理人または提案者が管理する。
>
> ただし影響を受けるグループが多い場合にはその一部への公告を持って
> 替えることができる。
>
> CFDの公告にはCFDを一意に識別する名称、含まれる議案、議案群の情報
> が含まれなければならない。
>
> その際、どの議案もそれが属するCFDの満了日が変更以前より早くなっ
> てはならない。
下手な制約は、解がなくなるかもしれない。
> 3.6 議案群(IG)
>
> CFDに属する議案は最終的に成立/不成立のいずれかとなる。
>
> 1つのCFDには0個以上の議案群(Issue Group、IG)が所属する。議案群は
> 議案の(排他ではない)部分集合であり、提案者の意見を参考にしながら
> 管理人が決定/変更する。
>
> 議案群は同時に成立する可能性のある議案の集合を表す。1つの議案群
> に互いに矛盾する(両立し得ない)議案が含まれてはならない。
>
> 不活性であると見なされる議案はどの議案群にも含まれなくてよい。
>
> 1つのCFDでは、議案群のうちたかだか1つだけがCFXにより成立し得る。
> 議案群が成立したとき、そこに含まれるすべての議案は成立し、それ以
> 外の議案は不成立となる。
議案群を再帰的に定義したので不要。
> (cfa) 異義が出た場合はCFDは継続する。
> (cfr) 異義が出た場合はCFDは継続する。
> (cfv) 結果が出た時点でCFDは終了する。
> およびすべての議案の不成立について投票を管理する。結果が出た時点
> でCFDは終了する。
継続してもよい。
> 1つのCFDについて複数のCFXを並行して行うことはできない。
関連しているものは並行して行う。
> CFXの開始日、期間、管理者/投票管理者はfjでの議論および提案者の意
> 見を尊重して管理人が決定し公告する。
前期、後期に反映。
> CFXの開始を決定し公告した後でも、開始までは決定をやり直すことが
> できる。開始以降はCFSの投票管理者追加のみが行える。
>
> CFXの期間中は議案群の構成は変更できない。新たに追加された議案は
> CFX期間が終るまで不活性と見なされる。
>
> CFXに関連して管理者/投票管理者がNG管理グループおよび関連グループ
> に公告を行う場合は、その投稿範囲は管理人がCFDの公告を行った範囲
> と一致させることが望ましい。
>
> CFXの期間中、管理者/投票管理者は自分が管理するCFXないし投票募集
> について適切な広報を行うものとする。
> 議案群が1つしかない場合に限り、YES/NOを1つだけ問い、YES/NOの数値
> を入れ換えたものをすべての議案を不成立とする選択肢の投票結果とし
> て扱ってよい。
>
> 投票結果が公表されない場合は、すべての議案を不成立とする選択肢が
> 過半数かつ最多票を集めたものとして扱う。
>
> 1つの選択肢について複数の投票管理者が投票を募集してもよい。その
> 場合、最終集計時にそれらの投票をYES/NOそれぞれについて合算する。
> 同一人による重複した投票は一票と数える。同一人がYESとNOにともに
> 投票している場合はその投票者の投票をすべて除外する。
>
> CFDに含まれる議案群のうち、投票管理者が現れない議案群については
> 投票を行わない。投票期間中にそのような議案群について投票管理者が
> 現れた場合はその時点から投票を行うが、投票期間自体は変更しない。
>
> 投票結果が公表されない場合はその議案群の投票がなかったものとして
> 扱う。すべての議案群の投票結果が公表されない場合はすべての議案を
> 不成立とする選択肢が過半数かつ最多票を集めたものとして扱う。
同時投票の扱いがまだ固まっていないので後回し。