アカウント名:
パスワード:
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁスポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
pull requestなんだから提案者が直し済みでしょ。コストが問題になる場面じゃない。しかもプログラム本体じゃなくてコメントの話なんだけど。「プロジェクトの本質に関係ない部分」を変えたくないっていうのもよくわからない。変更に慎重になるのはむしろ本質に関係ある部分じゃないの？
#とんちんかんなことを言っているように見えるんだけど、なんでこんなに評価が高いんだ？
ドキュメントの機能は、コードを正しく表現することだろすでにその機能を有している状況でドキュメントを修正すると、校正する手間が発生するじゃんドキュメントプロジェクトなんだからコードの内容は関係ないけど「正常なプログラムは修正するな」の法則のほうは同じく適用されるべきってことじゃね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
既存のドキュメントを書き直す手間 (スコア:3, すばらしい洞察)
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか
日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁ
スポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
手間？ (スコア:0)
pull requestなんだから提案者が直し済みでしょ。コストが問題になる場面じゃない。
しかもプログラム本体じゃなくてコメントの話なんだけど。
「プロジェクトの本質に関係ない部分」を変えたくないっていうのもよくわからない。変更に慎重になるのはむしろ本質に関係ある部分じゃないの？
#とんちんかんなことを言っているように見えるんだけど、なんでこんなに評価が高いんだ？
Re:手間？ (スコア:0)
ドキュメントの機能は、コードを正しく表現することだろ
すでにその機能を有している状況でドキュメントを修正すると、校正する手間が発生するじゃん
ドキュメントプロジェクトなんだからコードの内容は関係ないけど「正常なプログラムは修正するな」の法則のほうは同じく適用されるべきってことじゃね？