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

In article <3F4B29EB.74622D78@ht.sakura.ne.jp>
        IIJIMA Hiromitsu <delmonta@ht.sakura.ne.jp> writes:
> 新城案では、「結果的に組合せ爆発するような依存関係の記述」になった場合に、
> その爆発を押さえ込むことができません。

私は楽観的です。人間の思考がもともとその程度なので、そもそも
複雑な議案の組み合わせは最初から提出されないと思っています。
今の例で複雑になっているのは、飯島さんが、自説の補強材料とし
て、複雑な例、しかも、新城案ではもともと禁止されているような
例を出しているからです。元々の新城案の範囲内では、複雑にはな
りません。

> とすると、「具体例を頭の中に描」くためには、考え得る結論の数が、組合せ爆
> 発しない程度の少数におさまっている必要があります。7 個程度までにおさめる
> のが理想ですが、12 個くらいまでなら何とかなるでしょう。それ以上だとちょ
> っと投票参加者の手に負えません。

一度に認識できるのは、６か７ですが、チャンクを作ればもっとい
けるという話は、聞いたことがあります。７色の虹とか、ＯＳＩの
７層モデルとか。

> プログラミングでも、たとえば不正な入力を弾くコードが正しく動作しているか
> どうかを検証する場合にプログラマが何をするかというと、コードを読んで可能
> 性の樹形図を書くことはまずありません。実際に不正な入力の具体例をひとつか
> ふたつ考えて入力として与え、それで実際に意図した通りの手順で意図したとお
> りの場所にたどりつくかを確認して、それでよしとします。
> ＃だから、プログラマの想定外のの入力でハングアップしてバグ露呈、というこ
> ＃とがよくあるわけです。

面白いですね。

私の提案は、全体像を見渡すことが難しい時には、個々の議案（作
成、削除、状態変更）に対して、局所的に賛成、反対を求めるだけ
にするといいのではないかということです。認知心理学的にも、よ
い方法と言えませんか。小さい関数をバグがないよう書くというこ
とを繰り返すことで、大局的に自然にバグがないプログラムが完成
させようという試みとも言えます。

In article <3F4D8556.CE065D06@ht.sakura.ne.jp>
        IIJIMA Hiromitsu <delmonta@ht.sakura.ne.jp> writes:
> > ですから、「否決されたら」のような扱えない条件
> 
> を扱いたいという提案者が出てきたらどうするの、ということです。
> fj.os.solaris の成否を待って、別 CFD にするしかないですよね。

いいえ。同じ CFD で扱ってもいいです。同じ CFD なんだれども、
「否決されたら」ということなので、否決されるのを待ってから、
投票すればいいんです。その案が否決されるまで、
CFA/CVV/CVS/CFR などの承認手続きを遅らせればいいんです。

CFD の中で、１つの CFA/CVV/CVS/CFR が終ったとしても、決着し
ていないで別の案については、CFD 期間は続行して「同じ CFD」で
決着をつけられます。

CFD を、「fj.os.solaris 関連」くらいで１つのチャンクにしてし
まえば、人間、けっこう扱えます。

以前、comp 分野の管理人をしていた時には、チャンクとしては、
成立したものだけで、次のものを扱いました。

fj.lang.ruby
fj.comp.lang
fj.comp.input-method.*
fj.comp.statistics
fj.comp.applications.*
fj.comp.dev.pc-card
fj.os.ms-windows
fj.os.ms-windows.misc
fj.os.beos

成立しなかったものも、もっとたくさんあります。fj.unix 系の再
編など。こちらの方が、これを全部合わせたものより大変だったん
だけど。CFD の数は、* のものは、CFD としてはたくさんあります。
人間、このくらいは、扱えます。

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