[ruby-list:40279] Re: 「標準ライブラリ選定委員会」なんてのは？

たけ(tk)です

[ruby-list:40278] Re: 「標準ライブラリ選定委員会」なんてのは？ にて
Hidetoshi NAGAI <[e-mail]> さん曰く:

> あぁ，ディストリビューターというのは，単に配布パッケージを構築する人の
> ことだったですか．
> 標準とされたライブラリを作成，管理し source tree に提供する人のことかと
> 勝手に思い込んでました．
> ごめんなさい．

こちらもゴメンナサイ。たけ(tk)にしてはきついメールになってしまいました。

> ですので，前のメールでの私の記述はライブラリ開発者についての課題として
> 読み替えてください．
・・
> 私の批判は主として
> 委員会の「強制権」についての話であることに注意いただけると幸いです．

了解しました。

> で，わからなくなったのが「標準」の意味合いなのですが，
> この「標準」というのは
> 
> (1) 現在の標準ライブラリと同じで source archive には必ず含まれて
>     いるもの
> 
> のことでしょうか．それとも
> 
> (2) 現在の標準ライブラリに加えて，配布用バイナリパッケージ(?)には
>     必ず含まれるようにするもの
> 
> のことでしょうか．

たけ(tk)としては「(1) 現在の標準ライブラリと同じ」という意味合いしか頭に
なかったです。

「標準」ということは、ユーザから見て、どんなパッケージでインストールして
も必ず入っていると安心できる、ということです。


> ですが，ある意味巻き込まれた形であるライブラリ開発者にも
> 責任を被せるのは是していいものでしょうか？
> 委員会委員の任期をどう考えておられるのかはわかりませんが，
> 選定した委員が委員をやめてしまっても，ライブラリ開発者には
> 責任が残り続けるわけですよね？

現在の方法がどうなっているのか知りませんが、「標準添付のライブラリに入れ
てよいですか？」「OKです」くらいのやりとりはあるでしょう。

「OK」です、といった責任はあると思います。しかし、ボランティアなのだから、
メンテナンスに興味がなくなったときには、「他の人にメンテナを頼む」ていど
の責任を果たしてもらえればOKだと思います。

> > > にもかかわらず，委員会で決めたライブラリは「添付しなければならない」
> > > ということになっています．
> > > これは上記のような覚悟をディストリビュータに無理強いしていることに
> > > なります．
> > 
> > むしろ、選定委員会の方に覚悟が必要ですね。
> 
> 委員会の「覚悟して行わねばならないこと」というのは何でしょう？
> 単に「非難される」ということではないのですよね？

「非難される」だけでも、かなりきついと思いますよ。

それ以外の覚悟としては、「（非難されないように？）公明正大に手続きや決定
過程を公開すること」「内容的にも、ユーザの要望を満たし、かつ、高品質なモ
ノを選定すること」「将来にわたってライブラリの品質が確保されるように手を
打っておくこと」でしょうか。

> > 対象ライブラリが維持できなくなった場合には、委員会から参加者に「維持でき
> > なくなったので廃止予定である。メンテナを募集する。」といった案内を出して、
> > 駄目なら廃止するほかないでしょう。使えなくなったライブラリは付けてもしょ
> > うがない。
> > 
> > 委員会の役割としては、メンテナの確保、連絡、募集、といった作業になると思
> > います。
> 
> というのだとすると，強制してまで加えることの責任は果たしきれていない
> のではないでしょうか．

不可能なことはできない。ということですが、下記（↓）には同意します。

> 廃止してしまうと，「標準だから」と思って使っていたユーザを
> その時点で置き去りにしてしまうことになります．
> 私にはそれは簡単には許されて良いものではないと思えるのです．
> 
> ・代りのメンテナが見つかるまでは委員会がメンテを代行する．
> 
> ・メンテナが見つかりそうにないときは，代換となるライブラリを
>   添付できるように手配する．
> 
> ・廃止の前にその代換ライブラリへの移行がゆっくりと行えるだけの
>   十分な期間のメンテは (将来の廃止を警告しつつ) 継続する．
> 
> という程度は必要に感じます．

そうです。

> > > 委員会はそれだけの権限を持つことになりますが，誰がその委員会の
> > > メンバーを選ぶのでしょうか．
> > 
> > 人選の方法までは考えていませんが、自然に決まるか、選挙か、まつもとさんに
> > 決めてもらうか、その他の方法か、いろいろあると思います。現状の引継という
> > 意味ではまつもとさんが選任するという方法もありかも。
> > 
> > むしろ、ライブラリの選定の仕方を「ユーザが求めるモノであって」「品質等に
> > 問題がない」ものに決まっていくようにする仕組みを考える必要があると思いま
> > す。
> 
> 提案されているような強制権を持った委員会ではなく，
> まつもとさんから標準添付の是非を決定権を委譲された人 (選挙で選ぶでも
> もちろんかまいません) が ML 上での議論を経て最終決定するという程度の
> 形態ではダメですか？

よいです。人選に関しては「自然に決まる」のが一番良い。

強制権に関しては「ユーザが（必ず入っているはずだと）安心してパッケージを
選択できる」かどうかを基準にして、どの程度の強制力が必要かを考える必要が
あると思います。

> 添付を希望するなら，効能や価値，ユーザが安心して継続利用できることを
> きちんとに説明して，理解してもらい，広くコンセンサスを得るようにすると
> いうのは当然のことでしょう．
> 
> コンセンサスが得られないなら標準添付は避けるべきでしょうし，
> 得られるようなら標準添付は問題ないはずです．
> 決定権保有者はそれに従って最終決定を下すだけのことです．
> 
> 決定権保有者が添付反対の意見を持つなら，当然，反対意見で
> 議論に参加していたでしょうから，勝手に引っくり返すことは
> 考えなくてもよいと思います．
> 
> もしそんなことをしたり，進行中の堂々巡りではない議論を勝手に
> 打ち切ったりするようなら，決定権者のリコールという話になるだけです．

そうそう。そうです。

> > 基本的にはWeb投票で候補を決めて、選定委員会のほうで、品質、一貫性、メン
> > テナンス可能性、などを検討する形を考えています。
> > 
> > Web投票のシステムは自動化できそうな気がする。標準ライブラリについて要望
> > がある人がメールアドレスとパスワードの登録だけで参加できるようにする。
> 
> 組織票の問題は委員会での検討で回避するということですね？
> ML 上のオープンな議論ではいけない理由というのがわからないのですが．．．

ML 上のオープンな議論ではいけない理由はないです。むしろ、積極的に議論す
る必要がある。

ただし、最終的にはWeb投票で数字が出てきた方が、選定に説得力を付けやすい、
ということです。

＊　心配なのは、議論を、英語でやるのか日本語でやるのか・・。

Take_tk = KUMAGAI Hidetake
たけ(tk)＝熊谷秀武