アカウント名:
パスワード:
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁスポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
ポリシーを変更するなんて話は誰もしていないと思うんだけど。それとも、 libuv には「コメント中の英語の中に出てくる user は he で受ける」というポリシーがあったの?
本質に関係ないんだから、別に開発者が却下するようなことでもないと思うんだよね。ドキュメントのheを直したいですって言葉には、好きにすればって答えればよかったのに、なんでちょっと強行とも思えるような却下を決定したのか。この件は手間とか無駄とかより感情的なもののような気がする。
機能的なところと関係ない変更は、外部から突然やってくる。会社が買収されたり法令が変わったりしてドキュメントが書き換わることはよくあるんだから、社会的な価値観の変遷ということで、同じと考えてもおかしくないかと。
そしてコメントミスって余計な文言が入ったり、機械的に置換したせいで意味の分からない箇所が生じたり、置換漏れて旧規則と新規則が併存したり、ドキュメントとソースコメントが食い違って煩雑になったり、ドキュメントにあわせてプログラム内のコメント修正する過程でバグが埋め込まれたり、膨大なコメント修正に重要なコミットが埋もれたり、プログラムコメントに手を加えた場合には書き換えた箇所に対するテスト工数が莫大なことになったりする（コメントなので変化ないはずだけど、確認要求してくるプロジェクトは多い）
少なくともエンジニア視点では、プログラムが第一で、ドキュメント類の付随物はあくまでプログラムに従属するものであるとして、プログラムに関係なく、誤り修正でもない作業は極力排除するというのは正しい判断だと思う。
もちろん政治的な外圧でどうにもならないこともあるけど、どうにかなるうちは拒絶する態度を見せるのは良い事。構成管理者はこのような事案はリスク軽減のためにも厳しくあたるべきだと思う。
> 本質に関係ない部分で変更しなくてはならないんだろうか
逆じゃないかな。
本質(=コード)の変更ができないからこそ本質に関係ない部分にここまでこだわるんじゃないかと。
開発者の確保に支障をきたすとかなら分かるけどねえ
そのうちドキュメント書き方標準というのができておそらくその方面で先進的()なEUで強制されてこれに従わないコードは使えなくなるんでしょうね
ああやだやだ
いいんじゃないの？良く有ることだとおもうよ？スポンサーもエンジニアも、お互いにとって主張を通す事に価値があると判断したんでしょ会社にとっちゃ社外のプロジェクトが多少混乱するよりも差別的だとか他所からお客が来るのはさぞ怖いだろうし
pull requestなんだから提案者が直し済みでしょ。コストが問題になる場面じゃない。しかもプログラム本体じゃなくてコメントの話なんだけど。「プロジェクトの本質に関係ない部分」を変えたくないっていうのもよくわからない。変更に慎重になるのはむしろ本質に関係ある部分じゃないの？
#とんちんかんなことを言っているように見えるんだけど、なんでこんなに評価が高いんだ？
ドキュメントの機能は、コードを正しく表現することだろすでにその機能を有している状況でドキュメントを修正すると、校正する手間が発生するじゃんドキュメントプロジェクトなんだからコードの内容は関係ないけど「正常なプログラムは修正するな」の法則のほうは同じく適用されるべきってことじゃね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
既存のドキュメントを書き直す手間 (スコア:3, すばらしい洞察)
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか
日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁ
スポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
Re:既存のドキュメントを書き直す手間 (スコア:2)
ポリシーを変更するなんて話は誰もしていないと思うんだけど。それとも、 libuv には「コメント中の英語の中に出てくる user は he で受ける」というポリシーがあったの?
Re:既存のドキュメントを書き直す手間 (スコア:1)
本質に関係ないんだから、別に開発者が却下するようなことでもないと思うんだよね。ドキュメントのheを直したいですって言葉には、好きにすればって答えればよかったのに、なんでちょっと強行とも思えるような却下を決定したのか。この件は手間とか無駄とかより感情的なもののような気がする。
LIVE-GON(リベゴン)
Re: (スコア:0)
機能的なところと関係ない変更は、外部から突然やってくる。
会社が買収されたり法令が変わったりしてドキュメントが書き換わることはよくあるんだから、
社会的な価値観の変遷ということで、同じと考えてもおかしくないかと。
Re:既存のドキュメントを書き直す手間 (スコア:2, すばらしい洞察)
そしてコメントミスって余計な文言が入ったり、機械的に置換したせいで意味の分からない箇所が生じたり、置換漏れて旧規則と新規則が併存したり、ドキュメントとソースコメントが食い違って煩雑になったり、ドキュメントにあわせてプログラム内のコメント修正する過程でバグが埋め込まれたり、膨大なコメント修正に重要なコミットが埋もれたり、プログラムコメントに手を加えた場合には書き換えた箇所に対するテスト工数が莫大なことになったりする（コメントなので変化ないはずだけど、確認要求してくるプロジェクトは多い）
少なくともエンジニア視点では、プログラムが第一で、ドキュメント類の付随物はあくまでプログラムに従属するものであるとして、プログラムに関係なく、誤り修正でもない作業は極力排除するというのは正しい判断だと思う。
もちろん政治的な外圧でどうにもならないこともあるけど、どうにかなるうちは拒絶する態度を見せるのは良い事。
構成管理者はこのような事案はリスク軽減のためにも厳しくあたるべきだと思う。
Re: (スコア:0)
> 本質に関係ない部分で変更しなくてはならないんだろうか
逆じゃないかな。
本質(=コード)の変更ができないからこそ
本質に関係ない部分にここまでこだわるんじゃないかと。
Re: (スコア:0)
開発者の確保に支障をきたす
とかなら分かるけどねえ
そのうちドキュメント書き方標準というのができて
おそらくその方面で先進的()なEUで強制されて
これに従わないコードは使えなくなるんでしょうね
ああやだやだ
Re: (スコア:0)
いいんじゃないの？良く有ることだとおもうよ？
スポンサーもエンジニアも、お互いにとって
主張を通す事に価値があると判断したんでしょ
会社にとっちゃ社外のプロジェクトが多少混乱するよりも
差別的だとか他所からお客が来るのはさぞ怖いだろうし
手間？ (スコア:0)
pull requestなんだから提案者が直し済みでしょ。コストが問題になる場面じゃない。
しかもプログラム本体じゃなくてコメントの話なんだけど。
「プロジェクトの本質に関係ない部分」を変えたくないっていうのもよくわからない。変更に慎重になるのはむしろ本質に関係ある部分じゃないの？
#とんちんかんなことを言っているように見えるんだけど、なんでこんなに評価が高いんだ？
Re: (スコア:0)
ドキュメントの機能は、コードを正しく表現することだろ
すでにその機能を有している状況でドキュメントを修正すると、校正する手間が発生するじゃん
ドキュメントプロジェクトなんだからコードの内容は関係ないけど「正常なプログラムは修正するな」の法則のほうは同じく適用されるべきってことじゃね？