いいじま％自己流で断眠療法実行中、です。

流れが読めていないので間違っていたらごめんなさい、というのと、あと、
かなり長文なのもご容赦ください。

ポイントごとに番号振ります。

１．今までの流れ

まず今までの流れを整理すると、

○現行 NGMP では、単一の提案者が CFD を取り仕切ることになるので、その
　CFD を廃案に追い込んでからでなければ対案を出せない

　→これは、今後は管理人が仕切るということで合意をみたと考えます。
　　つまり、fj.net.watch の一件だと、当初案の提案者である久野さんが
　　新城さんの案の一部に難色を示しても、担当管理人・河野さんの裁量で
　　CFV の選択肢に含めさせることができたことになります。

○依存関係にある2つの議案（たとえば、fj.editor.*→fj.comp.editor.* の
　一括改名議案と、fj.(comp.)editor.hidemaru の新設議案）について、前者の
　結論が出なければ後者の前提条件が確定しない場合に、早い時期に後者だけ
　可決させたい場合の取り扱いをどうするか

　→これを久野さんは「CFD-議案群-議案」という 3 層構造の導入と「一括採決」
　　という方法で、新城さんは「依存」の概念の導入と「遡及決定」という方法
　　で、それぞれ解決しようとしている

　○相矛盾する議案が出たときの取り扱い

　→久野さんは「議案群を構成する際に同一の議案群に相矛盾する議案は入れな
　　いようにする」としており、一方で、新城さんは「相矛盾する案を両方とも
　　議上に載せたままにしておいて、一方が成立すれば他方は自動的に落ちる」
　　としている

これで間違いないでしょうか。

                                ☆

２．私の意見

で、私の意見ですが、先述の通り、

久野さん:
> 計算機屋でない人に読めないNGMPになりそうだから
> そういうものを入れるのは我慢して欲しいです。再帰とかも。まずは
> 「平に」記述して、

という意見に全面的に同意します。Makefile のような文法を持ち出してこなけ
れば記述できない NGMP には反対です。

で、久野案には納得できましたから、それに賛成です。あとは細かい文言に注文
をつけたいところはありますけど、それは v9、v10 が出てからにします。

                                ☆

３．make に喩えることには反対

> 依存は、簡単です。Makefile で、書くようなものです。

と、おっしゃいますが、make に喩えるのはおかしいのでは。make コマンドの
文法って、基本的に並列処理ではなく直列処理で、並列化できるのはそれぞれに
依存関係がない場合、と認識しています。たとえば、make build と make install
を並列化しようとしても、make install のほうは通常は make build の結果待ち
だし、仮に並列化できたとしても、make build が失敗したときのための make
uninstall はよほど丁寧に書かないと面倒なことになります。

依存関係があっても並列化できる make もあるのかもしれませんが、一般の UNIX
ユーザーにはなじみがありませんし、そもそも Makefile の読み書きをしない人
のほうが今や多くなった（UNIX 界でも、rpm しかインストールしないとか、
Makefile は読み書きするけど Ports collection のオブラートにくるまったもの
しか相手にしないとか、そういう人のほうが多い） fj の参加者に対して、Makefile
の文法を用いて解説しなければいけないのは間違っていると思います。

                                ☆

４．fj.net.watch vs fj.news.from.misc での新城案の問題点

そして、例として挙げられた、

> issue1: fj.net.watch or fj.news.from.misc
> issue2: fj.news.from.2ch
> issue3: fj.news.from.blog
> issue4: fj.news.from.slashdot
> 
> 私がやりたいのは、次の並列 make です。
>     make issue1 1issue2 issue3 issue4
> 
> issue2-4 を先に決まったとしても、issue1 でfj.news.from.misc
> かこけたら、undo してこけさせます。

という例は、そのままでは新城さんの方式では問題ありと考えます。これだと、
先に issues2-4 が fj.news.from.* という仮グループ名で一つでも可決されれば、
issue1 についても fj.news.from.misc に票が流れるでしょう。

あるいは、fj.net.watch.2ch や fj.net.watch.slashdot という名前がいい、
という意見が出て、CFD にその議案が追加されることもあるでしょう。とすると、

issue2: fj.news.from.2ch or fj.net.watch.2ch
issue3: fj.news.from.blog or fj.net.watch.blog
issue4: fj.news.from.slashdot or fj.net.watch.slashdot

となり、今度は、たとえば issue2 については

a)issue1 の結果に応じてどちらかの名前で必ず作る、issue1 が否決されたら
　別途名前を決める
b)issue1 の結果がどちらかを作ることになったらそれに応じた名前で作る、
　どちらも作らないことになったら作らない
c)issue1 の結果に関係なく、どちらも作らない

の 3 択になります。つまり、表面上は「どちらの名前にするかの 2 択＋廃案の
計 3 択」に見えて、表記上もそうなっているにも関わらず、実際には「名前は
実は a) 以外では関係なく、issue1 の結果をどう issue2 に反映させるのかに
よる 2 択＋無条件廃案の計 3 択」になるわけです。

こういう「熟慮に熟慮を重ねても見落としが出かねない論理構造」は好ましく
ないと考えます。そして往々にして、見落とし対策で全検索をすると組合せ爆発
します。

また、もし「どちらの名前にするかの 2 択＋廃案の計 3 択」で 3 つまとめて
投票をして矛盾する結果が出たら、その投票はすべて無駄で、結局は issue1
の投票に持ち込まれることになりますので、投票管理者にとって非常なコストに
なります。

そして、どうせ全検索で組合せ爆発するのであれば、久野案の「議案群」という
概念でそれを明示的に表現してしまって、場合によっては「じゃあ爆発するから
複数の CFD に分割しよう」としたほうがいいと思うのですよ。

５．可能性をすべて書き出してみると新城案の問題点がわかる

今回の場合、可能な組合せをぜんぶ書き出すと、

[略号 w=fj.net.watch、f=fj.news.from.*、m=misc、2=2ch、b=blog、s=slashdot]

[前提:両立しない組合せ]
        w* と f* の任意の組合せ
        w  と wm の両方を作る案

[全廃案という議案群…1件]
        φ

[1グループ作成という議案群…7件]
        w
        w2      ←こういう 6 案も選択肢に入ることに注意。
        wb
        ws
        f2
        fb
        fs

        ※「wmだけ」「fmだけ」という議案群は候補から外れると考えます。
        　他に何もないのに misc＝「その他」があるのはおかしい。

[2グループ作成という議案群…12件]
        w+w2
        w+wb
        w+ws
        wm+w2
        wm+wb
        wm+ws
        fm+f2
        fm+fb
        fm+fs
        f2+fb   ←この最後の3つ注意
        f2+fs
        fb+fs

[3グループ作成という議案群…10件]
        w+w2+wb
        w+w2+ws
        w+wb+ws
        wm+w2+wb
        wm+w2+ws
        wm+wb+ws
        fm+f2+fb
        fm+f2+fs
        fm+fb+fs
        f2+fb+fs　←これ注意

[4グループ作成という議案群…3件]
        w+w2+wb+ws
        wm+w2+wb+ws
        fm+f2+fb+fs

の33通りとなりますが、新城さんの方式では、議案の構成の仕方によって、最後
の最後になってみないと、その33通りのどれにでも転ぶ可能性があります。結果
として、議論参加者の望まない構成で CFD が成立してしまう可能性があります。

また、不用意に議事を進めると、人間の目を通さずに、自動的に特定の選択肢を
落としてしまう可能性があります。たとえば、新城さんの記述では、「fm なし
で f2、fb、fs の 1 個以上を作る。fm が相当な記事は fj.misc 等を用いる」
という選択肢は最初から落ちています。

つまり、「到達しうる選択肢の一覧」がどこにも明記されないまま議論が進むこ
とになります。

また、せっかく投票してもその結果が上位の投票で覆されて無駄になる事態があ
りうるのは、新城さんも当然に認めているところですが、投票は 1 回だけでも
投票管理者にとって大きな負担になります。

私自身、いま投票の最中ですが、はじめての投票なので、私の予想外の投票がい
ろいろと来て「この票を有効票と見なして受理して、開票後に無効とされたら申
し訳ない」「けれども、こちらで不備と見なして出し直しを指示し、あとでそれ
は不備ではないとされて出し直しは二重投票、したがって両方とも無効票、とさ
れたらそれも困る」ということで、非常に神経をすり減らしています。

６．久野案でのこの案件の取り扱い

久野さんの案では、この33通りの選択肢（これを久野さんは議案群と呼んでいる
わけですが、選択肢と言い換えてもいいかもしれない）を可能ならすべて書き出
して、あるいは、全部で何通りあるかわからない中から各提案者が思いつくもの
だけをリストアップし、その中から、賛成者のいない案、非合理的な案（たとえ
ば w+wm のような相矛盾する案）を除外して選択肢の数を絞り込んだ上で、複数
選択投票にかけます。

今回の案件では、33案の中からφ、w、fm+f2+fb+fs の 3 案に絞り込んで投票に
かける、と久野さんは明言しています。それに対して、私なら投票予告の時点で
w+w2 を選択肢に入れるように管理人さん（＝久野さん）に要望するでしょう。

７．では、前述の fj.editor.hidemaru の例ではどうなるか

この例では、久野さんの案では、
        ○何も変更しない
        ○fj.editor.hidemaru を作成する。
        　fj.editor.* → fj.comp.editor.* の移動は行わない。
        ○fj.editor.* → fj.comp.editor.* の移動を行う。
        　fj.comp.editor.hidemaru は作らない。
        ○fj.editor.* → fj.comp.editor.* の移動を行い、
        　fj.comp.editor.hidemaru を作る。
の４択での一括投票になります。

新城さんの案は、fj.(comp.)editor.hidemaru を作るかどうかを先に決めて
fj.editor.* → fj.comp.editor.* の可否はあとで決めることを可能にしよう、
その手段として、まず最初は「fj.editor.hidemaru 新設」という議案を通して
おいて、fj.editor.* → fj.comp.editor.* が可決されたらその時点で遡って
fj.comp.editor.hidemaru 新設議案が通ったものと見なす、ということになり
ますよね。

…でも、議論が長引いたとすると、fj.editor.hidemaru 新設のコントロールメ
ッセージを流したあとに、fj.editor.hidemaru 廃止・fj.comp.editor.hidemaru
新設のコントロールメッセージを流す可能性が高くなります。昨今の、各プロバ
イダのニュースサーバーの管理状況が決してよくない状況の中で、それでよろし
いのでしょうか？＞＞新城さん

とすると、fj.(comp.)editor.hidemaru に関するコントロールメッセージは新設
一発で済ませたいところですので、その意味でも、「一括採決」を旨とする久野
さんの案が望ましいと考えます。

もっとも、このケースに限っていえば、この両者を別々の CFD として扱った上
で、「管理行為の実行」の節に「成立した CFD であっても、他の CFD の結果に
よってコントロールメッセージの出し直しが必要になる可能性があるときは、当
該 CFD が決着するまで管理行為の実施を延期できる」という規定を設けること
で解決できそうですが、それはそれでややこしくなりそう。

========================================================================
飯嶋 浩光 / でるもんた・いいじま   http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta           mailto:delmonta@ht.sakura.ne.jp

───【宣伝/ADVERTISEMENT】──────────────────────
fj.os.ms-windows.server2003 または fj.os.ms-windows.server の新設の可否
を問う投票を実施中です。
fj.news.group.comp をご参照のうえ、ふるってご投票ください。
投票期限は 8/25(月)です。
────────────────────────────────────