Grouping discussion issues and dependency (ngMP v8)
新城@筑波大学情報です。こんにちは。
In article <bhua4v$1bg7@utogw.gssm.otsuka.tsukuba.ac.jp>
kuno@gssm.otsuka.tsukuba.ac.jp writes:
> 新城さんの提案は1番yesを集めた「議案」が成立することによってそれ
> と「依存」関係で結ばれたものも一緒に成立するわけじゃないですか。
いいえ。依存関係は、片方向です。ですから、AがBに依存してい
る時、Bが不成立ならAも不成立ですが、Aが不成立でもBは不成
立になりません。たとえば、次の4つの議案を考えます。
(B) fj.news.from.misc
(A1) fj.news.from.2ch
(A2) fj.news.from.blog
(A3) fj.news.from.slashdot
A1, A2, A3 が B に依存していると考えると、B が不成立になった
段階で、道連れで A1, A2, A3 も不成立になります。逆に、A1 が
不成立になっても、B は成立する可能性はあります。A1, A2, A3
の間では、独立しているので、A1 が不成立しても、A2 が成立する
こともあります。A1, A2, A3 の決着の時期は、同時でもいいし、
バラバラでもいいです。
ここまでは、自然で分かりやすいですよね。
少し頭を使うのは、タイミングがずれる時です。実は、A 系列と B
の決着の時期も、どちらが先でもかまいません。普通は B を先に
決着(CFA/CFV/CFS)つけるのでしょうが、A1 が先でも、かまいませ
ん。A1 が先に決着して成立した場合、これはまだ予約した状態に
留めておけばいいんです。この場合、最終的な成立は、B の決着を
待ってから確定させます。もちろん、B が不成立になると、A1 の
予約は取消して不成立にします。
後で取消すということは、自然現象にはありますが、人間の営みに
はよく出てきます。たとえば、航空券の予約とかホテルの予約とか
結婚の予約とかそういう日常的に行われている取引と似たようなも
のです。予約していても、キャンセルされることもあるわけです。
キャンセルのことを、コンピュータ用語では、undo といいます。
ワードプロセッサには、undo 機能が付いているので、ワードプロ
セッサを使える人には、お馴染の考え方でしょう。undo やキャン
セルは、そんなに難しい話ではありません。キャンセルというと、
投稿した記事のキャンセルというというのもありました。fj の参
加者は、予約やキャンセルの概念を理解できていると仮定しても問
題ないでしょう。
というわけで、予約もキャンセルも、分かりやすい話です。これも
いいですね。
話を、難しい話に戻します。CFDと議案群です。
久野流だと、上の議案 B, A1, A2, A3 は、全部別の CFD(久野) の
別の議案群になるのですか? 同じ CFD の別の議案群になるので
すか? 別記事では、こう書いていますけれど。
In article <bhqoj9$2v0e@utogw.gssm.otsuka.tsukuba.ac.jp>
kuno@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> はい、同時に投票したいですね。そのために我々が今努力してるんで
> しょ。私がv6でこの件の管理をするのであれば、その議案を
> { fj.net.watch }
> { fj.news.from.misc, fj.news.from.2ch, fj.news.from.blog,
> fj.news.from.slashdot }
> という2つの議案群にまとめ、複数選択CFVかCFSとします。どちらかの
> 議案群が成立すればそのグループ(群)がまとめてできます。どっちも反
> 対という票が多数ならどちらもできません。
この括り方だと、fj.news.from.2ch と fj.news.from.blog が一蓮
托生になってしまって、直感と合いませんし、今までの NGMP の
CFD の数え方(記事は1つでも複数独立として数える)とも合いま
せん。ngMP v8 で導入された、新たな問題です。
私は「必ず同時」に投票したいということはなくて、同時に投票で
きればそれでもいいし、fj.news.from.{2ch,blog,slashdot}を先に
投票できるなら先でもいいし、後でもいいしです。ただ、3ヶ月待
たされるのは勘弁して欲しいと、そういうことを言っているわけです。
議案を提出する段階で、これとこれは同時というのが決められるか
というと、私の感じでは辛いんじゃないかなあと思います。議論の
過程で、これは同時がいい、これは後回しにしようと出てくるもの
だからです。
上の B, A1, A2, A3 が全部別の「CFD」とすると、「CFD」と「CFD」
の関係は、どうなるんですか。「CFD期間」という概念を入れるに
は、これを明確にする必要があります。同じと認定されると、3ヶ
月先送りになるので。この点が、ngMP v8 のもう1つの問題点です。
> 1度に決着したいときは1つのCFDにし、別々に(ないし順番に)決着
> したいときは別のCFDにする。議案のCFDの間の移動は管理人が判断
> する。
> という方針を提案しているつもりですが、それではまずいですかね?
決定的にまずくはないけれど、よりよい案があります。それは、
ngMP v4 や v5 にあるように、議案提出時に他の議案との関係を決
めたら、基本的に変更しないことです。動的に変えるのを当てにす
るよりは、静的に決められるものは決めていた方が簡単です。
In article <bhua4v$1bg7@utogw.gssm.otsuka.tsukuba.ac.jp>
kuno@gssm.otsuka.tsukuba.ac.jp writes:
> > と言われても、ちょっとね。「同時」かどうかでCFDを定義し直す
> > んですかね。でも、それだとCFDをないがしろにしている気もする
> > し。まあ、私は CFD の定義にはこだわらないのでいいけど。こだ
> > わるのは、「関連している具体的な案が同時並行的」に審議できる
> > かどうかです。
> ようやく分かりました、では「類似」を落して「同時に決着すべき
> 議案」とすればどうでしょうか。
..
> 同時に成立することが相当であると管理人が判断した議案の集まり
> を議案群と呼ぶ
> とかそういう方がいいですか?
相変わらず、CFDと議案群が同じに見えます。でも、上の例であげ
た議案が全部別 CFD なら、それでいいです。複雑なCFDというくく
りと「議案群」という括りがあるのとないのでは、ない方がいいと
思いますが、まああってもいいです。
> その原理自体はいいんですよ。それでもともとの話、現在のNGMPは1つ
> の「議案」が1つの「CFD」だという想定があって、それじゃ不十分
> (fj.net.watchとfj.news-from.*群の選択)ができないから今回の検討を
> してるんでしょ。
なるほど。久野さんは、今までの NGMP を「決着」に重みをおいて
考えてらっしゃったわけですね。私は、「CFD」は、文字通り、
「議論をしましょう」ととう意味にとっていました。決着ではなく
て「議論」のことだと考えていました。ですから、上の例では、
A1, A2, A3, B は関連しているので1つの委員会で話をすると。
「委員会」という概念はいいかもしれませんね。わかりやすい。
> 新城さんがどっちでもいいなら、現在のNGMPからの移行を考えると
> CFDに期間がついているという枠組みは維持したいですね。
私は、「Xの期間」の「期間」といった時、「期間」が大事であっ
て、その「期間」さえ定義できればよくて、「X」の方は、さほど
重要ではないと言っているだけです。期間が大事というのは、同じ
です。
上で書いたように、ngMP v8 では、期間をうまく区切れるのか不明
です。v4, v5 では、この点大丈夫です。
> CFDをどうしてもやめたいということでしたら、その意見に賛成の人が
> 他にいるかしばらく見守りたいです。ただ、その見守っている間にCFD
> のある案を改訂して検討するのはいけませんかね。
はい。賛成です。そういうやり方を、楽観的/投機的といいます。
あとで、CFD の話がご破算になるかもしれないけど、そうならない
と仮定して話を先にすすめます。こういう楽観的/投機的な方法を
使うと、議論の収束が早くなります。成功する確率が高い時には。
悲観的な方法だと、まずCFDを決着して、何を決着して、とやるわ
けですが、成功する確率が高い時には遅くなります。上の例では、
B より先に A1, A2, A3 を先に投票にかけるような方法が楽観的/
投機的な方法です。逆に悲観的な方法では、予約とかキャンセルと
いう考え方がないので、こうはいきません。
まとめると、こうなります。
・「依存」は、具体例で考えると非常にわかりやすい。
・予約やキャンセルは、わかりやすい。
・予約やキャンセルという考え方を使うと議論が速くなる。
・議論の期間を区切ることは大事。
・ngMP v8 の「CFD」や「議案群」という、議案をグループ化した
ものの役割がまだ不明である。
・ngMP v8 の「CFD」と「CFD」の関係が不明で、期間が区切れるの
かも不明である。ngMP v4, v5 には、そのような問題はない。
というわけで、楽観的にいきましょう。
\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報 \\
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735