アカウント名:
パスワード:
とある若いプロジェクトに熱心な貢献者(?)が張り付いたことがあった。連日のようにプロジェクトのここが悪い、あそこが悪いとバグを起票して、文章の最後は自分で直すからコミット権をよこせと結んでいた。
ほどなくしてプロジェクトの更新が止まった。楽しくなかったろうしね。
外部から行動を起こしてそれが良い結果に結びついたとしたら、プロジェクト内に受け止める人がいてこそ可能だったことだろう。
本来は、貢献した者の意見だからこそ受け入れられる。
意見を出す人間が貢献してきたどうかなんてあんまし関係ないと思うけど。
むしろ端から見てもウザい奴の要求だったからこそ、管理者はプロジェクトを放棄した罪悪感を多少なりとも薄められていたはず。
もし、要求が貢献した人間(プロジェクトの管理人が恩義を感じている人間)からだったら、管理人は強烈なプレッシャーで潰されて、さらに悲惨なことになっていたかもしれない。
相手のキャパシティを超えた要求をしない、すれば相手は潰れる、それだけのこと。逆に要求される側も、受け止められないことはスルーしてもいい、そのことを忘れてはいけない。
# そもそも「俺はこいつのために貢献したから、意見を聞いてくれるはずだ」なんて# 思っている奴とはあまり関わりたくないな…。
なるほど、モンスター・コントリビュータには確かに関わりたくないな。
> 逆に要求される側も、受け止められないことはスルーしてもいい、そのことを忘れてはいけない。
ある程度の規模のプロジェクトでスルーすると、開発プロセスがオープンでないと批判されることがある。面倒でも却下した理由を言葉を尽くして説明して、議論の相手をしないといけない。個人プロジェクトならいいけど。
立場を理解して仲裁してくれる人がいると助かる。これも立派な貢献だと感じる。
批判されたって別にいい。スルーしてもいいってそういうことです。企業プロジェクトならなおさら。目的の遂行が最優先なのであって、顧客でもなんでもない、ただの外野の批判なんてのは真っ先に切り捨てる対象でしょう。
アホの相手をしてそのせいでプロジェクトが滞ったりしたら、それこそプロジェクトに期待している人たちへの裏切りですよ。結局、どう転んでも批判は免れません。
バグを指摘されても自分ではなおさず、なおすと言ってくれている人にコミット権もあたえず自滅したんですか?
テストの自動化が足りないとか、ディレクトリ構成が好みでないとか、コピーレフトなライセンスを使えとか。外部からみると歯がゆいかもしれないが、あまり口出しすることではないと思う。
ここでのバグって「issue」の方じゃない?
ガン無視した経緯がまったくわからないエピソードですよね。
その流れならパッチよこせとかいうのが正解では?貢献するといっているのに受け止めないとは…
いや、だから、貢献を受け入れることそのものは貢献に匹敵するかヘタするとそれ以上に負担なの。既に信用が得られている作業者の貢献なら負担も少ないだろうけど、まずその技術的背景から精査しないといけない貢献をテンポラリに受け入れろというのは酷でしょう。
パッチの現物も出せないような奴は貢献以前の問題って事でしょ。パッチも出せない奴がコミット権持っても何かできるわけがないし、「パッチよこせ」と言っとけば口だけ野郎はその段階で排除できる。よこされたパッチも却下は出来るし、毎回パッチ書かせれば口だけノイズよりも静かになるのが期待できる。
とりあえずフォークしてくださいというのが正解じゃないかと。貢献する方も、コミット権よこせとか言わずにフォークすればいいのにと思うけど、何かフォークできない理由があったんですかね。
「貢献する」と大声で言う人には要注意というのがこのストーリーの話題なわけで。#2782162を見るに、テストコードが書きにくいディレクトリ構造だったのかね。
ユーザー承認だとか、テスト手法だとか、それがだめになるとすべてが終わりとなる、キーとなる要素があるのは事実ですが、
それらは、キーとなる要素であるが為に、権限を掌握しさえすれば(これ自体大変ですが)非常に少ない労力で出来うるものばかりです。それは容易に定義から導き出されます。
なので、そのキーとなる要素のみを一手に引き受ける役割の人間を作ってしまうと、・それ以外の(圧倒的に大きな)労力をその人間がしなくて良くなる。・それ以外の(圧倒的に大きな)労力をその人間がしなくて良くなるのをほかの人がみて 自分もそうなりたいと思う。(ロールモデルとして)
で、だれもしなくなってしまう事になります。(不可避的に)
もし、キーとなる要素を定式化した人間は、すすんでそれ以外を担う様にすべきで、労力の分配を損ねるすべての試みは、貢献と見なされるべきでは無いと思う。そして、そのキーとなる要素は多額の投資をしてくれた人間に名誉的に与えられるべきだと思う。
あちゃーって感じのパッチ送られてきても困っちゃうんだよねぇ…
それならそれで却下すればいい
荒らし vs 自治厨
そのプロジェクトの場合は違うような気がするが、鬱陶しくなったらプロジェクトを畳むというのは一手だと思う。少しの休止期間の後、気の合ったメンバーにだけ声を掛けて、別の名前で後継プロジェクトを開始する。(水商売なんかでは、経営者の一身上の都合で店を畳んでしまうという形式のリストラがあるそうな)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
貢献した者の意見だからこそ受け入れられる (スコア:4, 興味深い)
とある若いプロジェクトに熱心な貢献者(?)が張り付いたことがあった。
連日のようにプロジェクトのここが悪い、あそこが悪いとバグを起票して、文章の最後は自分で直すからコミット権をよこせと結んでいた。
ほどなくしてプロジェクトの更新が止まった。
楽しくなかったろうしね。
外部から行動を起こしてそれが良い結果に結びついたとしたら、プロジェクト内に受け止める人がいてこそ可能だったことだろう。
本来は、貢献した者の意見だからこそ受け入れられる。
Re:貢献した者の意見だからこそ受け入れられる (スコア:3, 興味深い)
意見を出す人間が貢献してきたどうかなんてあんまし関係ないと思うけど。
むしろ端から見てもウザい奴の要求だったからこそ、管理者はプロジェクトを
放棄した罪悪感を多少なりとも薄められていたはず。
もし、要求が貢献した人間(プロジェクトの管理人が恩義を感じている人間)からだったら、
管理人は強烈なプレッシャーで潰されて、さらに悲惨なことになっていたかもしれない。
相手のキャパシティを超えた要求をしない、すれば相手は潰れる、それだけのこと。
逆に要求される側も、受け止められないことはスルーしてもいい、そのことを忘れてはいけない。
# そもそも「俺はこいつのために貢献したから、意見を聞いてくれるはずだ」なんて
# 思っている奴とはあまり関わりたくないな…。
Re:貢献した者の意見だからこそ受け入れられる (スコア:1)
なるほど、モンスター・コントリビュータには確かに関わりたくないな。
> 逆に要求される側も、受け止められないことはスルーしてもいい、そのことを忘れてはいけない。
ある程度の規模のプロジェクトでスルーすると、開発プロセスがオープンでないと批判されることがある。
面倒でも却下した理由を言葉を尽くして説明して、議論の相手をしないといけない。
個人プロジェクトならいいけど。
立場を理解して仲裁してくれる人がいると助かる。これも立派な貢献だと感じる。
Re: (スコア:0)
批判されたって別にいい。スルーしてもいいってそういうことです。
企業プロジェクトならなおさら。目的の遂行が最優先なのであって、
顧客でもなんでもない、ただの外野の批判なんてのは真っ先に切り捨てる対象でしょう。
アホの相手をしてそのせいでプロジェクトが滞ったりしたら、
それこそプロジェクトに期待している人たちへの裏切りですよ。
結局、どう転んでも批判は免れません。
Re: (スコア:0)
バグを指摘されても自分ではなおさず、なおすと言ってくれている人にコミット権もあたえず自滅したんですか?
Re:貢献した者の意見だからこそ受け入れられる (スコア:1)
テストの自動化が足りないとか、ディレクトリ構成が好みでないとか、コピーレフトなライセンスを使えとか。
外部からみると歯がゆいかもしれないが、あまり口出しすることではないと思う。
Re: (スコア:0)
ここでのバグって「issue」の方じゃない?
Re: (スコア:0)
ガン無視した経緯がまったくわからないエピソードですよね。
Re: (スコア:0)
その流れならパッチよこせとかいうのが正解では?
貢献するといっているのに受け止めないとは…
Re:貢献した者の意見だからこそ受け入れられる (スコア:1)
いや、だから、貢献を受け入れることそのものは貢献に匹敵するかヘタするとそれ以上に負担なの。
既に信用が得られている作業者の貢献なら負担も少ないだろうけど、まずその技術的背景から精査しないといけない貢献をテンポラリに受け入れろというのは酷でしょう。
Re: (スコア:0)
パッチの現物も出せないような奴は貢献以前の問題って事でしょ。
パッチも出せない奴がコミット権持っても何かできるわけがないし、「パッチよこせ」と言っとけば口だけ野郎はその段階で排除できる。
よこされたパッチも却下は出来るし、毎回パッチ書かせれば口だけノイズよりも静かになるのが期待できる。
Re:貢献した者の意見だからこそ受け入れられる (スコア:1)
とりあえずフォークしてくださいというのが正解じゃないかと。
貢献する方も、コミット権よこせとか言わずにフォークすればいいのにと思うけど、何かフォークできない理由があったんですかね。
Re: (スコア:0)
「貢献する」と大声で言う人には要注意というのがこのストーリーの話題なわけで。
#2782162を見るに、テストコードが書きにくいディレクトリ構造だったのかね。
Re: (スコア:0)
ユーザー承認だとか、テスト手法だとか、それがだめになるとすべてが終わりとなる、
キーとなる要素があるのは事実ですが、
それらは、キーとなる要素であるが為に、権限を掌握しさえすれば(これ自体大変ですが)
非常に少ない労力で出来うるものばかりです。それは容易に定義から導き出されます。
なので、そのキーとなる要素のみを一手に引き受ける役割の人間を作ってしまうと、
・それ以外の(圧倒的に大きな)労力をその人間がしなくて良くなる。
・それ以外の(圧倒的に大きな)労力をその人間がしなくて良くなるのをほかの人がみて
自分もそうなりたいと思う。(ロールモデルとして)
で、だれもしなくなってしまう事になります。(不可避的に)
もし、キーとなる要素を定式化した人間は、すすんでそれ以外を担う様にすべきで、
労力の分配を損ねるすべての試みは、貢献と見なされるべきでは無いと思う。
そして、そのキーとなる要素は多額の投資をしてくれた人間に名誉的に与えられるべき
だと思う。
Re: (スコア:0)
あちゃーって感じのパッチ送られてきても困っちゃうんだよねぇ…
Re: (スコア:0)
それならそれで却下すればいい
Re: (スコア:0)
Re: (スコア:0)
荒らし vs 自治厨
Re: (スコア:0)
そのプロジェクトの場合は違うような気がするが、鬱陶しくなったらプロジェクトを畳むというのは一手だと思う。
少しの休止期間の後、気の合ったメンバーにだけ声を掛けて、別の名前で後継プロジェクトを開始する。
(水商売なんかでは、経営者の一身上の都合で店を畳んでしまうという形式のリストラがあるそうな)