Author: mumumu Date: Sat Sep 15 18:00:17 2007 New Revision: 1182 Log: - "Version Control Means You Can Relax" section complete.
Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml ============================================================================== --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 18:00:17 2007 @@ -543,6 +543,7 @@ <sect2 id="version-control-relaxation"> <title>バージョン管理を行なうと堅くならずに済む</title> +<!-- <para>The fact that the project's source code is kept under version control means that most decisions can be easily unmade. The most common way this happens is that someone commits a change mistakenly @@ -559,7 +560,28 @@ bad or hasty judgement. This, in turn, frees people to trust their instincts about how much feedback is necessary before doing something.</para> +--> + +<para> + プロジェクトのソースコードがバージョン管理下にあるということは、 + ほとんどの決定を元に戻せるということを意味します。 + 変更を元に戻す原因としてよくあるのが、 + 皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、 + これは結局コミットした後に反対されることになります。 + こうした反対意見は決まって、 + 以前の議論を見逃したことを詫びることから始まりますが、 + 反対する人がメーリングリストのアーカイブにこれにあたる議論を見つけられなかった場合は省略されます。 + どちらにせよ、変更がコミットされる前と後とで議論の口調を変える理由はありません。 + 少なくとも、あるコミットに依存する変更が行われた時点 + （i.e. もともと加えられていた変更が突然削除され、新しい変更がそれを壊していた場合） + まで、変更は取り消すことができます。 + バージョン管理システムは、プロジェクトにとってよくない、 + または性急な判断から生じた結果を元に戻す手段を与えているのです。 + これは言い替えれば、開発者が何かをする前にどのくらいのフィードバックが必要かということを、 + 自分の直感を信頼して判断してよい、ということでもあります。 +</para> +<!-- <para>This also means that the process of establishing consensus need not be very formal. Most projects handle it by feel. Minor changes can go in with no discussion, or with minimal discussion followed by a @@ -568,7 +590,19 @@ day or two before assuming there is consensus, the rationale being that no one should be marginalized in an important conversation simply because he didn't check email frequently enough.</para> +--> +<para> + このことは、合意を得る手続きを型にはめる必要がないということでもあります。 + ほとんどのプロジェクトはこの手続きを感覚で扱っています。 + 小さな変更は、議論をしないか、最小限の議論だけをして、2、3の賛成があったあとに行われます。 + より重要な変更、特に多くのコードを不安定にさせる変更については、 + 開発者達は合意に達した、 + つまり単にメールを頻繁にチェックしていなかっただけの理由で重要な議論をないがしろにしたヤツはいないはずだ、 + という合理的な根拠があるとみなす前に、１日か２日の間を置くべきです。 +</para> + +<!-- <para>Thus, when someone is confident he knows what needs to be done, he should just go ahead and do it. This applies not only to software fixes, but to web site updates, documentation changes, and anything @@ -583,6 +617,25 @@ this fact by committing potentially controversial changes too quickly, however, people can and should complain, and hold that developer to a stricter standard until things improve.</para> +--> + +<para> + というわけで、自分がやるべきことを理解しているのなら、 + 単に作業を進めてやり遂げるべきです。これはソフトウェアの修正だけでなく、 + ウェブサイトの更新、ドキュメントの変更、 + そして議論になりそうにない他のあらゆることに当てはまります。 + 通常、とられたアクションを元に戻す必要がある事例は少ししかないでしょうし、 + そうした事例はケースバイケースで扱えます。 + もちろん、聞く耳を持たないことを奨励すべきではありません。 + 議論中の事項と、既に実行されて効果が表れている決定事項の間には、 + いくら技術的に元に戻せるとはいっても精神的な差があります。 + 開発者達は勢いが行動に繋がるといつも思っていますし、 + はじめに変更するのをやめさせることより、 + 行われた変更を元に戻すことの方がちょっと気が進まないでしょう。 + ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、 + 他の開発者達は文句を言えますし、言うべきです。 + そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。 +</para> </sect2> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
