[ProducingOSS commit] r1569 - trunk/ja
Author: mumumu Date: Sun Nov 23 16:56:59 2008 New Revision: 1569 Log: - translated introduction of Choosing a License section. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 23 16:56:59 2008 @@ -999,29 +999,65 @@ !-- SECTION == -- sect1 id=license-choosing +!-- titleChoosing a License/title +-- +titleライセンスを選ぶ/title +!-- paraWhen choosing a license to apply to your project, if at all possible use an existing license instead of making up a new one. There are two reasons why existing licenses are better:/para +-- + +para +プロジェクトに適用するライセンスを選ぶときは、 +新しいものを作るよりは、できる限り既にあるものを使うようにしましょう。 +既にあるものを使う方がよい理由はふたつあります。 +/para itemizedlist + !-- listitemparaFamiliarity. If you use one of the three or four most popular licenses, people won't feel they have to read the legalese in order to use your code, because they'll have already done so for that license a long time ago./para /listitem + -- + + listitemparaそのライセンスが既に知られているからです。 +あなたが人気のあるライセンスのうちのひとつを使えば、 +コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。 +なぜなら、ずっと以前にそうしたことがあるからです。/para + /listitem + + !-- listitemparaQuality. Unless you have a team of lawyers at your disposal, you are unlikely to come up with a legally solid license. The licenses mentioned here are the products of much thought and experience; unless your project has truly unusual needs, it is unlikely you would do better./para /listitem + -- + + listitemparaライセンスの質が保たれているからです。 +自分の思い通りになる弁護士のチームがいなければ、 +法的に隙がないライセンスを生み出すことはできないでしょう。 +この章で触れているライセンスには、多くの人々の経験や思考が詰まっています。 +つまり、あなたのプロジェクトに本当に変わった要求がない限り、 +さらに行動する必要はないということです。/para + /listitem + /itemizedlist - + +!-- paraTo apply one of these licenses to your project, see xref linkend=license-quickstart-applying/phrase output=printed in xref linkend=getting-started//phrase./para +-- + +paraプロジェクトにライセンスを適用するには、 +phrase output=printedxref linkend=getting-started/ の /phrase xref linkend=license-quickstart-applying/ を参照してください。/para sect2 id=license-choosing-mit-x titleThe MIT / X Window System License/title ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1570 - trunk/ja
Author: mumumu Date: Sun Nov 23 17:00:42 2008 New Revision: 1570 Log: - r1569 translation tweaks. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 23 17:00:42 2008 @@ -1012,8 +1012,8 @@ para プロジェクトに適用するライセンスを選ぶときは、 -新しいものを作るよりは、できる限り既にあるものを使うようにしましょう。 -既にあるものを使う方がよい理由はふたつあります。 +できる限り新しいものを作らず、既にあるものを使うようにしましょう。 +既にあるものを使う理由はふたつあります。 /para itemizedlist @@ -1025,10 +1025,10 @@ /listitem -- - listitemparaそのライセンスが既に知られているからです。 + listitemparaライセンスが既に知られているからです。 あなたが人気のあるライセンスのうちのひとつを使えば、 コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。 -なぜなら、ずっと以前にそうしたことがあるからです。/para +なぜなら、ずっと以前に読んだことがあるからです。/para /listitem !-- ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1571 - trunk/ja
Author: mumumu Date: Sun Nov 23 17:49:04 2008 New Revision: 1571 Log: - translated The MIT / X Window System License section. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 23 17:49:04 2008 @@ -1012,8 +1012,8 @@ para プロジェクトに適用するライセンスを選ぶときは、 -できる限り新しいものを作らず、既にあるものを使うようにしましょう。 -既にあるものを使う理由はふたつあります。 +できる限り新しいものを作らずに既にあるものを使うようにしましょう。 +有り物を使う理由はふたつあります。 /para itemizedlist @@ -1028,7 +1028,7 @@ listitemparaライセンスが既に知られているからです。 あなたが人気のあるライセンスのうちのひとつを使えば、 コードを使う人が法律用語をわざわざ読む必要はないと思うでしょう。 -なぜなら、ずっと以前に読んだことがあるからです。/para +ずっと以前に読んだことがあるからです。/para /listitem !-- @@ -1060,8 +1060,9 @@ phrase output=printedxref linkend=getting-started/ の /phrase xref linkend=license-quickstart-applying/ を参照してください。/para sect2 id=license-choosing-mit-x -titleThe MIT / X Window System License/title +titleMIT / X Window System License/title +!-- paraIf your goal is that your code be accessible by the greatest possible number of developers and derivative works, and you do not mind the code being used in proprietary programs, choose the MIT / X @@ -1070,7 +1071,20 @@ Window System code). This license's basic message is You are free to use this code however you want. It is compatible with the GNU GPL, and it is short, simple, and easy to understand:/para +-- + +para +自分のコードをできる限り多くの開発者と派生物で使ってもらい、 +かつプロプラエタリなコードで使われるのを気にしないのならば、 +MIT/ X Window System License (マサチューセッツ工科大学 +がオリジナルの X Window System のコードをこのライセンスでリリースしたので、 +そう呼ばれています) を選びましょう。このライセンスが言っているのは基本的に +「あなたはこのコードを自由に、 +無料で使うことができますよ」ということです。 +このライセンスは GNU GPL と互換性があり、短く、簡単で、理解しやすいものです。 +/para +!-- screenCopyright (c) lt;yeargt; lt;copyright holdersgt; Permission is hereby granted, free of charge, to any person obtaining @@ -1091,9 +1105,18 @@ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE./screen +-- + +screenCopyright (c) lt;yeargt; lt;copyright holdersgt; + +以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。 + +上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。 + +ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。/screen -para(Taken from ulink -url=http://www.opensource.org/licenses/mit-license.php/.)/para +para(原文は ulink +url=http://www.opensource.org/licenses/mit-license.php/ にあります。日本語訳については ulink url=http://sourceforge.jp/projects/opensource/wiki/licenses%2FMIT_license/ から引用させて頂きました。)/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1572 - trunk/ja
Author: mumumu Date: Sun Nov 23 17:51:13 2008 New Revision: 1572 Log: - linefeed tweaks in screen tag. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 23 17:51:13 2008 @@ -1109,11 +1109,16 @@ screenCopyright (c) lt;yeargt; lt;copyright holdersgt; -以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。 +以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うこと +を無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提 +供する相手に同じことを許可する権利も無制限に含まれます。 上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。 -ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。/screen +ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、およ +び権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフト +ウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとし +ます。/screen para(原文は ulink url=http://www.opensource.org/licenses/mit-license.php/ にあります。日本語訳については ulink url=http://sourceforge.jp/projects/opensource/wiki/licenses%2FMIT_license/ から引用させて頂きました。)/para ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1566 - trunk/ja
Author: mumumu Date: Mon Nov 10 15:36:10 2008 New Revision: 1566 Log: - translated The GPL and License Compatibility section. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Mon Nov 10 15:36:10 2008 @@ -696,7 +696,7 @@ GPL は、 GPL で配布されたコードを使ったいかなる派生物も、 GPL として配布しなければならず、 かつ GPL が必要とすること以上の制限をつけてはならない、 - ということです。 + ことを要求しています。 GPL と互換性があるライセンスもあれば、ないものもあります。 詳しくは、phrase output=printed 後の方にある /phrase xref linkend=license-compatibility/ で議論しています。 @@ -841,8 +841,12 @@ !-- SECTION == -- sect1 id=license-compatibility +!-- titleThe GPL and License Compatibility/title +-- +titleGPL とライセンスの互換性/title +!-- paraBy far the sharpest dividing line in licensing is that between proprietary-incompatible and proprietary-compatible licenses, that is, between the GNU General Public License and everything else. Because @@ -852,20 +856,54 @@ GPL's requirements (see ulink url=http://www.fsf.org/licensing/licenses/gpl.html/ for its full text) are these two:/para +-- + +para +ライセンスをくっきりと分ける境界線は、 +プロプラエタリなライセンスと互換性があるか、ないかです。 +つまり、GPL (GNU General Public License) とそれ以外全てです。 +GPL の第一の目的はフリーソフトウェアを広めることなので、 +GPL を書いた人は、意図的にプロプラエタリなコードと GPL のコードを混ぜることができないようにしました。 +特に GPL が要求していること +(全文は ulink url=http://www.fsf.org/licensing/licenses/gpl.html/ を参照してください) は以下の二つです。 +/para orderedlist + !-- listitemparaAny derivative workmdash;that is, any work containing a nontrivial amount of GPLed codemdash;must itself be distributed under the GPL./para /listitem - listitemparaNo additional restrictions may be placed on the + -- + + listitem +para +すべての派生物 mdash; +つまり、GPL が適用されたコードを含んだあらゆるプログラム +mdash; は、それ自体も GPL で配布しなければならない。 +/para + /listitem + + listitem +!-- +paraNo additional restrictions may be placed on the redistribution of either the original work or a derivative work. (The exact language is: You may not impose any further restrictions on the recipients' exercise of the rights granted herein.)/para +-- + +para +オリジナルでも、派生物であっても、 +それを再配布する場合には制限を追加してはいけない。 +(原文の該当箇所を以下に引用します: 「あなたは、 + ソフトウェアを受け取る人がここで認められた権利を行使することに関して、 + これ以上他のいかなる制限も課してはならない。」) +/para /listitem /orderedlist +!-- paraWith these conditions, the GPL succeeds in making freedom contagious. Once a program is copyrighted under the GPL, its terms of redistribution are firsttermviral/firsttermmdash;they are passed @@ -881,7 +919,24 @@ at least not regrettable. The GPL not only keeps your software free, but effectively makes your software an agent in pushing emphasisother/emphasis software to enforce freedom as well./para +-- + +para +これらの条件によって、GPL は自由を伝播させることに成功しています。 +いったんプログラムが GPL で保護されると、 +再配布の条件が firstterm伝染する/firstterm のです +mdash; つまり、取り込んだコード以外のあらゆる部分にその条件を適用させ、 +かつ GPL を採用したコードをクローズドソースなプログラムで使うのを不可能にしているのです。 +しかしながら、 +これらの条項は他のフリーなライセンスと GPL を非互換にするものでもあります。 +通常は、他のライセンスが追加の条件を課したときに非互換が起きます +mdash; たとえば、何らかの方法でオリジナルの作者へのクレジットを要求する場合です +mdash; これは、GPL の 「あなたは、これ以上他のいかなる制限も課してはならない ...」 という文言に反しています。こうした二次的な結果は、望ましいものか、少なくとも悪いことではない、というのが FSF の見解です。 +GPL は あなたのソフトウェアをフリーな状態に保つだけでなく、 +emphasis他の/emphasis ソフトウェアにも自由を強制する媒体にもするのです。 +/para +!-- paraThe question of whether or not this is a good way to promote free software is one of the most persistent holy wars on the Internet (see xref linkend=holy-wars/phrase output=printed @@ -901,12 +956,44 @@ other would be under a closed-source license. But that concern applies only to the derivative works, not to the code you distribute in the first place./para +-- +para +この手法がフリーソフトウェアを広める優れた手段なのかどうかは、 +インターネット上でずっと続いている宗教論争 +(phrase output=printedxref linkend=communications/ の /phrase + xref linkend=holy-wars/ を参照してください) のひとつであり、 +ここでは深く触れません。重要なのは、 +GPL と互換性があるかどうかがライセンスを選ぶ際に重大な問題になるということです。GPL は非常に重要なオープンソースライセンスです。 +ulink url=http://freshmeat.net/stats/#license/ では、 +GPL が 68% を占めており、次に高いのは 6% です。 +GPL で保護されたコードと自分のコードを混ぜた上でフリーにしたいのなら +mdash; GPL なコードがたくさんあるのだから +mdash; GPLと互換性があるライセンスを選ぶべきです。 +GPL と互換性があるオープンソースライセンスのほとんどは、 +プロプラエタリなライセンスとも互換性があります。 +よって、そうしたライセンスを採用したコードは、 +GPL なコードでも使うことができますし、 +プロプラエタリなプログラムでも使うことができるのです。 +もちろん、そうやってコードを混ぜた +emphasis結果生じたもの/emphasis は相互に互換性がありません。 +なぜなら、一方は GPL となり、 +一方はクローズドソースなライセンスが適用されるからです。 +問題が及ぶのは派生物に対してのみであり、 +はじめに配布したオリジナルなコードは影響を受けません
[ProducingOSS commit] r1565 - trunk/ja
Author: mumumu Date: Sun Nov 9 08:26:36 2008 New Revision: 1565 Log: - r1563 translation tweaks. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 9 08:26:36 2008 @@ -622,14 +622,14 @@ para 多くのフリーソフトウェアライセンスが利用できますが、 -それら全てが述べている重要な点は同じです。 -つまり、誰もがコードを改変でき、 -オリジナルのままでも改造を加えた形でも再配布できること、 +それらが述べている重要な点はすべて同じです。 +つまり、誰もがコードを改造でき、 +オリジナルのままでも、改造を加えた形でも再配布できること、 そして著作権を持つ人、そしてソフトウェアの作者はいかなる保証もしない (無保証であること、責任を回避することは、 特にソフトウェアが改変されたことを知らないで実行する人がいる可能性を考えると特に重要です) ことです。 -それぞれのライセンスの違いは、2、3のよく起こる問題に集約できます。 +それぞれのライセンスの違いは、以下のよく起こる問題に集約できます。 /para variablelist @@ -761,9 +761,9 @@ (またはその著作権を持つ人や組織など) の名前を、事前の書面での許可なく派生物で使っては emphasisいけない/emphasis と定めています。 クレジットを強制するやり方は、 - ある名前をどこかで使うことを主張しますし、 - 商標で保護するやり方は、使わないことを主張しますが、 - これらはどちらも同じ要求を表しています。 + ある名前をどこかで使うことを求めますし、 + 商標で保護するやり方は、使わないことを求めますが、 + どちらも同じ要求を表しています。 つまり、オリジナルのソースコードへの敬意を払い、 それを伝播させたいけれども、 どこからもそうした敬意を傷つけられたくないのです。 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1563 - trunk/ja
Author: mumumu Date: Sat Nov 8 17:55:38 2008 New Revision: 1563 Log: - translated Aspects of Licenses section. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sat Nov 8 17:55:38 2008 @@ -604,8 +604,12 @@ !-- SECTION == -- sect1 id=license-aspects +!-- titleAspects of Licenses/title +-- +titleライセンスの特徴/title +!-- paraAlthough there are many different free software licenses available, in the important respects they all say the same things: that anyone can modify the code, that anyone can redistribute it both @@ -614,10 +618,29 @@ especially important given that people might run modified versions without even knowing it). The differences between licences boil down to a few oft-recurring issues:/para +-- + +para +多くのフリーソフトウェアライセンスが利用できますが、 +それら全てが述べている重要な点は同じです。 +つまり、誰もがコードを改変でき、 +オリジナルのままでも改造を加えた形でも再配布できること、 +そして著作権を持つ人、そしてソフトウェアの作者はいかなる保証もしない +(無保証であること、責任を回避することは、 + 特にソフトウェアが改変されたことを知らないで実行する人がいる可能性を考えると特に重要です) +ことです。 +それぞれのライセンスの違いは、2、3のよく起こる問題に集約できます。 +/para variablelist + !-- varlistentrytermcompatibility with proprietary licenses/term -listitemparaSome free licenses allow the covered code to be + -- + varlistentrytermプロプラエタリなライセンスとの互換性/term + +listitem + !-- + paraSome free licenses allow the covered code to be used in proprietary programs. This does not affect the licensing terms of the proprietary program: it is still as proprietary as ever, it just happens to contain some @@ -625,11 +648,29 @@ X Consortium License, BSD-style license, and the MIT-style license are all examples of proprietary-compatible licenses./para + -- + + para + フリーなライセンスの中には、 + それが適用されるコードをプロプラエタリなプログラムで使うことを認めるものがあります。 + これはプロプラエタリなプログラムのライセンス条件に影響を与えません。 + プロプラエタリなプログラムはプロプラエタリなままで、 + プロプラエタリでないソースコードがいくらか混入するだけです。 + Apacheライセンス、Xコンソーシアムライセンス、 + BSDスタイルのライセンス、そして MITスタイルのライセンスは、 + すべてプロプラエタリなライセンスと互換性があるライセンスの例です。 + /para /listitem /varlistentry + !-- varlistentrytermcompatibility with other free licenses/term -listitemparaMost free licenses are compatible with each other, + -- + varlistentryterm他のフリーなライセンスとの互換性/term + +listitem + !-- + paraMost free licenses are compatible with each other, meaning that code under one license can be combined with code under another, and the result distributed under either license without violating the terms of the @@ -642,22 +683,65 @@ detail in xref linkend=license-compatibility/phrase output=printed later in this chapter/phrase./para + -- + + para + ほとんどのフリーなライセンスはお互いに互換性があります。 + つまり、あるライセンスが適用されたコードは、 + 別のライセンスが適用されたコードと組み合わせることができます。 + 組み合わせた結果できたものは、 + それぞれのライセンス条件を破ることなく再配布することができます。 + このことの重要な例外は、GPL + (GNU General Public License) です。 + GPL は、 GPL で配布されたコードを使ったいかなる派生物も、 + GPL として配布しなければならず、 + かつ GPL が必要とすること以上の制限をつけてはならない、 + ということです。 + GPL と互換性があるライセンスもあれば、ないものもあります。 + 詳しくは、phrase output=printed 後の方にある /phrase + xref linkend=license-compatibility/ で議論しています。 + /para /listitem /varlistentry + !-- varlistentrytermenforcement of crediting/term -listitemparaSome free licenses stipulate that any use of the + -- + varlistentrytermクレジットの強制/term + +listitem + !-- + paraSome free licenses stipulate that any use of the covered code be accompanied by a notice, whose placement and display is usually specified, giving credit to the authors or copyright holders of the code. These licenses are often still proprietary-compatible: they do not necessarily demand that the derivative work be free, merely that credit be given to the free code./para + -- + + para + フリーなライセンスの中には、 + それが適用されたソースコードを使ういかなるコードにも、 + 注意書きを記すことを強制するものがあります。 + 注意書きの位置や内容も決まっているのが普通です。 + 内容はコードの作者や著作権を持つ人へのクレジットです。 + こうしたライセンスでも、 + プロプラエタリなライセンスと互換性があるものがあります。 + なぜなら、派生物がフリーであることを要求するのではなく、 + フリーなコードに対してクレジットを与えることだけを要求しているからです。 + /para
[ProducingOSS commit] r1561 - trunk/ja
Author: mumumu Date: Fri Nov 7 14:32:23 2008 New Revision: 1561 Log: - translated Terminology section. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Fri Nov 7 14:32:23 2008 @@ -22,12 +22,12 @@ para あなたが選ぶライセンスは、それがオープンソースである限り、 プロジェクトで採用するにあたって大きな影響を与えないはずです。 -ユーザーは、ソフトウェアを機能や質で選ぶことが一般的で、 -ライセンスの詳細に基づいて選んだりはしません。それでも、 +ユーザーは、ソフトウェアを機能や質を見て選ぶことが一般的で、 +ライセンスの詳細を見て選んだりはしません。それでも、 プロジェクトが採用するライセンスが目的に確実に合ったものにすることと、 -ライセンスに関する決定を他の人と議論できるようするために、 -フリーソフトウェアのライセンス問題に関する基本的なことがらは、 -やはり理解する必要があります。しかしながら私は法律家ではないですし、この章の内容も、 +ライセンスに関する決定を他の人と議論できるようにするために、 +フリーソフトウェアのライセンス問題に関する基本的なことがらはやはり理解する必要があります。 +しかしながら私は法律家ではないですし、この章の内容も、 法的なアドバイスを正式に受けて書いているわけではないことに注意してください。 そうするには、法律家を雇うか、あなた自身が法律家になる必要があるでしょう。 /para @@ -36,8 +36,12 @@ !-- SECTION == -- sect1 id=licenses-terminology +!-- titleTerminology/title +-- +title使用する用語/title +!-- paraIn any discussion of open source licensing, the first thing that becomes apparent is that there seem to be many different words for the same thing: firsttermfreenbsp;software/firstterm, @@ -45,16 +49,45 @@ firsttermFOSS/firstterm, firsttermF/OSS/firstterm, and firsttermFLOSS/firstterm. Let's start by sorting those out, along with a few other terms./para +-- + +para +オープンソースライセンスについて議論するときにまず明らかになることは、 +同じ意味を持つ異なる単語がたくさんあるらしいということです。 +たとえば firsttermフリーソフトウェア/firstterm、 +firsttermオープンソース/firstterm、firsttermFOSS/firstterm、 +firsttermF/OSS/firstterm、そして firsttermFLOSS/firstterm です。 +ここでは、そうした用語を他の言葉と一緒に整理することにしましょう。 +/para variablelist + !-- varlistentrytermfirsttermfree software/firstterm/term -listitemparaSoftware that can be freely shared and modified, + -- + varlistentrytermfirsttermフリーソフトウェア/firstterm/term + +listitem + !-- + paraSoftware that can be freely shared and modified, including in source code form. The term was first coined by Richard Stallman, who codified it in the GNU General Public License (GPL), and who founded the Free Software Foundation (ulink url=http://www.fsf.org//) to promote the concept./para + -- + para + ソースコードを自由に共有し、 + かつ変更を加えることができるソフトウェアのことです。 + この用語は リチャード・ストールマン がはじめに作り、 + GNU General Public Licence (一般公衆利用許諾契約書、 + 以下 GPL) に盛り込みました。 + そして Free Software Foundation (フリーソフトウェア財団、 + 以下 FSF、ulink url=http://www.fsf.org//) + を設立してこの概念を広めたのです。 + /para + + !-- paraAlthough free software covers almost exactly the same range of software as open source, the FSF, among others, prefers the former term because it emphasizes @@ -68,12 +101,36 @@ in English have their own ambiguities. (Throughout this book, free is used in the freedom sense, not the zero-cost sense.)/para + -- + + para + 「フリーソフトウェア」という用語は、 + ソフトウェア の範疇では「オープンソース」とほとんど同じ意味です。 + しかし、とりわけ FSF は前者を好みます。なぜなら、 + 「フリーソフトウェア」の方が、自由という考え方や、 + 技術的な流行ではなくて何より社会運動としての、 + 自由に再配布可能なソフトウェア、 + という考えを強調しているからです。 + FSF は、「フリー」という単語が mdash; 「自由」ではなく、 + 「コストがかからない」、と解釈され得るという意味で + mdash; 曖昧なものだと認めています。 + しかしながら色々考えてみて、 + フリーという単語がやはり一番だと考えていますし、 + 他の英単語にも曖昧な部分があるとも考えています。 + (本書では、「フリー」という単語を「コストがかからない」という意味ではなく、 + 「自由」という意味で使っています。) + /para /listitem /varlistentry + !-- varlistentrytermfirsttermopen source software/firstterm/term + -- + varlistentrytermfirsttermオープンソースソフトウェア/firstterm/term -listitemparaFree software under another name. But the +listitem + !-- + paraFree software under another name. But the different name reflects an important philosophical difference: open source was coined by the Open Source Initiative (ulink url=http://www.opensource.org//) @@ -83,7 +140,20 @@ methodology rather than a political movement. They may also have wanted to overcome another stigma: that anything free must be low quality./para + -- + + para + フリーソフトウェア の別名です。しかしながら、 + この名前の違いは重要な哲学の違いを反映しています。 + 「オープンソース」という単語は、Open Source Initiative + (オープンソース・イニシアティブ、以下 OSI。 ulink url
[ProducingOSS commit] r1562 - trunk/ja
Author: mumumu Date: Fri Nov 7 14:43:48 2008 New Revision: 1562 Log: - r1561 translation tweaks. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Fri Nov 7 14:43:48 2008 @@ -238,7 +238,7 @@ (訳注: フランス語で「自由」) という単語は、 多くの言葉に存在していながら、「フリー」が持つ曖昧な意味がありません。 詳しくは ulink url=http://en.wikipedia.org/wiki/FLOSS/ - を参照してください。 + を参照してください。) /para !-- @@ -384,7 +384,7 @@ varlistentrytermfirsttermproprietary/firstterm, firsttermclosed-source/firstterm/term -- - varlistentrytermfirsttermプロプラエタリ/firstterm, + varlistentrytermfirsttermプロプラエタリ/firstterm、 firsttermクローズドソース/firstterm/term listitem @@ -403,7 +403,7 @@ 「フリー」や「オープンソース」とは反対の意味です。 コピーひとつ毎にお金を支払うか、 オープンソースの力学を妨げるのに充分制限的な条件を適用した、 - 伝統的なロイヤリティベースのライセンスで配布されるソフトウェアのもとです。 + 伝統的なロイヤリティベースのライセンスで配布されるソフトウェアのことです。 無料で配布されるソフトウェアでも、 ライセンスが自由な改変や再配布を認めていない場合には、 プロプラエタリなソフトウェアになり得ます。 @@ -460,7 +460,7 @@ 「firstterm商用の/firstterm」 という言葉が、 「プロプラエタリ」の別名として使われることがあります。 しかし、正確に言うと、これらは同じではありません。 - フリーソフトウェアも商用のソフトウェアにすることができます。 + フリーソフトウェアも商用にすることができます。 結局、買う人がコピーする権利を制限しない限り、 フリーソフトウェアは売ることもできるのです。 フリーソフトウェアは他のやり方、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1560 - trunk/ja
Author: mumumu Date: Thu Nov 6 03:43:09 2008 New Revision: 1560 Log: - fixed Japanese Keigo. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Thu Nov 6 03:43:09 2008 @@ -2110,10 +2110,10 @@ もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか -を覚えていたし、問題を乗り越えてきていたので、どう人に説明すればいいかを分か -っていました。このため、彼が書いたドキュメントは、彼自身が理解できなかった部 -分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」もの -として見逃していた部分も網羅できていたのです。 +を覚えていましたし、問題を乗り越えてきていたので、どう人に説明すればいいかを +分かっていました。このため、彼が書いたドキュメントは、彼自身が理解できなかっ +た部分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」 +ものとして見逃していた部分も網羅できていたのです。 もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は 自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1551 - trunk/ja
Author: mumumu Date: Sun Nov 2 09:15:17 2008 New Revision: 1551 Log: - translated Documentation and Usability section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 09:15:17 2008 @@ -2016,15 +2016,27 @@ !-- subsection === -- sect2 id=subsidize-documentation-usability +!-- titleDocumentation and Usability/title +-- +titleドキュメントやユーザビリティの改善/title +!-- paraDocumentation and usability are both famous weak spots in open source projects, although I think, at least in the case of documentation, that the difference between free and proprietary software is frequently exaggerated. Nevertheless, it is empirically true that much open source software lacks first-class documentation and usability research./para +-- + +para +ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として有名ですが、 +私は少なくともドキュメントについては、プロプラエタリなソフトウェアとの違いが誇張されていると思っています。 +とは言っても経験上は、素晴らしいドキュメントやユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。 +/para +!-- paraIf your organization wants to help fill these gaps for a project, probably the best thing it can do is hire people who are emphasisnot/emphasis regular developers on the project, but @@ -2034,17 +2046,46 @@ closest to the software are usually the wrong people to write documentation or investigate usability anyway, because they have trouble seeing the software from an outsider's point of view./para +-- + +para +あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、 +プロジェクトの開発者ではemphasisなく/emphasis、 +彼らと建設的に話ができる人を雇うとよいでしょう。 +プロジェクトの開発者を雇わない方がよい理由はふたつあります。 +ひとつは、プロジェクトから離れてしまうと開発する時間がとれなくなること。 +もうひとつは、対象となるソフトウェアにあまりにも距離が近い人は、 +第3者の視点からそれを眺めるのが難しいために、 +ドキュメントを書いたりユーザビリティを調べるのに普通向いていないからです。 +/para +!-- paraHowever, it will still be necessary for whoever works on these problems to communicate with the developers. Find people who are technical enough to talk to the coding team, but not so expert in the software that they can't empathize with regular users anymore./para +-- +para +しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。 +彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておらず、 +普通のユーザーに感情移入できる人を探しましょう。 +/para + +!-- paraA medium-level user is probably the right person to write good documentation. In fact, after the first edition of this book was published, I received the following email from an open source developer named Dirk Reiners:/para +-- +para +中級者レベルのユーザが、ドキュメントを書くのに多分向いているでしょう。 +実際、この本の第1版が世に出たあと、 +私は Dirk Reiner というオープンソースソフトウェアの開発者から次のようなメールを受け取っています。 +/para + +!-- screen One comment on Money::Documentation and Usability: when we had some money to spend and decided that a beginner's tutorial was the most @@ -2060,6 +2101,27 @@ many people, which is something that was just a lucky occurrence and is probably hard to get in most cases. /screen +-- + + + +screen +「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。 +もし人に支払えるだけのお金があって、 +もっとも必要となっているのが初心者向けのチュートリアルだという話になった場合、 +私が実際に雇ったのは中級者レベルのユーザーだった。 +彼はシステムに関する研修を最近受けたので、 +何が問題になるのかを覚えているし、問題を乗り越えてきているので、 +どう人に説明すればいいかを分かっていた。 +このため、彼が書いたドキュメントは、彼自身が理解できなかった部分については、 +開発者がちょっと修正すればよかったし、 +開発者が「自明な」ものとして見逃していた部分も網羅できていた。 + +もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することだったので、 +彼は自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、 +たまたまうまくできたこと、をうまく組み合わせることができた。 +よって、彼が書いたドキュメントはさらに素晴らしいものになっていた。 +/screen /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1553 - trunk/ja
Author: mumumu Date: Sun Nov 2 10:40:16 2008 New Revision: 1553 Log: - translated Providing Hosting/Bandwidth section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 10:40:16 2008 @@ -1752,7 +1752,7 @@ !-- titleQuality Assurance (i.e., Professional Testing)/title -- -title品質保証 (テストの専門家など) を支援する/title +title品質保証 (テストの専門家など)/title !-- paraIn proprietary software development, it is normal to have teams @@ -2125,8 +2125,12 @@ !-- subsection === -- sect2 id=subsidize-hosting +!-- titleProviding Hosting/Bandwidth/title +-- +titleホスティングサイトや接続回線を提供する/title +!-- paraFor a project that's not using one of the free canned hosting sites (see xref linkend=canned-hosting/phrase output=printed in @@ -2137,7 +2141,20 @@ moderately effective way to obtain good public relations karma, though it will not bring any influence over the direction of the project./para +-- + +para +一通りのツールが揃ったホスティングサイト (phrase output=printed +xref linkend=technical-infrastructure/ の /phrase xref linkend=canned-hosting/ を参照してください) を使っていないプロジェクトに対して、 +サーバーやネットワーク接続を提供mdash; +もっとも重要なのはシステム管理を手助けすることですがmdash;すると、 +プロジェクトが大いに助かる可能性があります。 +たとえそれがあなたの組織ができる全てであったとしても、 +世間的に良い評価を得るためにそれなりの手段になることでしょう。 +ただ、プロジェクト全体の方向性に影響を与えることはできませんが。 +/para +!-- paraYou can probably expect a banner ad or an acknowledgment on the project's home page, thanking your company for providing hosting. If you set up the hosting so that the project's web address is under your @@ -2145,7 +2162,7 @@ just through the URL. This will cause most users to think of the software as having emphasissomething/emphasis to do with your company, even if you don't contribute to development at all. The -problem is, the developers are aware of this associative tendency too, + problem is, the developers are aware of this associative tendency too, and may not be very comfortable with having the project in your domain unless you're contributing more resources than just bandwidth. After all, there are a lot of places to host these days. The community may @@ -2154,6 +2171,29 @@ So if you want to provide hosting, do somdash;but either plan to get even more involved soon, or be circumspect about how much involvement you claim./para +-- + + +para +ホスティングサイトを提供していることに感謝の意を表すために、 +プロジェクトのホームページにお礼の言葉を載せてもらったり、 +バナー広告を貼らせてもらえることが期待できます。 +ホスティングの設定にあたって、プロジェクトのURLをあなたの企業のドメイン内に設定した場合、 +URLだけでプロジェクトとあなたの企業が関係があることを理解してもらえるでしょう。 +これによって、あなたの企業が開発に全く貢献していなくても、 +ほとんどのユーザーが emphasis何かしらの/emphasis 関係があると看做すようになります。 +問題は、ユーザーがそう考えることに開発者も気づくため、 +ホスティングサイトやネットワーク回線以外の開発リソースを提供しなければ、 +あなたのドメイン内にプロジェクトを置くことにあまりいい感情を持たない可能性があることです。 +何だかんだ言っても、最近はたくさんのホスティングサイトがあります。 +コミュニティは結局、実態に見合わないクレジットを与えるのは、 +ホスティングを提供してもらう利点に見合わないと感じて、 +プロジェクトを他に移してしまうでしょう。 +よって、あなたがホスティングサイトを提供したいなら、そうすると良いでしょうmdash; +但し、すぐにもっと積極的にプロジェクトに関わるプランを示すか、 +自分の主張がどれくらいプロジェクトに影響を与えられるかについて、 +よく考える必要があります。 +/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1554 - trunk/ja
Author: mumumu Date: Sun Nov 2 12:24:45 2008 New Revision: 1554 Log: - translated the introduction of Marketing section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 12:24:45 2008 @@ -2201,8 +2201,12 @@ !-- SECTION == -- sect1 id=marketing +!-- titleMarketing/title +-- +titleマーケティング/title +!-- paraAlthough most open source developers would probably hate to admit it, marketing works. A good marketing campaign emphasiscan/emphasis create buzz around an open source product, @@ -2216,6 +2220,20 @@ such an effort; see also xref linkend=publicity/phrase output=printed in xref linkend=communications//phrase./para +-- + +para +ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、 +マーケティングは役に立つものです。マーケティング活動をうまくやれば、 +頭の固いプログラマーが理由がよくわからないのに、 +そのソフトウェアに対して良い印象を持つ位にまで、 +オープンソース界隈の評判を作り出すことがemphasisできます/emphasis。 +ここでは、マーケティングにおける競争力学を一般的に分析するわけではありません。 +フリーソフトウェアの世界に関わっている企業は結局、企業自体や、ソフトウェア、 +そしてソフトウェアと企業の関係をどうやって売り込んでいくか、考えるようになります。 +以下では、こうした努力をするにあたって陥りがちな一般的な落とし穴について解説します。 +phrase output=printedxref linkend=communications/ の /phrase xref linkend=publicity/ も参照してください。 +/para !-- subsection == -- sect2 id=goldfish-bowl ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1557 - trunk/ja
Author: mumumu Date: Sun Nov 2 17:41:08 2008 New Revision: 1557 Log: - translated Remember That You Are Being Watched section. - Chapter 5 translation complete!! Only chapter 9 is left. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 17:41:08 2008 @@ -2225,30 +2225,41 @@ para ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、 マーケティングは役に立つものです。マーケティング活動をうまくやれば、 -頭の固いプログラマーが理由がよくわからないのに、 -そのソフトウェアに対して良い印象を持つ位にまで、 +頭の固いプログラマーが理由もよくわからないのに、 +そのソフトウェアに対して良い印象を持つくらいにまで、 オープンソース界隈の評判を作り出すことがemphasisできます/emphasis。 ここでは、マーケティングにおける競争力学を一般的に分析するわけではありません。 フリーソフトウェアの世界に関わっている企業は結局、企業自体や、ソフトウェア、 -そしてソフトウェアと企業の関係をどうやって売り込んでいくか、考えるようになります。 +そしてソフトウェアと企業の関係をどうやって売り込んでいくか、を考えるようになります。 以下では、こうした努力をするにあたって陥りがちな一般的な落とし穴について解説します。 phrase output=printedxref linkend=communications/ の /phrase xref linkend=publicity/ も参照してください。 /para !-- subsection == -- sect2 id=goldfish-bowl -titleRemember That You Are Being Watched/title !-- -title見られていることを意識する/title +titleRemember That You Are Being Watched/title -- +title見られていることを意識する/title +!-- paraFor the sake of keeping the volunteer developer community on your side, it is emphasisvery/emphasis important not to say anything that isn't demonstrably true. Audit all claims carefully before making them, and give the public the means to check your claims on their own. Independent fact checking is a major part of open source, and it applies to more than just the code./para +-- + +para +ボランティアの開発者コミュニティーをあなたの味方に付けるには、 +はっきりしていない事柄は喋らないことが emphasisとても/emphasis 重要です。 +すべての主張を公にする前に注意深く調べ、その主張自体をチェックする手段も公にしておきます。 +独自に事実を検証できるのは、オープンソースの重要な部分です。 +それはコード以外の部分にも当てはまります。 +/para +!-- paraNaturally no one would advise companies to make unverifiable claims anyway. But with open source activities, there is an unusually high quantity of people with the expertise to verify @@ -2258,7 +2269,7 @@ Megacorp Chemical Industries pollutes a stream, that's verifiable, but only by trained scientists, who can then be refuted by Global Megacorp's scientists, leaving the public scratching their heads and -wondering what to think. On the other hand, your behavior in the open +wondering what to think. On the other hand, your behavior in the open source world is not only visible and recorded; it is also easy for many people to check it independently, come to their own conclusions, and spread those conclusions by word of mouth. These communications @@ -2266,14 +2277,47 @@ operates, and they can be used to transmit any sort of information. Refutation is usually difficult, if not impossible, especially when what people are saying is true./para +-- + +para +当然のことながら、検証できない主張をするなと企業にアドバイスする人などいません。 +しかし、ことオープンソースの活動においては、 +主張を検証する経験に長けた人が非常に多くいますmdash; +なぜなら、広い帯域のインターネット接続回線を持ち、 +物事を中傷するために社会的接触を持つ可能性がある人が大勢いるからです。 +化学工業の巨大企業が川を汚染している場合、それは検証可能ですが、 +検証できるのは訓練を受けた科学者のみです。 +彼らは巨大企業の科学者から反論され、 +頭をかきむしってどう考えたらよいのか困惑するかもしれません。 +一方で、オープンソースの世界であなたがすることは、 +目に見える形で記録されるだけではありません。多くの人が独立してチェックし、 +独自の結論を下し、それらを口コミで広めていくのです。 +この口コミのネットワークは既に定着しているものです。つまり、 +オープンソースがどのように影響するかを決める要素であり、 +あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにしても、 +特に人々が言っていることが事実である場合は、普通難しいものです。 +/para +!-- paraFor example, it's okay to refer to your organization as having founded project X if you really did. But don't refer to yourself as the makers of X if most of the code was written by outsiders. Conversely, don't claim to have a deeply involved volunteer developer community if anyone can look at your repository and see that there are few or no code changes coming from outside your organization./para +-- +para +たとえば、プロジェクトXを作った とあなたの組織が言うのは、 +実際にそうしたのであれば問題ありません。しかし、 +実際にコードを書いたのが外部の人間である場合、 +Xというソフトウェアを作った と言ってはいけません。 +逆に、誰かがリポジトリの中身を覗いてみて、 +あなたの組織以外の人が変更を加えた跡が殆どまたは全くない場合は、 +ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。 +/para + +!-- paraNot too long ago, I saw an announcement by a very well-known computer company, stating that they were releasing an important software package under an open source license. When the initial @@ -2284,16 +2328,46 @@ worryingmdash;they'd just made the announcement, after all. There was no reason to expect a lot of development activity right away./para +-- +para +それほど昔のことではありませんが、 +とてもよく知られているコンピューター会社が、 +重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、 +というアナウンスを見ました。はじめのアナウンスが出た後、 +私は公開されているバージョン管理システムのリポジトリを見てみましたが、 +そこには3つのリビジョンしか存在していませんでした。 +言い換えれば、彼らはソースコードのインポートを終えたこと以外は何もしていなかったのです。 +それ自体は変な事ではありませんでした。mdash; +だって結局彼らはアナウンスしただけですから。 +しかし、すぐに活発な開発が行われると期待する理由は何もなかったのです。 +/para + +!-- paraSome time later, they made another announcement. Here is what it said, with the name and release
[ProducingOSS commit] r1558 - trunk/ja
Author: mumumu Date: Sun Nov 2 17:49:06 2008 New Revision: 1558 Log: - r1551 translation tweaks. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Nov 2 17:49:06 2008 @@ -2108,17 +2108,17 @@ screen 「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。 もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの -チュートリアルだという話になった場合、私が実際に雇ったのは中級者レベルのユー -ザーだった。彼はシステムに関する研修を最近受けたので、何が問題になるのかを覚 -えていたし、問題を乗り越えてきているので、どう人に説明すればいいかを分かって -いた。このため、彼が書いたドキュメントは、彼自身が理解できなかった部分につい -ては、開発者がちょっと修正すればよかったし、開発者が「自明な」ものとして見逃 -していた部分も網羅できていた。 +チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー +ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか +を覚えていたし、問題を乗り越えてきていたので、どう人に説明すればいいかを分か +っていました。このため、彼が書いたドキュメントは、彼自身が理解できなかった部 +分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」もの +として見逃していた部分も網羅できていたのです。 -もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することだったので、彼は自 -分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたまう -まくできたこと、をうまく組み合わせることができた。 -よって、彼が書いたドキュメントはさらに素晴らしいものになっていた。 +もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は +自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま +うまくできたこと、をうまく組み合わせることができました。 +よって、彼が書いたドキュメントはさらに素晴らしいものになっていたのです。 /screen /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1559 - trunk/ja
Author: mumumu Date: Sun Nov 2 20:14:32 2008 New Revision: 1559 Log: - translated introduction of 9. Licenses, Copyrights, and Patents. Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml == --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Sun Nov 2 20:14:32 2008 @@ -1,9 +1,12 @@ chapter id=legal - +!-- titleLicenses, Copyrights, and Patents/title +-- +titleライセンス、著作権、そして特許/title simplesect +!-- paraThe license you select probably won't have a major impact on the adoption of your project, as long as the license is open source. Users generally choose software based on quality and features, not on @@ -14,6 +17,20 @@ that I am not a lawyer, and that nothing in this chapter should be construed as formal legal advice. For that, you'll need to hire a lawyer or be one./para +-- + +para +あなたが選ぶライセンスは、それがオープンソースである限り、 +プロジェクトで採用するにあたって大きな影響を与えないはずです。 +ユーザーは、ソフトウェアを機能や質で選ぶことが一般的で、 +ライセンスの詳細に基づいて選んだりはしません。それでも、 +プロジェクトが採用するライセンスが目的に確実に合ったものにすることと、 +ライセンスに関する決定を他の人と議論できるようするために、 +フリーソフトウェアのライセンス問題に関する基本的なことがらは、 +やはり理解する必要があります。しかしながら私は法律家ではないですし、この章の内容も、 +法的なアドバイスを正式に受けて書いているわけではないことに注意してください。 +そうするには、法律家を雇うか、あなた自身が法律家になる必要があるでしょう。 +/para /simplesect ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1546 - trunk/ja
Author: mumumu Date: Mon Oct 27 18:40:39 2008 New Revision: 1546 Log: - punctuation mark tweaks. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Mon Oct 27 18:40:39 2008 @@ -1924,8 +1924,8 @@ テストチームと直接話をする機会に繋がります。 たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、 開発者はスケーラビリティに関するバグ (これをテストするリソースを彼らは持たない場合があります) を修正する作業に注力でき、 -その修正が望ましい結果を出しているかどうかを検証するようにバグ追跡システム上にコメントすることで, -テストチームに頼むことができます。 +その修正が望ましい結果を出しているかどうかを検証するよう、 +バグ追跡システム上にコメントすることでテストチームに頼むことができます。 開発者から多少の抵抗があることは覚悟しておいて下さい。 プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。 テストチームが重要なバグを発見し、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1523 - trunk/ja
Author: mumumu Date: Sat Oct 18 13:37:10 2008 New Revision: 1523 Log: - added conventions if japanese translators should add ー to some word. Modified: trunk/ja/conventions.txt Modified: trunk/ja/conventions.txt == --- trunk/ja/conventions.txt(original) +++ trunk/ja/conventions.txtSat Oct 18 13:37:10 2008 @@ -1,6 +1,14 @@ Producing Open Source Software 翻訳用語集 -翻訳の際、以下の単語については、訳語を統一する。 + +1) 翻訳の際、以下の単語については、訳語を統一する。 Bug Tracking - バグ追跡 Bug Tracker - バグ追跡システム +2) 基本的に、「ー」を付けるか否か迷う単語は、 +「ー」を付ける方向で統一する。 + +例： +maintainer - メンテナー +committer - コミッター + ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1524 - trunk/ja
Author: mumumu Date: Sat Oct 18 13:43:20 2008 New Revision: 1524 Log: - added reference url for convention supplement. Modified: trunk/ja/conventions.txt Modified: trunk/ja/conventions.txt == --- trunk/ja/conventions.txt(original) +++ trunk/ja/conventions.txtSat Oct 18 13:43:20 2008 @@ -5,8 +5,10 @@ Bug Tracking - バグ追跡 Bug Tracker - バグ追跡システム -2) 基本的に、「ー」を付けるか否か迷う単語は、 -「ー」を付ける方向で統一する。 +2) 基本的に、「ー」を付けるか否か迷うカタカナ単語は +長音表記にする(「ー」を付ける)方向で統一する。 + +参考：http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3491 例： maintainer - メンテナー ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1504 - trunk/ja
Author: mumumu Date: Sun Sep 28 15:16:12 2008 New Revision: 1504 Log: - translated Review and Acceptance of Changes section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Sep 28 15:16:12 2008 @@ -1557,8 +1557,12 @@ /para sect2 id=community-review-acceptance +!-- titleReview and Acceptance of Changes/title +-- +titleレビューを行い、変更をソースコードに取り入れる/title +!-- paraThe community is still important to the success of contract work. Their involvement in the design and review process for sizeable changes cannot be an afterthought. It must be considered part of the @@ -1566,6 +1570,17 @@ scrutiny as an obstacle to be overcomemdash;think of it as a free design board and QA department. It is a benefit to be aggressively pursued, not merely endured./para +-- + +para +契約して仕事をうまく遂行するために、コミュニティが果たす役割は依然として重要です。 +変更の規模が大きい機能設計やレビューの過程に、コミュニティが後付けで関わることはできません。 +コミュニティが参加するのは仕事の一部でなければなりませんし、 +これは仕事を受ける人も必ず受け入れなければなりません。 +コミュニティが関わることが仕事の邪魔になると考えないでください mdash; +コミュニティを仕事とは独立した設計や品質保証の部署として捉えるようにしましょう。 +コミュニティが関わるのを我慢するのではなく、利益になることとして強く追求すべきです。 +/para sect3 id=cvs-pserver titleCase study: the CVS password-authentication protocol/title ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1502 - trunk/ja
Author: mumumu Date: Sat Sep 27 17:13:03 2008 New Revision: 1502 Log: - translated Contracting Section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat Sep 27 17:13:03 2008 @@ -1263,7 +1263,7 @@ プロジェクトにカネを出す人が、他の人と同じルールを守る必要があることは、 誰かがカネを出す場合に優しい独裁者モデル (phrase output=printedxref linkend=social-infrastructure/ の/phrase xref linkend=benevolent-dictator/ を参照してください) -がちょっとうまくいきにくいことを意味しています。 +がちょっと機能しにくいことを意味しています。 優しい独裁者がプロジェクトに一番カネを出している場合は特にそうでしょう。 独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、 プロジェクトにカネを出している人がコミュニティのルールを守っていると証明することは困難です。 @@ -1277,8 +1277,9 @@ !-- subsection == -- sect1 id=contracting -titleContracting/title +title契約する/title +!-- paraContracted work needs to be handled carefully in free software projects. Ideally, you want a contractor's work to be accepted by the community and folded into the public distribution. In theory, it @@ -1293,7 +1294,26 @@ contractor is paid by the hour, you may end up paying more than you expected; if he is paid a flat sum, he may end up doing more work than he can afford./para +-- + +para +契約は、フリーソフトウェアの世界では注意深く扱う必要があります。 +理想を言えば、契約を結んで作業した人の成果物がコミュニティに受け入れられ、 +公のリリースに取り込まれるのが望ましいです。理屈の上では、 +成果物の品質が良く、それがプロジェクトのガイドラインを満たしている限り、 +誰と契約しようと問題ありません。この理屈と実践は一致することもありますし、 +そうでないこともあります。 +つまり、品質が良い修正プログラムなら、それが全く知らない人が書いたものであっても、 +一般的にはソフトウェアに取り込むことが emphasisできる/emphasis ということです。 +困るのは、重要な改良や新機能の追加を行う良質の修正プログラムを全く知らない人に作ってもらうのはとても難しいということです。 +作業を請け負う人は、プロジェクトでまず議論してもらわないといけません。 +議論が行われる期間は正確に予測できません。 +もしあなたが時給単位でお金を払っているのなら、 +予想以上のお金を支払うことになるかもしれません。 +逆に固定給であれば、その人は貰う金額に見合わない量の仕事をする羽目になるかもしれません。 +/para +!-- paraThere are two ways around this. The preferred way is to make an educated guess about the length of the discussion process, based on past experience, add in some padding for error, and base the contract @@ -1316,7 +1336,33 @@ regarding code changes, the contract can reference those standards and specify that the work must meet them. In practice, this usually works out the way everyone hopes./para +-- + +para +この問題に対処する方法がふたつあります。望ましいのは、 +過去の経験に照らして議論にかかる時間を推測し、誤差を少し足しておきます。 +その値に基づいて契約するのです。 +これは、問題を独立した多くの小さな断片にできるだけ分割し、 +それぞれの断片の予測可能性を増やすのにも役立ちます。別のやり方として、 +修正プログラムだけを作ってもらう契約を交わし、 +それを公のプロジェクトに取り込んでもらうことを別の問題として扱う方法があります。 +こうすると契約書を書くのは楽になりますが、 +あなたがプロジェクトに依存する間、 +またはそれと同様の機能をプロジェクトの本流に取り込んでもらうまでの間、 +契約で作られた修正プログラムを維持するのに四苦八苦することになります。 +もちろん、前者の望ましい方法をとったとしても、 +修正プログラムが取り込まれることを契約の条件には出来ません。 +なぜなら、これは状況によっては売っていないものを売ってしまうことになるからです。 +(もし、プロジェクトが対象となる機能をサポートしないと決めたらどうなるでしょう？) +しかしながら、変更をコミュニティに受け入れてもらい、 +彼らが承知すればそれをリポジトリにコミットしてもらえるよう、 +foreignphrase誠意をもって/foreignphrase 努力することを契約の条件にすることはできます。 +たとえば、プロジェクトがコード変更に関する基準を持っている場合は、 +契約でそうした基準を参照した上で、成果物はそれを満たすように取り決めることができます。 +実際、このやり方で契約の当事者全員が望む結果が普通は出てきます。 +/para +!-- paraThe best tactic for successful contracting is to hire one of the project's developersmdash;preferably a committermdash;as the contractor. This may seem like a form of purchasing influence, and, @@ -1341,12 +1387,50 @@ review the code, both of which can be very useful. For all these reasons, the contractor is best drawn from the ranks of those already involved with the project./para +-- + +para +契約を成功させるために最も良い戦略は、プロジェクトの開発者を雇うことです +mdash; 契約の相手としてはコミッタが望ましいです。 +これは影響力を買っているように見えますし、実際そうですが、 +見た目ほど破綻しているわけではありません。 +プロジェクトの開発者は、主にコードの質が高いことと、 +他の開発者との交流しているからこそ、影響力を持っているのです。 +開発者があることを成し遂げる契約をしたからといって、 +彼のそうした地位を高めることにはなりませんし、傷つけることもありません。 +ただ、契約をすることで、周囲の人が彼のことをあれこれ詮索するようになるかもしれません。 +ほとんどの開発者は、不適切、または多くの人が嫌っている新機能の導入を支援することで、 +長い時間かけて築いてきたプロジェクト内での地位を危険に晒したりはしません。 +そういう目的で実際に開発者を雇うとき、 +どういう変更がコミュニティに受け入れられやすいかについて、あなたはアドバイスを貰うはずです。 +また、プロジェクト内の優先順位をわずかながら変更させることになります。 +プロジェクト内の優先順位付けは、開発者が何に時間を掛けるかの問題にすぎないので、 +開発者の時間を契約で買うとすると、彼の仕事の優先度が少し変わることになるからです。 +これは経験を積んだオープンソースプロジェクトの開発者にとって避け難い現実ですし、 +雇い主が課す仕事を単にそれが emphasis先に片付けられそう/emphasis だという理由だけで、 +それだけに注意を向ける開発者も少なからずいます。 +彼らはその仕事を早く片付ける後押しをしてくれます。 +彼らは全くコードを書かず、設計について議論したり、 +コードをレビューしたりしているだけかもしれませんが、これらはとても役に立つものです。 +これまで述べてきたすべての理由から、契約相手になる開発者は、 +プロジェクトに既に参加している人をランク付けして選ぶのが一番よいのです。 +/para +!-- paraThis immediately raises two questions: Should contracts ever be private? And when they're not, should you worry about creating tensions in the community by the fact that you've contracted with some developers and not others?/para +-- + +para +プロジェクトの開発者を雇うとすると、疑問が二つ出てきます。 +契約を公にしない方がいいのでしょうか？ また、仮に公にするとして、 +特定の開発者以外の人と契約しないことで、 +コミュニティに緊張関係を作ってしまうことを気にかけるべきなのでしょうか。 +/para +!-- paraIt's best to be open about contracts, when you can. Otherwise, the contractor's behavior may
[ProducingOSS commit] r1485 - trunk/ja
Author: mumumu Date: Sat Aug 9 18:55:30 2008 New Revision: 1485 Log: - translation tweaks in r1484. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat Aug 9 18:55:30 2008 @@ -1035,9 +1035,9 @@ あなたがカネを貰って雇われている開発者なら、 カネで買えるものと買えないものに関する基準を早い段階から設定するようにしましょう。 これは、あなたの気高くて侵し得ない性分について、 -1日に2回はメーリングリストに繰り返し投稿することではありません。 +1日に2回メーリングリストに繰り返し投稿することではありません。 カネが作り出す emphasis可能性がある/emphasis 葛藤を鎮める機会を探っておくべき、 -というだけです。そういった葛藤が既にあるものとして考える必要はありませんが、 +というだけです。そういった葛藤が既にあるものと考える必要はありませんが、 カネによってそういうことが起きるかもしれない、ということを認識しておく必要はあります。 /para @@ -1055,7 +1055,7 @@ para そういった葛藤の良い例が Subversion プロジェクトで起こりました。 -Subversion は、プロジェクト開始時からのカネを出していて、 +Subversion は、プロジェクト開始時からカネを出していて、 何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払っていた ulink url=http://www.collab.net/;CollabNet/ulink が始めたものです。 プロジェクトが始まってすぐ、CollabNet は Mike Pilato という別の開発者を雇いました。 彼を雇うまでに、コーディングは既に始まっていました。 @@ -1134,7 +1134,7 @@ para こうした理由から、Mike は 他のボランティアの開発者と同様に、 コミット権限がない状態で CollabNet での仕事を始めることに同意しました。 -彼は公のメーリングリストに修正プログラムを送り、 +彼は公のメーリングリストに修正プログラムを送りました。 それはプロジェクトのメンバ全員でレビューできる状態にありましたし、 また現にレビューされました。 CollabNet は メーリングリスト上で、 @@ -1233,10 +1233,10 @@ -- para -(コミット権限に関する似たような話として、Danese Cooper のブログを見るとよいでしょう。 -ulink url=http://blogs.sun.com/roller/page/DaneseCooper/20040916/ +(コミット権限に関する似たような話として、Danese Cooper のブログエントリ +ulink url=http://blogs.sun.com/roller/page/DaneseCooper/20040916/ を見るとよいでしょう。 Cooper は そのとき サン・マイクロシステムズ の オープンソースの部署 にいました mdash; -私はそれが彼女の公の肩書きだと思っていました mdash; このブログエントリでは、 +それが彼女の公の肩書きだと思います mdash; このブログエントリでは、 Tomcat の開発コミュニティが、どのようにして自分たちと同じコミット権限に関する基準を サン・マイクロシステムズ に守らせたかについて説明しています。) /para @@ -1261,10 +1261,10 @@ para プロジェクトの創始者が、他の人と同じルールを守る必要があることは、 -誰かがお金を出す場合に優しい独裁者モデル(phrase output=printedxref linkend=social-infrastructure/ +誰かがカネを出す場合に優しい独裁者モデル (phrase output=printedxref linkend=social-infrastructure/ の/phrase xref linkend=benevolent-dictator/ を参照してください) がちょっとうまくいきにくいことを意味しています。 -優しい独裁者がプロジェクトの創始者である場合は特にそうでしょう。 +優しい独裁者がプロジェクトに一番カネを出している場合は特にそうでしょう。 独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、 プロジェクトの創始者がコミュニティのルールを守っていると証明することは困難です。 必ずしも不可能ではありませんが。それには、外部の開発者と同じ視点から物事を見ることができ、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1472 - trunk/ja
Author: mumumu Date: Sun Jun 22 19:09:59 2008 New Revision: 1472 Log: - translated Be Open About Your Motivations section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sun Jun 22 19:09:59 2008 @@ -776,8 +776,12 @@ !-- subsection == -- sect1 id=open-motives +!-- titleBe Open About Your Motivations/title +-- +title動機を隠し立てしない/title +!-- paraBe as open about your organization's goals as you can without compromising business secrets. If you want the project to acquire a certain feature because, say, your customers have been clamoring for @@ -787,7 +791,21 @@ development community knows about emphasiswhy/emphasis you want what you want, the more comfortable they'll be with whatever you're proposing./para +-- +para +あなたの組織がプロジェクトで目指していることを、できる限り隠さないようにしましょう。 +ただし、ビジネス上の秘密は漏らしてはいけませんが。 +たとえば、自分の顧客から強く要求されているという理由で、 +ある機能をプロジェクトに取り込んでもらいたいのであれば、 +メーリングリスト上で率直にそう言うようにしましょう。 +顧客から自分のことを秘密にしてほしいと頼まれることもありますが、 +その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。 +開発コミュニティがあなたがやりたいことの emphasis動機/emphasis を知れば知るほど、 +あなたが何を提案しても違和感がより少なくなります。 +/para + +!-- paraThis runs counter to the instinctmdash;so easy to acquire, so hard to shake offmdash;that knowledge is power, and that the more others know about your goals, the more control they have over you. @@ -800,7 +818,23 @@ will start to suspect a hidden agenda. But if you give just a few real-world scenarios showing why the proposed feature is important, that can have a dramatic effect on the debate./para +-- +para +これは、知識は力であり、他人が自分の目標を知れば知るほど多く干渉される、 +という直感に反するものです。 +mdash; 直感を受け入れるのは簡単ですが、取り除くのは難しいものです。 +しかし、ここではその直感は間違っています。 +新機能 (バグ修正でもなんでも) を公の場で主張することで、 +あなたは emphasis既に/emphasis カードをテーブルに置いているのです。 +その時点で唯一問題になるのは、目標を共有できるようにコミュニティを誘導できるかどうかです。 +仮に望むことだけを主張して、その理由となる具体例を述べなければ、 +その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。 +しかし、現実世界のシナリオを 2,3 述べ、提案している新機能がなぜ重要なのかを示すだけで、 +議論する上で劇的な効果があるのです。 +/para + +!-- paraTo see why this is so, consider the alternative. Too frequently, debates about new features or new directions are long and tiresome. The arguments people advance often reduce to I personally @@ -812,7 +846,20 @@ experience. Without some countervailing force, the end result is as likely as not to be determined by whoever was the most articulate, or the most persistent, or the most senior./para +-- +para +別の視点から考えてみましょう。新機能やプロジェクトの新しい方向性に関する議論は長く、 +退屈なものです。人々の主張は「個人的には X が欲しいんだよね」とか、 +もっとよくあるのは「ソフトウェア設計を長い間やってきたんだけど、 +X は ユーザにとってもの凄く重要だ / 誰も満足しない余計な飾りだよね」 +といったものになります。現実世界での使い方が示されていないと、 +議論の短縮や決着に繋がらないばかりか、実際のユーザ体験からは程遠い議論になってしまいます。 +そういった議論を止める力が働かない限り、行き着くところは結局何も決まらない、 +ということになりがちです。 +/para + +!-- paraAs an organization with plentiful customer data available, you have the opportunity to provide just such a countervailing force. You can be a conduit for information that might otherwise have no means of @@ -827,7 +874,23 @@ oxygen. As long as you present it right, they will welcome it enthusiastically, and it will propel things in the direction you want to go./para +-- +para +大量の顧客データを持つ組織として、あなたにはそういった議論を止めるチャンスがあります。 +他の人が開発コミュニティに伝えることができない情報へのパイプ役になれるのです。 +あなたが望むことをを支えている情報は恥ずかしいものでも何でもないのです。 +ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、 +広い見聞を持っているわけではありません。開発者はめいめいが、 +自分独自のやり方でソフトウェアを使っているのです。そして他の使い方については、 +直感や当て推量、そして本能に頼って作っていることを知っているのです。 +非常に多くのユーザの信頼できるデータを提供することで、 +あなたは開発コミュニティに酸素に似た何かを与えることになります。 +そうした情報を適切に示す限り、彼らは熱狂的にそれを受け入れるでしょうし、 +物事はあなたの望む方向に進むでしょう。 +/para + +!-- paraThe key, of course, is presenting it right. It will never do to insist that simply because you deal with a large number of users, and because they need (or think they need) a given feature, therefore @@ -835,7 +898,7 @@ initial posts on the problem, rather than on one particular solution. Describe in great detail the experiences your customers are encountering, offer as much analysis as you have available, and as -many reasonable solutions as you can think of. When people start +many reasonable solutions as you can think of. When people start speculating about the effectiveness of various solutions, you can continue to draw on your data to support or refute what they say. You may have one particular solution in mind all along, but don't single @@ -847,7 +910,30 @@ get behind it of their own free will, which is much better than you browbeating them into implementing it. (There is also the possibility that they will think of a better solution.)/para +-- + +para +鍵となるのは、もちろん情報を適切に示すことです。あなたが大量のユーザを抱えていたり、 +ユーザがある機能を必要としている (またはそう思っている) からといって、 +自分の解決策を実装すべきだと主張してもうまくいかないでしょう。 +むしろ、ある特定の解決策についてではなく、 +問題となっていることがらをはじめに投稿するとよいでしょう。 +あなたの顧客が経験していることを詳細に記し、できるだけ多く分
[ProducingOSS commit] r1468 - trunk/ja
Author: mumumu Date: Sat May 31 19:43:52 2008 New Revision: 1468 Log: - translated Appear as Many, Not as One section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat May 31 19:43:52 2008 @@ -687,8 +687,12 @@ !-- subsection == -- sect1 id=appear-as-many +!-- titleAppear as Many, Not as One/title +-- +title企業の人間としてではなく、個人として振る舞う/title +!-- paraYour developers should strive to appear in the project's public forums as individual participants, rather than as a monolithic corporate presence. This is not because there is some negative @@ -698,7 +702,19 @@ are structurally equipped to deal with. An individual contributor can have discussions, submit patches, acquire credibility, vote, and so forth. A company cannot./para +-- + +para +あなたが雇った開発者には、プロジェクトの公のフォーラムで一枚岩の企業の人間としてではなく、 +個人として振る舞ってもらうようにしましょう。 +これは企業が関わることでついてまわる否定的な意味合いがあるからではありません。 +(まぁ多分あるのでしょうが、それはこの本では触れません) +むしろ個人こそが、オープンソースプロジェクトが構造的に扱える唯一の存在だからです。 +個人の貢献者は、議論に参加したり、パッチを提出したり、信頼を得たり、 +投票するなどができますが、企業にはそれができません。 +/para +!-- paraFurthermore, by behaving in a decentralized manner, you avoid stimulating centralization of opposition. Let your developers disagree with each other on the mailing lists. Encourage them to @@ -706,18 +722,30 @@ anyone else's. Discourage them from always voting as a bloc, because if they do, others may start to feel that, just on general principles, there should be an organized effort to keep them in check./para +-- + +para +それ以上に、分散した個人として振る舞うことで、 +反感が一ヶ所に集中するのを避けることができます。あなたが雇った開発者には、 +メーリングリスト上でお互いが反目させるようにしてみましょう。 +彼らにお互いのコードを頻繁に、公の場で、赤の他人としてレビューさせるようにしましょう。 +そして、いつも徒党を組んで投票させないようにしましょう。なぜならそうしてしまうと、 +他の人が「こいつらは徒党を組んでいる」と感じますし、道徳的な見地から、 +彼らをチェックし続けるために組織的な努力がなされるべきだからです。 +/para +!-- paraThere's a difference between actually being decentralized and -simply striving to appear that way. Under certain circumstances, +simply striving to appear that way. Under certain circumstances, having your developers behave in concert can be quite useful, and they should be prepared to coordinate behind the scenes when necessary. For example, when making a proposal, having several people chime in with agreement early on can help it along, by giving the impression of -a growing consensus. Others will feel that the proposal has momentum, +a growing consensus. Others will feel that the proposal has momentum, and that if they were to object, they'd be stopping that momentum. Thus, people will object only if they have a good reason to do so. There's nothing wrong with orchestrating agreement like this, as long -as objections are still taken seriously. The public manifestations of +as objections are still taken seriously. The public manifestations of a private agreement are no less sincere for having been coordinated beforehand, and are not harmful as long as they are not used to prejudicially snuff out opposing arguments. Their purpose is merely @@ -725,6 +753,25 @@ shape; see xref linkend=bikeshed/phrase output=printed in xref linkend=communications//phrase for more about them./para +-- + +para +実際に個人として振る舞うことと、そうしようと単に努力することは違います。 +状況下によっては、雇った開発者達に一致した行動をとらせた方が便利なこともありますし、 +必要なときは裏で協力する準備をすべきでしょう。 +たとえば提案をするとき、合意が形成されつつあることを印象付けるために、 +何人かに早い段階から同意の意志を示してもらうようにします。 +他の人は、その提案に勢いがあると感じるでしょうし、仮に反対すれば、 +その勢いを削いでしまうだろうとも思うでしょう。 +よって、理由がある場合だけ、人々は反対するようになります。 +反対意見を真摯に受け止めている限り、賛成意見を組織化することは間違っていません。 +賛成意見を公の場で明らかにすることは、 +たとえそれが事前に協力していたとしても真摯である点は変わりませんし、 +反対意見を封殺するのに使われない限り、害はありません。 +彼らの目的は、単に体裁を保つためだけに反対したがる類の人を抑えることなのです。 +そういう人については、phrase output=printedxref linkend=communications//phrase の +xref linkend=bikeshed/ を参照してください。 +/para /sect1 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1460 - trunk/ja
Author: mumumu Date: Sun Apr 27 19:07:17 2008 New Revision: 1460 Log: - Translated Credit section. Modified: trunk/ja/ch08.xml Modified: trunk/ja/ch08.xml == --- trunk/ja/ch08.xml (original) +++ trunk/ja/ch08.xml Sun Apr 27 19:07:17 2008 @@ -3830,13 +3830,16 @@ !-- SECTION == -- sect1 id=credit -titleCredit/title +titleクレジット/title +!-- paraCredit is the primary currency of the free software world. Whatever people may say about their motivations for participating in a project, I don't know any developers who would be happy doing all their work anonymously, or under someone else's name. There are -tangible reasons for this: one's reputation in a project roughly +tangible reasons for this: + + one's reputation in a project roughly governs how much influence one has, and participation in an open source project can also indirectly have monetary value, because some employers now look for it on resumeacute;s. There are also @@ -3845,7 +3848,26 @@ recognized by others. The promise of credit is therefore one of best motivators the project has. When small contributions are acknowledged, people come back to do more./para +-- +para +クレジット(訳注：ある物事に対する貢献を明確にするため、貢献があった人物、 +団体、企業等の名前を明示すること) は、 +フリーソフトウェアの世界における通貨のようなものです。 +プロジェクトに参加する動機が何であれ、 +匿名や他人の名前で仕事をして喜んでいる開発者を私は知りません。 +これには明確な理由があります。 +プロジェクトで尊敬されているかどうかは、そこで行使できる影響力をも左右します。 +そして、オープンソースプロジェクトに参加していることを履歴書で評価する経営者もいるので、 +そのことが直接ではないにしろ開発者の市場価値に反映されるかもしれないからです。 +もっと明確で、説得力のある理由がもう一つあります。人は他人から評価されたいですし、 +無意識のうちに他人が自分の仕事をわかってくれる証を求めるからです。 +よって、クレジットはプロジェクトに対するもっとも強い動機付けのひとつになります。 +小さな貢献をプロジェクトが認めてくれると、 +認められた人はもっと大きな貢献をするために戻ってくるのです。 +/para + +!-- paraOne of the most important features of collaborative development software (see xref linkend=technical-infrastructure/) is that it keeps accurate records of who did what, when. Wherever possible, @@ -3854,14 +3876,27 @@ Don't just write Thanks to J. Random lt;[EMAIL PROTECTED]gt; if instead you can write Thanks to J. Random lt;[EMAIL PROTECTED]gt; for the bug report and reproduction recipe in a log message./para +-- +para +共同で開発するソフトウェア(xref linkend=technical-infrastructure/ を参照してください) +が持つ重要な特徴のひとつとして、誰がいつ、 +何をしたかを正確に記録していることがあげられます。 +可能ならいつも、この記録をクレジットを適切に記す目的に使うようにしましょう。 +そして、行った貢献の種類を明確にしておきましょう。 +ありがとう、J. Random lt;[EMAIL PROTECTED]gt; のような書き方はせず、 +バグ報告と再現手順を教えてくれた J. Random lt;[EMAIL PROTECTED]gt;、 +ありがとう と記すようにします。 +/para + +!-- paraIn Subversion, we have an informal but consistent policy of crediting the reporter of a bug in either the issue filed, if there is one, or the log message of the commit that fixes the bug, if not. A quick survey of Subversion commit logs up to commit number 14525 shows that about 10% of commits give credit to someone by name and email address, usually the person who reported or analyzed the bug fixed by -that commit. Note that this person is different from the developer +that commit. Note that this person is different from the developer who actually made the commit, whose name is already recorded automatically by the version control system. Of the 80-odd full and partial committers Subversion has today, 55 were credited in the @@ -3870,7 +3905,27 @@ factor in their continued involvement, but it at least sets up an atmosphere in which people know they can count on their contributions being acknowledged./para +-- +para +Subversion プロジェクトでは、記録されているバグ報告や、 +記録がなくてもコミットログに残っている報告者にクレジットを与えるやり方について、 +非公式ですが一貫したポリシーがあります。 +リビジョン 14525 までの Subversion のコミットログをざっと調査したところ、 +10%のコミットに対して名前と電子メールアドレスを記録するクレジットを与えていました。 +クレジットを与えられたのは、バグを報告したり、 +そのコミットで修正されたバグを分析したりした人であるのが普通です。 +クレジットを貰う人たちは、実際にコミットを行った開発者とは違いますし、 +開発者の名前はいつも自動的にバージョン管理システムに記録されていることに注意してください。 +Subversion プロジェクトでは、80数人のコミッターのうち55人が、 +自身がコミッターになる前に(通常は複数回)コミットログでクレジットを貰っていました。 +クレジットを貰うことが、 +継続して開発に参加してくれることを保証してくれるわけではもちろんありません。 +しかし少なくとも、 +プロジェクトが貢献を認めることを期待できる雰囲気を作り出すことはできます。 +/para + +!-- paraIt is important to distinguish between routine acknowledgment and special thanks. When discussing a particular piece of code, or some other contribution someone made, it is fine to acknowledge their @@ -3878,7 +3933,7 @@ mean we can now implement feature X simultaneously helps people identify which changes you're talking about and acknowledges Daniel's work. On the other hand, posting solely to thank Daniel for the delta -code changes serves no immediate practical purpose. It doesn't add +code changes serves no immediate practical purpose. It doesn't add any information, since the version control system and other mechanisms have already recorded the fact that he made the changes. Thanking everyone for everything would be distracting and ultimately @@ -3888,8 +3943,28 @@ never thank people. Just
[ProducingOSS commit] r1455 - trunk/ja
Author: mumumu Date: Mon Apr 21 17:30:39 2008 New Revision: 1455 Log: - tweaks Types of involvement section. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Mon Apr 21 17:30:39 2008 @@ -306,8 +306,8 @@ そのソフトウェアを活発に維持していくことがその企業の関心事になるのは自然の流れです。 /para para例: ulink - url=http://www.collab.net/;CollabNet が/ulink - ulink url=http://subversion.tigris.org// をサポートしていること(お断り: これは筆者のルーチンワークですが、これがこのモデルの最良の例なのです) + url=http://www.collab.net/;CollabNet/ulink が + ulink url=http://subversion.tigris.org// をサポートしていること(お断り: これは筆者のルーチンワークですが、これがこのモデルの最良の例です) /para /listitem /varlistentry @@ -429,7 +429,7 @@ xref linkend=dual-licensing/ を参照してください) オープンソース開発者のコミュニティが活発なら、 デュアルライセンスされたソフトウェアは、 - 広く多くの人から開発作業やデバッグをしてもらえる利益を得られる上、 + 広く多くの人から開発作業やデバッグをしてもらえるという利益を得られる上、 企業はフルタイムで働くプログラマを支援することで、 ロイヤリティの収入を得ることができるのです。/para paraこのモデルの例として、よく知られているものがふたつあります。 @@ -473,7 +473,7 @@ コーヒーのマグカップやTシャツ、マウスパッドなどのような、 ブランド化した商品を売ることで、 個人や組織から重要な貢献を受けることができます。 - ここで一言注意：もしあなたのプロジェクトで寄付を受けることにした場合、 + ここで一言注意しておきます。もしあなたのプロジェクトで寄付を受けることにした場合、 お金が入ってくる emphasis前/emphasis に寄付されたお金をどう使うかを計画し、 それをプロジェクトのウェブサイトに掲示するようにしましょう。 どうお金を使うかの議論は、実際にお金が入ってくる前の方がうまくいきます。 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1452 - trunk/ja
Author: mumumu Date: Wed Apr 16 04:31:57 2008 New Revision: 1452 Log: - Translated the introduction of Chapter 5. Money. Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Wed Apr 16 04:31:57 2008 @@ -28,6 +28,7 @@ 対象となる人は文脈の中で明らかにしていきます。 /para +!-- paraCorporate funding of free software development is not a new phenomenon. A lot of development has always been informally subsidized. When a system administrator writes a network analysis @@ -39,7 +40,22 @@ the organizations they work for. Those organizations benefit from the investment, of course, although they may not be institutionally aware of it at first./para +-- + +para +フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。 +多くの開発が、いつも非公式に奨励金の対象になってきたのです。 +システム管理者が業務の遂行を助けるためにネットワーク分析ツールを書き、 +オンラインにそれを投稿し、 +バグ修正や機能追加の貢献を他のシステム管理者から受けた場合、 +非公式に団体が設立されていったのです。 +団体を維持するための資金は、システム管理者達の給料から出ており、 +オフィススペースやネットワークの帯域は寄付によって賄われました。 +こうした組織は、はじめのうちは制度的に認知されることはありませんでしたが、 +もちろん投資から利益を得ていたのです。 +/para +!-- paraThe difference today is that many of these efforts are being formalized. Corporations have become conscious of the benefits of open source software, and started involving themselves more directly @@ -48,29 +64,68 @@ long-term sponsors. While the presence of money has not changed the basic dynamics of free software development, it has greatly changed the scale at which things happen, both in terms of the number of -developers and time-per-developer. It has also had effects on how -projects are organized, and on how the parties involved in them +developers and time-per-developer. It has also had effects on +how projects are organized, and on how the parties involved in them interact. The issues are not merely about how the money is spent, or how return on investment is measured. They are also about management and process: how can the hierarchical command structures of corporations and the semi-decentralized volunteer communities of free software projects work productively with each other? Will they even agree on what productively means?/para +-- +para +当時と今の違いは、こうした努力の多くが公に認められるようになったということです。 +企業はオープンソースソフトウェアから得られる利益に関心を示すようになり、 +その開発に直接関わりはじめました。 +開発者達も、本当に重要なプロジェクトには少なくとも寄付や、 +可能であれば長期のスポンサーを期待するようになっています。 +お金があるからといって、 +フリーソフトウェアの基本的な開発力学が変わるものではありませんが、 +開発者の数や、開発者ひとり当たりの作業量の規模は劇的に変わりました。 +お金は、プロジェクトが組織化される方法や、 +関係者のプロジェクトでのやりとりの仕方にも影響を与えました。 +問題は、単にお金がどう使われるのかとか、 +投資に対する見返りをどのように測るか、ということにとどまらず、 +プロジェクトの管理やそのプロセスにも及びます。 +つまり、企業の階層的な命令系統と、 +緩やかに分散したフリーソフトウェアプロジェクトのコミュニティが、 +お互いに生産的に動くにはどうしたらいいでしょう？ +そもそも 生産的に という言葉がどういう意味なのか、 +について企業とコミュニティは一致するのでしょうか？ +/para + +!-- paraFinancial backing is, in general, welcomed by open source development communities. It can reduce a project's vulnerability to the Forces of Chaos, which sweep away so many projects before they really get off the ground, and therefore it can make people more willing to -give the software a chancemdash;they feel they're investing their +give the software a chancemdash; they feel they're investing their time into something that will still be around six months from now. After all, credibility is contagious, to a point. When, say, IBM backs an open source project, people pretty much assume the project won't be allowed to fail, and their resultant willingness to devote effort to it can make that a self-fulfilling prophecy./para +-- + +para +金銭的な支援を受けることは、 +オープンソース開発コミュニティでは一般的に歓迎されています。 +支援を受けることで、 +軌道に乗る前に多くのプロジェクトを潰してきたコミュニティの弱点を無秩序の力に変えることができます。 +それゆえに、人々はソフトウェアを世に送り出したいと強く願うようになります。 +mdash; つまり、これから向こう6ヵ月間は自分の時間をそこらへんに転がっている何かに使おう、 +と人々は考えるのです。結局、何かを信じる心は、ある程度までは他の人に伝染しやすいものです。 +たとえば、IBM がオープンソースプロジェクトを支援したとき、 +このプロジェクトに失敗は許されないと人々は強く思いましたし、 +失敗しないようプロジェクトに注力しようと思う心が、 +プロジェクトが実際に失敗しない状況を作ったのです。 +/para +!-- paraHowever, funding also brings a perception of control. If not handled carefully, money can divide a project into in-group and -out-group developers. If the unpaid volunteers get the feeling that + out-group developers. If the unpaid volunteers get the feeling that design decisions or feature additions are simply available to the highest bidder, they'll head off to a project that seems more like a meritocracy and less like unpaid labor for someone else's benefit. @@ -82,7 +137,23 @@ contributions or outside participation in design discussions. People sense what's expected of them, and live up (or down) to those expectations./para +-- + +para +しかし、お金を出すことは、人を支配する感覚を生むものでもあります。 +注意深く扱わないと、お金はプロジェクトを、仲間内の開発者とそうでない開発者に分裂させてしまうかもしれません。 +ボランティアの開発者が、一番お金を出している人が機能追加や設計上の決定を行えるんだと思ってしまうと、 +実力志向が強く、それでいて他人の利益のために無給で働くことを好まないプロジェクトに移ってしまうでしょう。 +彼らは、決してメーリングリスト上で大声で不平を言ったりはしません。 +そのかわり、ボランティア達が真剣に取り組むことをやめてしまうため、 +外から口を出
[ProducingOSS commit] r1451 - trunk/ja
Author: mumumu Date: Fri Apr 11 14:28:34 2008 New Revision: 1451 Log: - Translated Planning Releases section. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Fri Apr 11 14:28:34 2008 @@ -3233,15 +3233,18 @@ それぞれのコミットを論理的な変更単位に分割するのが望ましいのは、 もちろんリリースブランチを安定させるためだけではありません。 心理的にも、意味がまとまっているコミットはレビューしやすく、 -必要な時に元に戻しやすいということもあります。 -(バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります) +必要な時に元に戻しやすい (バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります) ということもあります。 前もって皆が規律をちょっと守っておけば、プロジェクトが後に頭痛の種を多く抱えずに済むのです。 /para !-- subsection == -- sect2 id=planning +!-- titlePlanning Releases/title +-- +titleリリースの計画を立てる/title +!-- paraOne area where open source projects have historically differed from proprietary projects is in release planning. Proprietary projects usually have firmer deadlines. Sometimes it's because @@ -3254,7 +3257,25 @@ most literal sense: they were written for the love of it. No one felt the need to ship before all the features were ready, and why should they? It wasn't as if anyone's job was on the line./para +-- +para +オープンソースプロジェクトが、歴史的にプロプラエタリなプロジェクトと異なる点は、 +リリースの計画に関するものです。 +プロプラエタリなプロジェクトでは、確固とした〆切があるのが普通です。 +その理由は、顧客にある時点でアップグレードを提供すると約束している場合もあれば、 +新しいリリースをマーケティング上の理由から他の仕事と連携させる必要があったりとか、 +プロジェクトにお金を出しているベンチャーキャピタルの人が、 +さらに投資をする前に成果を見る必要がある場合もあります。 +一方、フリーソフトウェアプロジェクトでは、 +ほとんど文字通りの意味での「道楽」が最近までほとんどの動機付けとなってきました。: +つまり、好きだからコードを書いてきたのです。 +全ての機能が揃う前にリリースする必要性を感じる人はいませんし、 +そもそもなぜそうすべきなのでしょう？ +フリーソフトウェアプロジェクトでは、皆の仕事がひとつの生産ラインに乗っているわけではないのです。 +/para + +!-- paraNowadays, many open source projects are funded by corporations, and are correspondingly more and more influenced by deadline-conscious corporate culture. This is in many ways a good thing, but it can @@ -3267,7 +3288,22 @@ agendasmdash;perhaps features they want to complete, or some testing they want to have donemdash;that they feel the release should wait on./para +-- +para +最近では、多くのオープンソースプロジェクトが企業からお金を出してもらうようになり、 +それに伴って企業の〆切文化の影響をより多く受けるようになってきています。 +これは多くの点では良いことなのですが、 +お金を貰って雇われている開発者とボランティアの開発者の間で、 +優先順位の衝突が起きる可能性があります。 +こうした衝突はリリーススケジュールをいつ、どのようにするかという問題でよく発生します。 +プレッシャーが強い雇われ開発者は、当然リリースする日程を決めたがりますが、 +ボランティアの開発者は他の問題意識の方が強いかもしれません mdash; +それは自分たちが求める機能や、仕上げておきたいテストであったりします mdash; +よって、ボランティアの開発者達はリリースを待つべきだと感じることになります。 +/para + +!-- paraThere is no general solution to this problem except discussion and compromise, of course. But you can minimize the frequency and degree of friction caused, by decoupling the proposed @@ -3282,10 +3318,11 @@ Exploring the Impact of Release Management/citetitle (ulink url=http://www.cyrius.com/publications/michlmayr-phd.html/). It is about using time-based release processes, as opposed to -feature-based, in large free software projects. Michlmayr also gave a +feature-based, in large free software projects. Michlmayr also gave a talk at Google on the subject, available on Google Video at ulink url=http://video.google.com/videoplay?docid=-5503858974016723264; -/./para/footnote. By nailing down feature sets early, you reduce +/./para/footnote. + By nailing down feature sets early, you reduce the complexity of the discussion centered on any individual release, and therefore improve predictability. This also creates a kind of inertial bias against anyone who proposes to expand the definition of @@ -3293,7 +3330,32 @@ release's contents are fairly well defined, the onus is on the proposer to justify the expansion, even though the date of the release may not have been set yet./para +-- +para +もちろんこの問題については、議論し、妥協する以外に一般的な解決策はありません。 +しかし、提案されているリリースの emphasis存在/emphasis から、 +日付を切り離すことで、衝突の頻度や度合いを最小限にすることができます。 +つまり、はじめはざっくりとした見積りfootnotepara別のアプローチとして、 +Martin Michlmayr の Ph.D論文 citetitleQuality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management/citetitle (ulink url=http://www.cyrius.com/publications/michlmayr-phd.html/) を読むとよいかもしれません。 +これは巨大なソフトウェアプロジェクトにおいて、 +機能ベースのリリースプロセスとは正反対の、 +時間軸をベースとしたリリースプロセスを採用することに関する論文です。 +Michlmayr は、Google でこれを題材にした講演も行っています。Google Video で視聴可能です。ulink url=http://video.google.com/videoplay?docid=-5503858974016723264/ +/para/footnote 以外は日付について触れず、 +直近から中期的な段階で、プロジェクトはどういった形のリリースができるか、 +そしてそのリリースにどんな機能を含めるのか、という方向に議論を誘導してみるのです。 +機能について早期に確定しておくことで、 +個々のリリースに関する議論が複雑になる度合いを減らすことができ、 +予測可能性を高めることができます。 +また、新機能や他の複雑なことをリリースに追加することで、 +リリースの定義を拡大解釈する提案に反対させるある種の先入観を植え付けることができます。 +たとえリリースの日取りが決まっていなくても、 +その内容がうまく決まっていれば、 +リリースの内容を拡大するのを正当化するのはそれを提案する人の責任になります。 +/para + +!-- paraIn his multi-volume biography of Thomas Jefferson, citetitleJefferson and His Time/citetitle, Dumas
[ProducingOSS commit] r1450 - trunk/ja
Author: mumumu Date: Wed Apr 9 15:51:12 2008 New Revision: 1450 Log: - Translated Releases and Daily Development section. -- I'm ashamed to read this section ... :( Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Wed Apr 9 15:51:12 2008 @@ -3102,8 +3102,12 @@ !-- SECTION == -- sect1 id=releases-and-daily-development +!-- titleReleases and Daily Development/title +-- +titleリリースと日々の開発/title +!-- paraMaintaining parallel releases simultaneously has implications for how daily development is done. In particular, it makes practically mandatory a discipline that would be recommended anyway: @@ -3112,31 +3116,51 @@ to do in one commit, break it across N commits, where each commit is a well-partitioned subset of the overall change, and includes nothing unrelated to the overall change./para +-- + +para +平行して行われるリリースを同時に管理するということから、 +日々の開発のやり方を推測することができます。 +特に、次のことはどんなときでも推奨される強制的な規律になります。 +つまり、コミットのひとつひとつは、論理的な変更単位であること、 +そして関連のない変更をごっちゃにして一度にコミットしてはいけない、ということです。 +変更する量がとても多い、または一度にコミットするのが破壊的である場合は、 +それをN回のコミットに分割し、 +それぞれのコミットが変更全体をうまく分割したサブセットであるようにします。 +そして変更全体に関係のないものは一切含まれないようにします。 +/para +!-- paraHere's an example of an ill-thought-out commit:/para +-- + +para +次に示すのは、まとまりのない悪いコミットの例です。: +/para screen r6228 | jrandom | 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 lines -Fix Issue #1729: Make indexing gracefully warn the user when a file -is changing as it is being indexed. +問題 #1729 を修正 : インデックス作成を上品に行うようにした。これに伴い、 +ファイルにインデックスを作成している最中にユーザーがファイルを変更していたら警告するようにした。 * ui/repl.py - (ChangingFile): New exception class. - (DoIndex): Handle new exception. + (ChangingFile): 新しい例外クラス + (DoIndex): 新しい例外を処理するようにした * indexer/index.py - (FollowStream): Raise new exception if file changes during indexing. - (BuildDir): Unrelatedly, remove some obsolete comments, reformat - some code, and fix the error check when creating a directory. + (FollowStream): インデックスを作成中にファイルが変更されたら、例外を生成するようにした + (BuildDir): 上記とは関係ないが、いくつかの古いコメントを削除し、 + コードのフォーマットをいくつか修正した。また、ディレクトリ作成時のエラーチェックを修正した。 -Other unrelated cleanups: +その他関連のないクリーンアップ: -* www/index.html: Fix some typos, set next release date. +* www/index.html: typoを修正し、次のリリース日を設定。 /screen +!-- paraThe problem with it becomes apparent as soon as someone needs to port the functionBuildDir/function error check fix over to a branch for an upcoming maintenance release. The porter doesn't want @@ -3147,14 +3171,36 @@ functionBuildDir/function change via the version control tool's merge functionality, because the version control system was told that that change is logically grouped with all these other unrelated -things. In fact, the problem would become apparent even before the +things. + +In fact, the problem would become apparent even before the merge. Merely listing the change for voting would become problematic: instead of just giving the revision number, the proposer would have to make a special patch or change branch just to isolate the portion of the commit being proposed. That would be a lot of work for others to suffer through, and all because the original committer couldn't be bothered to break things into logical groups./para +-- + +para +問題点が浮き彫りになるのは、来るべきメンテナンスリリースに備えて、 +functionBuildDir/function 関数のエラーチェックをリリースブランチに移植する必要が出てきたときです。 +移植する人は、それ以外の変更点はいらないのです。 +たとえば、問題 #1729 の修正自体をメンテナンスブランチに取り込むことは認められず、 +filenameindex.html/filename の調整もここでは関係ありません。 +しかし、functionBuildDir/function の変更を、 +バージョン管理システムのマージ機能を使って容易に取り出すことはできません。 +なぜなら、バージョン管理システムは、 +この変更を他の関係のないものとグループ化するように指示されているからです。 +実際には、マージする前でさえ問題が出てくるでしょう。投票を行うために変更点を羅列する場合です。: +投票を提案する人は、該当する変更のリビジョン番号を与える代わりに、 +提案されているコミットの一部分を分離するためだけに、特別なパッチを作ったり、 +変更用のブランチを切らなければならなくなります。 +このため、他の人がうんざりする量の仕事をすることになります。 +それというのもすべて、変更点を論理的なグループに分割するのを面倒臭がったコミッタのせいなのです。 +/para +!-- paraIn fact, that commit really should have been emphasisfour/emphasis separate commits: one to fix issue #1729, another to remove obsolete comments and reformat code in @@ -3162,7 +3208,18 @@ functionBuildDir/function, and finally, one to tweak filenameindex.html/filename. The third of those commits would be the one proposed for the maintenance release branch./para +-- +para +実際には、このコミットは emphasis4つ/emphasis に分割すべきでした。 +ひとつは 問題 #1729 の修正、 +もうひとつは 古いコメントの削除と functionBuildDir/function 関数のコードフォーマットの修正、 +そして functionBuildDir/function 関数のエラーチェックの修正、 +最後に filenameindex.html/filename の微調整です。 +3番目のコミットこそが、メンテナンスリリースのブランチに含めるよう提案されているものなのです。 +/para + +!-- paraOf course, release stabilization is not the only reason why
[ProducingOSS commit] r1447 - trunk/ja
Author: mumumu Date: Tue Apr 8 16:32:37 2008 New Revision: 1447 Log: - Translated Maintaining Multiple Release Lines section. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Tue Apr 8 16:32:37 2008 @@ -2879,8 +2879,12 @@ !-- SECTION == -- sect1 id=release-lines +!-- titleMaintaining Multiple Release Lines/title +-- +title複数のリリースラインを管理する/title +!-- paraMost mature projects maintain multiple release lines in parallel. For example, after 1.0.0 comes out, that line should continue with micro (bugfix) releases 1.0.1, 1.0.2, etc., until the @@ -2896,14 +2900,45 @@ bit severe to just put the bugfix in 1.1.0 and tell all the old 1.0.x users they should upgrade. Why not release both 1.1.0 and 1.0.4, so everyone can be happy?/para +-- +para +ほとんどの成熟したプロジェクトは、複数のリリースラインを平行して管理しています。 +たとえば バージョン 1.0.0 がリリースされた後は、 +プロジェクトが明示的にリリースラインの維持をやめるまで、 +マイクロ(バグ修正)リリースを 1.0.1, 1.0.2などの形でリリースするようにします。 +ただ (訳注: メジャー番号が上がった) 1.1.0 をリリースすることが、 +1.0.x ラインの維持をやめる十分な理由にはならないことに注意してください。 +たとえば、新しいマイナー(メジャー)シリーズのはじめのリリースは絶対にアップグレードの対象にしないことをポリシーにしているユーザーもいます mdash; +つまり、彼らはたとえば 1.1.0 の間は他のユーザーにバグを探させ、 +1.1.1 のリリースを待っているのです。これは必ずしも自分勝手な行動とは言えません。 +(彼らは、新機能や、バグ修正の恩恵を受けることを控えていることも覚えておきましょう) +ただ、理由が何であれ、彼らはアップグレードをとても慎重に行うと決めただけなのです。 +よって、プロジェクトが 1.1.0 のリリースを目前にして 1.0.3 で重大なバグを発見した場合は、 +ちょっと厳しいですが 1.1.0 でその修正を行い、 +すべての 1.0.x 系を使っているユーザーにアップグレードを推奨することになるでしょう。 +この場合、1.1.0 と 1.0.4 を両方リリースしたとして、開発者とユーザーの双方がハッピーでしょうか？ +そうではないですよね。 +/para + +!-- paraAfter the 1.1.x line is well under way, you can declare 1.0.x to be at firsttermend of life/firstterm. This should be announced officially. The announcement could stand alone, or it could be mentioned as part of a 1.1.x release announcement; however you do it, users need to know that the old line is being phased out, so they can make upgrade decisions accordingly./para +-- + +para +1.1.x ラインの維持がうまくいくと、プロジェクトは 1.0.x ラインの firstterm維持をやめる/firstterm と宣言することができます。 +この宣言は公式なものとして行いましょう。その告知は単独で行うこともできますし、 +1.1.x ラインのリリース告知と一緒に行うこともできます。どの方法をとるにしても、 +ユーザーは古いリリースラインが維持されなくなることを知らなければいけません。 +なぜなら、その告知に従って、ユーザーはアップグレードをする決断ができるからです。 +/para +!-- paraSome projects set a window of time during which they pledge to support the previous release line. In an open source context, support means accepting bug reports against that line, and making @@ -2912,7 +2947,20 @@ to gauge how many people are still using the older line. When the percentage drops below a certain point, they declare end of life for the line and stop supporting it./para +-- +para +プロジェクトによっては、以前のリリースラインのサポートを保証する期間を設定するところもあります。 +オープンソースの文脈でいえば、サポート とはそのリリースラインに対するバグ報告を受け付け、 +バグが十分出尽くすまでメンテナンスリリースを行うということです。 +一方で、明示的にサポート期間は設定しないものの、 +古いリリースラインを使っているユーザーの数を把握するため、 +バグ報告の数を見張るプロジェクトもあります。 +古いリリースラインを使うユーザーの率がある値より下がった時点で、 +プロジェクトはそのラインの維持をやめると宣言し、サポートをやめるのです。 +/para + +!-- paraFor each release, make sure to have a firsttermtarget version/firstterm or firsttermtarget milestone/firstterm available in the bug tracker, so people filing bugs will be able to do @@ -2920,10 +2968,22 @@ called development or latest for the most recent development sources, since some peoplemdash;not only active developersmdash;will often stay ahead of the official releases./para +-- + +para +リリースを行うごとに、必ず firsttermターゲットバージョン/firstterm または firsttermターゲットとなるマイルストーン/firstterm をバグ報告システムに設定するようにしましょう。 +なぜなら、ユーザーが、適切なリリースに対してバグを報告できるようにするためです。 +開発中の最新のソースコードに対しては、 + development や latest と呼ばれるターゲット名を設定することも忘れないでください。 +なぜなら、ユーザーによっては、 mdash; 活発な開発者だけではありません mdash; 公式なリリースより新しいコードを実行しているからです。 +/para !-- subsection == -- sect2 id=security-releases titleSecurity Releases/title +!-- +titleセキュリティリリース/title +-- paraMost of the details of handling security bugs were covered in xref linkend=security/phrase output=printed in ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1340 - trunk/ja
Author: mumumu Date: Fri Dec 21 20:59:34 2007 New Revision: 1340 Log: - trivial fix. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Fri Dec 21 20:59:34 2007 @@ -916,7 +916,7 @@ -- para -投票システムは、有権者に関する疑問を提起します。 +投票システムを使うとなると、有権者に関する疑問が出てきます。 誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。 なぜなら、どの人が熱心にプロジェクトに参加しているかとか、 どの人がよりよい判断を下せるか、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1320 - trunk/ja
Author: mumumu Date: Sat Dec 8 11:44:09 2007 New Revision: 1320 Log: - translated Pre-Release Section. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Dec 8 11:44:09 2007 @@ -2108,7 +2108,7 @@ バージョン管理システムのリポジトリに要求することでいつでも引き出すことができます。 これによって、プロジェクトが変更点を静的なファイルに保存する意味がなくなります。 mdash; 実際には、リポジトリに保存されたログメッセージは、 - ChangeLog ファイルの内容と重複するだけなので、もっと意味がないことが起こります。 + ChangeLog ファイルの内容と重複するだけなので、もっと無意味なことが起こります。 /para /sidebar @@ -2205,7 +2205,7 @@ !-- titleTo capitalize or not to capitalize/title -- -title大文字にすべきか、小文字のままにするか/title +title大文字にするか、小文字のままにするか/title !-- paraWhen referring to a project by name, people generally capitalize @@ -2240,14 +2240,23 @@ !-- titlePre-releases/title -- -titleプレリリース/title +titleプレリリース版/title +!-- paraWhen shipping a pre-release or candidate release, the qualifier is truly a part of the release number, so include it in the name of the package's name. For example, the ordered sequence of alpha and beta releases given earlier in xref linkend=release-number-components/ would result in package names like this:/para +-- + +para +プレリリース版またはリリース候補のパッケージをリリースする場合は、 +その識別子はリリース番号の一部になります。 +よって、パッケージ名にその識別子を含めるようにしましょう。 +たとえば、xref linkend=release-number-components/ で説明したアルファ版やベータ版のリリースの順番は、パッケージ名では以下のように表現します。 +/para informalexample literallayoutscanley-2.3.0-alpha1.tar.gz @@ -2258,9 +2267,15 @@ scanley-2.3.0.tar.gz/literallayout /informalexample +!-- paraThe first would unpack into a directory named filenamescanley-2.3.0-alpha1/filename, the second into filenamescanley-2.3.0-alpha2/filename, and so on./para +-- + +para +はじめのパッケージは、filenamescanley-2.3.0-alpha1/filenameというディレクトリに展開され、ふたつめは filenamescanley-2.3.0-alpha2/filename に展開される ... などです。 +/para /sect3 @@ -2268,7 +2283,10 @@ !-- == subsection === -- sect2 id=packaging-build-install +!-- titleCompilation and Installation/title +-- +titleコンパイルとインストール/title paraFor software requiring compilation or installation from source, there are usually standard procedures that experienced users expect to @@ -2343,7 +2361,10 @@ !-- == subsection === -- sect2 id=binary-packages +!-- titleBinary Packages/title +-- +titleバイナリパッケージ/title paraAlthough the formal release is a source code package, most users will install from binary packages, either provided by their operating ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1321 - trunk/ja
Author: mumumu Date: Sat Dec 8 12:30:12 2007 New Revision: 1321 Log: - Money Ownership, but doing something :-). Modified: trunk/ja/ch05.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat Dec 8 12:30:12 2007 @@ -1,9 +1,13 @@ chapter id=money +!-- titleMoney/title +-- +titleカネに関する問題/title simplesect +!-- paraThis chapter examines how to bring funding into a free software environment. It is aimed not only at developers who are paid to work on free software projects, but also at their managers, who need to @@ -12,6 +16,17 @@ paid developer, or one who manages such developers. The advice will often be the same for both; when it's not, the intended audience will be made clear from context./para +-- + +para +この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきます。 +ここでは、フリーソフトウェアプロジェクトで、お金を貰って雇われる開発者だけでなく、 +開発する環境が置かれる社会力学を理解する必要があるプロジェクトの管理者も対象にします。 +以下の節では、読者(あなたです！) はお金を貰って雇われる開発者か、 +そうした開発者を管理する人であることを想定します。 +この章でのアドバイスは、両者に当てはまることもありますし、そうでないこともありますが、 +対象となる人は文脈の中で明らかにしていきます。 +/para paraCorporate funding of free software development is not a new phenomenon. A lot of development has always been informally ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1322 - trunk/ja
Author: mumumu Date: Sat Dec 8 13:52:58 2007 New Revision: 1322 Log: - translated part of Compilation and Installation - trivial fix. Modified: trunk/ja/ch05.xml trunk/ja/ch07.xml Modified: trunk/ja/ch05.xml == --- trunk/ja/ch05.xml (original) +++ trunk/ja/ch05.xml Sat Dec 8 13:52:58 2007 @@ -20,7 +20,7 @@ para この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきます。 -ここでは、フリーソフトウェアプロジェクトで、お金を貰って雇われる開発者だけでなく、 +ここでは、フリーソフトウェアプロジェクトでお金を貰って雇われる開発者だけでなく、 開発する環境が置かれる社会力学を理解する必要があるプロジェクトの管理者も対象にします。 以下の節では、読者(あなたです！) はお金を貰って雇われる開発者か、 そうした開発者を管理する人であることを想定します。 Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Dec 8 13:52:58 2007 @@ -1983,7 +1983,7 @@ -- para -今回のリリースで新しくなったことを説明する filenameCHANGES/filename (filenameNEWS/filename と呼ばれることもあります) ファイルもツリーの最上部に配置されます。 +今回のリリースで新しくなったことを説明する filenameCHANGES/filename (filenameNEWS/filename と呼ばれることもあります) ファイルもツリーの最上部に配置します。 この filenameCHANGES/filename ファイルは、 これまで行われたリリース全ての変更点を集めたもので、 今回のリリースの変更点の一覧が一番最初になるように、 @@ -2051,8 +2051,8 @@ -- para - firsttermChangeLog/firstterm ファイルは、 - 伝統的にプロジェクトでこれまで行われたあらゆる変更を一覧にします。 + 伝統的に firsttermChangeLog/firstterm ファイルは、 + プロジェクトでこれまで行われたあらゆる変更を一覧にします。 mdash; つまり、バージョン管理システムにコミットされた全てのリビジョンです。 ChangeLog ファイルには様々なフォーマットがあります。 どんなフォーマットでも同じ情報が含まれているので、 @@ -2288,11 +2288,20 @@ -- titleコンパイルとインストール/title +!-- paraFor software requiring compilation or installation from source, there are usually standard procedures that experienced users expect to be able to follow. For example, for programs written in C, C++, or certain other compiled languages, the standard under Unix-like systems is for the user to type:/para +-- + +para +ソースコードをコンパイルし、インストールを行う必要があるソフトウェアは、 +経験豊富なユーザーが行う標準的な手順があります。 +たとえば、C, C++, その他のコンパイル言語で書かれたプログラムでは、 +Unixライクなシステムでユーザーがタイプする標準的な手順は次のようなものです。 +/para screen $ ./configure @@ -2300,6 +2309,7 @@ # make install /screen +!-- paraThe first command autodetects as much about the environment as it can and prepares for the build process, the second command builds the software in place (but does not install it), and the last command @@ -2310,7 +2320,21 @@ is published as treeware by New Riders, and its content is also freely available online at ulink url=http://sources.redhat.com/autobook//./para +-- +para +はじめのコマンドは、自動的に実行環境をできるだけ把握し、ビルドプロセスの準備を行います。 +ふたつめのコマンドはソフトウェアをビルとします。（しかしインストールは行いません） +最後のコマンドはシステムにソフトウェアをインストールします。 +最初のふたつのコマンドは通常のユーザーで実行し、最後はrootユーザーで実行します。 +このシステムをセットアップする作業の詳細は、Vaughan, Elliston, Tromey, +Taylor が書いた citetitleGNU Autoconf, Automake, +and Libtool/citetitle という優れた本があるので、それを参照して下さい。 +この本は 出版社 New Riders によってツリーウェア(訳注：ドキュメントやその他の印刷物を指すハッカー用語)として公開されており、 +ulink url=http://sources.redhat.com/autobook// でもオンラインで利用可能です。 +/para + +!-- paraThis is not the only standard, though it is one of the most widespread. The Ant (ulink url=http://ant.apache.org//) build system is gaining popularity, especially with projects written in @@ -2323,6 +2347,20 @@ an experienced developer; you can safely assume that emphasissome/emphasis standard applies, even if you don't know what it is at first./para +-- + +para +この手順が唯一の標準というわけではありませんが、 +これはもっとも普及しているもののひとつです。 +Ant(ulink url=http://ant.apache.org//) ビルドシステムが特にJavaで書かれたプロジェクトで人気を得つつありますが、Antもビルドとインストールの標準的な手順を持っています。 +同様に、PerlやPythonのようなプログラミング言語では、 +その言語で書かれた殆どのプログラムで同じ手順を使うことを勧めています(たとえば、Perlモジュールは次のようなコマンドを使います。 +commandperlnbsp;Makefile.pl/command) +自分のプロジェクトにどの標準を使うかがわからない場合は、 +経験豊富な開発者に尋ねてみましょう。 +たとえどの標準使うかがはじめわからなくても、 +適用できる標準が emphasis存在する/emphasis と想定しても安全です。 +/para paraWhatever the appropriate standards for you project are, don't deviate from them unless you absolutely must. Standard installation ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1323 - trunk/ja
Author: mumumu Date: Sat Dec 8 14:06:51 2007 New Revision: 1323 Log: - self review ... trivial fix. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Dec 8 14:06:51 2007 @@ -2140,7 +2140,8 @@ できるだけ似たものにすべきです。 これらの間には少し違いがあるのが普通です。 たとえば、リリースされるパッケージには設定やコンパイルに必要な自動生成されたファイル(phrase output=printedこの章の後半の/phrasexref linkend=packaging-build-install/ を参照して下さい) が含まれていたり、 - プロジェクトが管理していないが、必須のものであったり、ユーザーがまだインストールしていないかもしれないサードパーティーのソフトウェアが含まれているからです。 +プロジェクトが管理していないが、必須のものであったり、 +ユーザーがまだインストールしていないかもしれないサードパーティーのソフトウェアが含まれているからです。 しかしながら、たとえ配布されたディレクトリツリーが、 バージョン管理システムのリポジトリにある開発ツリーと全く同じだったとしても、 その配布物は作業コピーと同じであってはいけません(xref linkend=vc-vocabulary-working-copy/ を参照して下さい)。 @@ -2298,7 +2299,7 @@ para ソースコードをコンパイルし、インストールを行う必要があるソフトウェアは、 -経験豊富なユーザーが行う標準的な手順があります。 +経験豊富なユーザーが従う標準的な手順があります。 たとえば、C, C++, その他のコンパイル言語で書かれたプログラムでは、 Unixライクなシステムでユーザーがタイプする標準的な手順は次のようなものです。 /para @@ -2323,8 +2324,8 @@ -- para -はじめのコマンドは、自動的に実行環境をできるだけ把握し、ビルドプロセスの準備を行います。 -ふたつめのコマンドはソフトウェアをビルとします。（しかしインストールは行いません） +はじめのコマンドは、自動的に実行環境をできるだけ把握し、ビルドの準備を行います。 +ふたつめのコマンドはソフトウェアをビルドします。（しかしインストールは行いません） 最後のコマンドはシステムにソフトウェアをインストールします。 最初のふたつのコマンドは通常のユーザーで実行し、最後はrootユーザーで実行します。 このシステムをセットアップする作業の詳細は、Vaughan, Elliston, Tromey, @@ -2351,8 +2352,8 @@ para この手順が唯一の標準というわけではありませんが、 -これはもっとも普及しているもののひとつです。 -Ant(ulink url=http://ant.apache.org//) ビルドシステムが特にJavaで書かれたプロジェクトで人気を得つつありますが、Antもビルドとインストールの標準的な手順を持っています。 +もっとも普及しているもののひとつです。 +Ant (ulink url=http://ant.apache.org//) ビルドシステムが特にJavaで書かれたプロジェクトで人気を得つつありますが、Antもビルドとインストールの標準的な手順を持っています。 同様に、PerlやPythonのようなプログラミング言語では、 その言語で書かれた殆どのプログラムで同じ手順を使うことを勧めています(たとえば、Perlモジュールは次のようなコマンドを使います。 commandperlnbsp;Makefile.pl/command) ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1279 - trunk/ja
Author: mumumu Date: Sat Nov 3 10:39:55 2007 New Revision: 1279 Log: - sorry. i forgot commenting out ... Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Nov 3 10:39:55 2007 @@ -1457,6 +1457,7 @@ -- titleリリースに含める変更を投票で決める/title +!-- paraAt the opposite extreme from dictatorship by release owner, developers can simply vote on which changes to include in the release. However, since the most important function of release stabilization is @@ -1479,6 +1480,7 @@ vote against as a personal affront. The greater the number of people involved, the more the discussion becomes about the change and less about the individuals./para +-- para リリースオーナーの独裁と全く正反対ですが、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1254 - trunk/ja
Author: mumumu Date: Sat Oct 13 17:51:13 2007 New Revision: 1254 Log: - Stabilizing release translated. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Oct 13 17:51:13 2007 @@ -295,7 +295,7 @@ 些細な話題なのに最も古くからあちこちで議論されてきた（phrase output=printedxref linkend=communications/ の /phrase xref linkend=bikeshed/ を参照してください）もののひとつですが、 近い将来、唯一の完全な標準に落ち着く気配はありません。 しかし、emphasis一貫していること/emphasis という普遍的に受け入れられた原則に基づいて、 -優れた戦略がいくつか現れてきています。 +優れた戦略がいくつか出てきています。 番号の付け方を選び、それを文書化し、守るようにしましょう。 番号の付け方をはっきりさせれば、ユーザーはあなたに感謝することでしょう。 /para @@ -316,7 +316,6 @@ 読者に前提となる知識が殆どないことを想定しています。 主に参考資料として読まれることを意図していますが、 あなたが既にこうした規約に馴染んでいるのなら、飛ばして読んでも構いません。 - /para paraリリース番号はドットで区切られた数字の集まりです。/para @@ -384,9 +383,9 @@ 同じバージョン番号ながら、 こうした識別子がつかないものが将来リリースされることを示しています。 よって、2.3.0nbsp;(Alpha) は結局 2.3.0 になります。 -このような、複数の最終リリースの候補となるものを一行であらわすために、 +このように、複数の最終リリースの候補となるものを一行であらわすために、 識別子そのものが メタ識別子 を持つことができます。 -たとえば、一般の人が利用できるようになるまでの順番で、 +例として、一般の人が利用できるようになるまでの順番で、 一連のリリースを以下に示します。 /para @@ -492,7 +491,7 @@ -- para -リリース番号を付ける一貫したポリシーがあれば、 +リリース番号を付ける一貫した決まりがあれば、 ユーザーは同じソフトウェアのふたつのリリース番号を見て、 数字だけでふたつの重要な違いを区別できるようになります。 3つの数字からなる典型的なリリース番号では、 @@ -543,7 +542,7 @@ 3番目のマイクロ番号と同じ意味で用いているプロジェクトもあります。） 最後の数字を firsttermビルド番号/firstterm として用いるプロジェクトもあります。 ビルド番号はソフトウェアがビルドされるたびにひとつ増えていき、 -ビルド以外の変更がないことを表しています。 +ビルド以外の変更がないことをあらわしています。 ビルド番号はバグレポートを特定のビルド番号に結びつけるのに役立ちますし、 バイナリパッケージを通常配布しているプロジェクトで、恐らくもっとも役に立つでしょう。 /para @@ -679,13 +678,13 @@ たとえば、あなたのプロジェクトがクライアント/サーバ アプリケーションを作っているとすると、 後方互換性 とは、サーバを 2.6.0 にアップグレードしても 既にあるバージョン 2.5.4 のクライアントが以前と異なる振舞い（もちろんバグを直した場合は別です）をしたり、 -動かなくなる機能があったりしてはいけないということです。 -一方、サーバを 2.6.0 にアップグレードするとともに、クライアントも2.6.0にすると、 +動かなくなる機能があってはいけないということです。 +一方、サーバを 2.6.0 にアップグレードすると同時に、クライアントも2.6.0にすると、 emphasis新しい/emphasis 機能がクライアントで使えるようになるかもしれませんが、 -2.5.4で使えていたクライアントの機能は 2.6.0 でどのように扱われるかわかりません。 +2.5.4で使えていたクライアントの機能は 2.6.0 でどう扱われるかわかりません。 こういうことが起こると、このクライアントのアップグレードには 前方互換性が emphasisない/emphasis ことになります。 つまり、クライアントを 2.5.4 にダウングレードしても、 -2.6.0で使えていた全ての機能は使えないということになります。 +2.6.0 で使えていた全ての機能は使えないということになります。 なぜなら、2.6.0 の機能には新機能が含まれているからです。 /para @@ -736,8 +735,9 @@ なぜなら、マイナー番号をまたがるとダウングレードできる必要はないからです。 あなたのプロジェクトが他のプログラムで使われているライブラリを配布しているとすると、 その API も互換性の問題が起こる領域に入ります。 -新しいバージョンに古いバージョンを置き換える形でアップグレードしても安全かどうか、詳しいユーザーがわかるように、 -ソース、バイナリレベルでの互換性に関するルールを詳しく説明しておかなければなりません。 +新しいバージョンに古いバージョンを置き換える形でアップグレードしても安全かどうか、 +詳しいユーザーがわかるように、 +ソース、バイナリレベルでの互換性に関するルールを詳しく説明しておかなければいけません。 詳しいユーザーは、バージョン番号をみれば互換性があるかどうかがすぐにわかるでしょう。 /para @@ -793,12 +793,12 @@ リリースポリシーではこのことを明示的に宣言しておくべきです） 開発の初期段階にあるプロジェクトは、 バージョン 0.1, 0.2, 0.3 といった順で、 1.0 の準備ができるまでリリースを行うことができますし、 -リリース間の差異は適宜大きくすることができます。 -バージョン 1.0以前は、マイクロ番号を使うかどうかは任意です。 +リリース間の違いを適宜大きくすることができます。 +バージョン 1.0 以前は、マイクロ番号を使うかどうかは任意です。 プロジェクトの性質とリリース間の差異によっては、 0.1.0, 0.1.1 といった番号があれば便利かもしれませんし、そうでないかもしれません。 バージョン 1.0 以前のリリース番号のルールはかなりルーズです。 -これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることや、 +これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることと、 早くから使っている人はどちらにせよ寛大な傾向にあることが主な理由です。 /para @@ -812,10 +812,11 @@ -- para -こうした制約は、ここで説明した３つの数字を使った番号の付け方にだけ当てはまります。 -あなたのプロジェクトでは、３つの番号を使って、 +こうした制約は、３つの数字を使った番号の付け方にだけ当てはまります。 +あなたのプロジェクトでは、３つの数字を使って、 これとは違った番号の付け方を簡単に思い付くでしょう。 -もしくは、細かい粒度は必要ないので、代わりに２つの番号を使おうと決めることもできるでしょう。 +もしくは、細かい粒度は必要ないので、 +代わりに２つの番号を使おうと決めることもできるでしょう。 重要なのは、こういうことは早めに決めておいて、 それぞれの数字が意味するところを正確に皆に知らせ、それを守ることです。 /para @@ -836,14 +837,15 @@ -- para -プロジェクトによっては、マイナー番号の偶数/奇数をソフトウェアの安定度を示すのに使うことがあります。 +プロジェクトによっては、 +マイナー番号の 偶数/奇数 をソフトウェアの安定度を示すために使うことがあります。 つまり、偶数は安定版で、奇数は不安定版ということです。 これはマイナー番号にのみ当てはまることで、 メジャー番号とマイクロ番号には当てはまりません。 マイクロ番号をひとつ増やすことは、 バグフィックスが行われた（新機能はない）ことを示しますし、 メジャー番号をひとつ増やすことは、 -大きな変更が行われたか、新機能が揃っていることを表しています。 +大きな変更が行われたか、新機能が揃っていることをあらわしています。 /para !-- @@ -900,7 +902,8 @@ 大きな害はありません。 奇数/偶数に意味を持たせる仕組みは、 リリースサイクルがとても長いプロジェクトでもっとも有効でしょうし、 -プロジェクトの性質上、新機能よりも安定性に重きを置く保守的なユーザの割合が高いところでも有効です。 +プロジェクトの性質上、 +新機能よりも安定性に重きを置く保守的なユーザの割合が高いところでも有効です。 この仕組みが、新機能を大胆にテストする唯一の方法ではありません。 phrase output=printedこの章の後半の/phrase xref linkend=stabilizing-a-release/ でも説明していますが、 潜在的に不安定なコードをリリースするもっと一般的な方法は、 @@ -956,9 +959,9 @@ -- para -では、プロジェクトはどうやって正式なリリース作業を行うべきなのでしょうか。 +では、プロジェクトはソフトウェアをどうやって正式にリリースすべきなのでしょうか。 ある時点のソースツリーのスナップショットを取得してパッケージにまとめ、 -世界中にたとえばバージョン 3.5.0 として配布すべきなのでしょうか。 +たとえばバージョン 3.5.0 として世界中に配布すべきなのでしょうか。 常識的からいって答えはNOです。第一、開発ツリー全体が綺麗になっていて、 リリースの準備ができている瞬間なんて多分ありません。 開発を始めた新機能のコードが、様々な完成度でそこらじゅうに転がっているでしょう。 @@ -993,14 +996,13 @@ そのとき進行
[ProducingOSS commit] r1255 - trunk/ja
Author: mumumu Date: Sat Oct 13 18:18:36 2007 New Revision: 1255 Log: - updated translation Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Oct 13 18:18:36 2007 @@ -1294,7 +1294,7 @@ それに乗り遅れまいとして大急ぎで変更作業を終えようとします。 これは勿論、リリースするときにはまさに起こって欲しくないことです。 開発者は自分の好きなペースで新機能を実装していればいいのであって、 -自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方が望ましいのです。 +自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方がいいのです。 ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、 コードは不安定になり、（普通）多くのバグが発生してしまうのです。 /para @@ -1322,15 +1322,14 @@ リリースを安定化する過程でどの変更をリリースに取り込むべきかについて、 おおまかな点で一致しています。深刻なバグ、 特に回避しようがないバグの修正は含めていいでしょう。 -ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正も同様です。 -（但し、それがインターフェイスの一部と考えられていて、 -安定していなければいけない場合は別です） -多くのプロジェクトでは、リスクが低いか、コアに影響しないある種の変更も受け入れますし、 +ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正（但し、それがインターフェイスの一部と考えられていて、 +安定していなければいけない場合は別です）も同様です。 +多くのプロジェクトでは、リスクが低いか、コアに影響しない変更も受け入れますし、 リスクを測るための正式なガイドラインもあるでしょう。 -しかし、どんな基準があっても人間の判断は必ず必要です。 +しかし、どんな基準があったとしても人間の判断は必ず必要です。 変更をリリースに取り込むか否かをプロジェクトが決めなければいけないのは日常茶飯事でしょう。 危険なのは、開発者それぞれが自分の変更をリリースに含めたいと思っているので、 -変更を受け入れることを望む人は多いのに、それに対してNOという人が少ないことです。 +変更を受け入れることを望む人は多いのに、それに対して NO という人が少ないことです。 /para !-- @@ -1351,15 +1350,15 @@ para そういうわけで、リリースを安定化させるプロセスは、 ほとんどが NO と言う仕組みを作ることと同じです。 -オープンソースプロジェクトに特有なトリックは、 +オープンソースプロジェクトに特有なのは、 開発者を傷つけたり、がっかりさせることなく NO といいつつ、 -価値がある変更はリリースに取り込むようにする方法に知恵を絞っています。 +価値がある変更はリリースに取り込むようにする方法に知恵を絞っていることです。 たくさんの方法がありますが、いったん開発チームがそれらを重要な基準として注目すれば、 基準を満たす仕組みを作るのは簡単です。 -ここではもっとも両極端な、人気のあるやり方をふたつ簡単に説明しますが、 +ここではもっとも人気のある、両極端なやり方をふたつ簡単に説明しますが、 二つだけにすることで、プロジェクトが創造性をなくしてはいけません。 他のやり方はたくさんあるでしょうから、 -実際に使われているのを私が見たことがあるふたつだけに留めておきます。 +私が実際に使われているのを見たことがあるふたつだけに留めておきます。 /para !-- subsection == -- ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1236 - trunk/ja
Author: mumumu Date: Sun Oct 7 14:26:32 2007 New Revision: 1236 Log: - simple strategy translated. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sun Oct 7 14:26:32 2007 @@ -570,6 +570,7 @@ sect2 id=release-number-simple-strategy title単純なやり方/title +!-- paraMost projects have rules about what kinds of changes are allowed into a release if one is only incrementing the micro number, different rules for the minor number, and still different ones for the major @@ -580,33 +581,82 @@ of information release numbers should convey. This policy is adapted from the numbering system used by the APR project, see ulink url=http://apr.apache.org/versioning.html/./para +-- -orderedlist +para +ほとんどのプロジェクトには、たとえマイクロ番号をひとつ増やすだけの場合であっても、 +どんな修正をリリースに取り込むかについてのルールがあります。 +マイナー番号を増やす場合にはまた違ったルールがありますし、 +メジャー番号を増やす場合はさらにルールが違います。 +こうしたルールに決まった基準はありませんが、 +複数のプロジェクトでうまく使われてきたルールをここで説明します。 +あなたのプロジェクトでこのルールを単純に採用してもよいのですが、 +たとえそうしなくても、これはリリース番号が伝える情報をうまく表現する見本になります。 +このルールは、APRプロジェクトで使われているものです。 +ulink url=http://apr.apache.org/versioning.html/ を参照してください。 +/para - listitemparaChanges to the micro number only (that is, changes +orderedlist + listitem +!-- +paraChanges to the micro number only (that is, changes within the same minor line) must be both forward- and backward-compatible. That is, the changes should be bug fixes only, or very small enhancements to existing features. New features should not be introduced in a micro release./para +-- + +para +マイクロ番号だけに影響する（つまり、 +同じマイナーライン上で行う）変更は、 +前方互換性と後方互換性の両方がなければなりません。 +つまり、変更はバグ修正のみか、 +既にある機能に対するわずかな改善にとどめるべきです。 +新機能は、マイクロ番号を変更するリリースに取り込んではいけません。 +/para /listitem - listitemparaChanges to the minor number (that is, within the + listitem +!-- +paraChanges to the minor number (that is, within the same major line) must be backward-compatible, but not necessarily forward-compatible. It's normal to introduce new features in a minor release, but usually not too many new features at once./para +-- + +para +マイナー番号に影響する（つまり、 +同じメジャーラインで行う）変更には、 +後方互換性がなければなりませんが、前方互換性は必ずしも必要ありません。 +マイナー番号を変更するリリースでは、 +新機能を取り込むのが普通ですが、 +一度にたくさん取り込んだりはしません。 +/para /listitem - listitemparaChanges to the major number mark compatibility + listitem +!-- +paraChanges to the major number mark compatibility boundaries. A new major release can be forward- and backward-incompatible. A major release is expected to have new features, and may even have entire new feature sets./para +-- + +para +互換性を維持するには限度があり、 +メジャー番号に影響する変更がその境目となります。 +新しいメジャーリリースには前方互換性も後方互換性もありません。 +メジャーリリースには新機能が含まれているはずですが、 +全ての機能が新しくなっている場合さえあります。 +/para /listitem /orderedlist +!-- paraWhat firsttermbackward-compatible/firstterm and firsttermforward-compatible/firstterm mean, exactly, depends on what your software does, but in context they are usually not open to @@ -622,7 +672,25 @@ forward-compatible: clearly you can't now downgrade that client back to 2.5.4 and keep all the functionality it had at 2.6.0, since some of that functionality was new in 2.6.0./para +-- + +para +firstterm後方互換性/firstterm と firstterm前方互換性/firstterm の正確な意味は、 +ソフトウェアが実現することに依存しますが、解釈の余地がないのが普通です。 +たとえば、あなたのプロジェクトがクライアント/サーバ アプリケーションを作っているとすると、 +後方互換性 とは、サーバを 2.6.0 にアップグレードしても +既にあるバージョン 2.5.4 のクライアントが以前と異なる振舞い（もちろんバグを直した場合は別です）をしたり、 +動かなくなる機能があったりしてはいけないということです。 +一方、サーバを 2.6.0 にアップグレードするとともに、クライアントも2.6.0にすると、 +emphasis新しい/emphasis 機能がクライアントで使えるようになるかもしれませんが、 +2.5.4で使えていたクライアントの機能は 2.6.0 でどのように扱われるかわかりません。 +こういうことが起こると、このクライアントのアップグレードは前方互換性が emphasisない/emphasis ことになります。 +つまり、クライアントを 2.5.4 にダウングレードしても、 +2.6.0で使えていた全ての機能は使えないということになります。 +なぜなら、2.6.0 の機能には新機能が含まれているからです。 +/para +!-- paraThis is why micro releases are essentially for bug fixes only. They must remain compatible in both directions: if you upgrade from 2.5.3 to 2.5.4, then change your mind and downgrade back to 2.5.3, no @@ -630,7 +698,19 @@ would reappear after the downgrade, but you wouldn't lose any features, except insofar as the restored bugs prevent the use of some existing features./para +-- + +para +こういうわけで、マイクロリリースは本来バグフィックスのためだけに存在します。 +マイクロリリースでは前方、後方互換性の両方を維持しなければなりません。 +つまり、2.5.3 から
[ProducingOSS commit] r1217 - trunk/ja
Author: mumumu Date: Mon Sep 24 17:12:59 2007 New Revision: 1217 Log: - updated translation. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Mon Sep 24 17:12:59 2007 @@ -201,7 +201,7 @@ 次のふたつのセクションでは、 ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。 そこではふたつ例をあげていますが、いささか極度に理想的なものです。 -多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。 +多くのプロジェクトは、ふたつの状態の間のどこかに位置しているのです。 /para /sect1 @@ -299,7 +299,7 @@ 議論の最初の段階では、 自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。 人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。 -もちろん、優しい独裁者であっても必ず愚かな考えをたびたび述べてしまいます。 +もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。 だから、自分が悪い決断を下したときに、それを認識し、 受け入れる能力も必要になるのです。mdash; ですが、この資質は優れた開発者であれば、 @@ -487,7 +487,7 @@ -- para -firstterm合意/firstterm とは、単に皆が受け入れようと一致することです。 +firstterm合意/firstterm とは、皆が受け入れようと一致することです。 これはあいまいな状態ではありません。 誰かが合意に達したんじゃないかと提案し、 それに対して誰も反対を表明しない場合、あるグループは合意に達したといえます。 @@ -516,9 +516,9 @@ ある機能を追加するか、しないか、 プログラムのインターフェイスをどの程度厳密に文書化するか、などです。 合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。 -議論が終わるまでに、どの方向性をとるかに関して合意がよく成立します。 +議論が終わるまでに、どの方向性をとるかについて合意がよく成立します。 通常は議論を終了するという投稿をし、 -同時に何が決まるのかをまとめた上で合意に達したのではないかと暗に提案します。 +同時に何が決まるのかをまとめた上で、合意に達したよねと暗に提案します。 これが 待った！ 俺は反対だ。もう少し徹底的に話し合う必要があるね。 と言える最後の機会を与えているのです。 /para @@ -549,7 +549,7 @@ 他の開発者はわざわざ同意すると口に出して言ったりしません。 なぜなら黙っていることは合意することだからです。 コミットされた修正が、合意を得られないと判明した場合、 -プロジェクトでは単にそれがまだコミットされていないかのように議論されます。 +プロジェクトではそれがまだコミットされていないかのように議論されます。 このやり方がうまく行く理由は次の節で述べていきます。 /para @@ -686,7 +686,7 @@ 投票が打開策になります。 投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。 ここで、普段やっている技術的な議論をしてみると、 -これが結論を出す過程と意外によく合っていることが再びわかるでしょう。 +結論を出す手続きと意外によく合っていることが再びわかるでしょう。 投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。 こういう複雑な議論では、 firstterm仲裁人/firstterm の役割を果たす人が普通ひとりかふたりはいます。 @@ -727,7 +727,7 @@ 選択肢に対する正確な説明がないといった、 投票が正しいものかどうかを心配していることがありますが、 投票によって出る結論が自分の望むものに絶対ならないことを多分知っていて、 -単に投票を避けようとしている場合もあります。 +投票を避けようとしているだけの場合もあります。 この手の妨害行為をどう扱うかは、 phrase output=printedxref linkend=communications//phrase の、 xref linkend=difficult-people/ を参照してください。 @@ -760,7 +760,7 @@ 一回の投票で済みます。認定投票と他の投票システムの詳細については、 ulink url=http://en.wikipedia.org/wiki/Voting_system#List_of_systems/ を参照してください。 しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。 -（なぜなら、当然のことながら、 +（当然、 投票システムを決めるのにどの投票システムを使うかを議論することになるからです！） 認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。 mdash; つまり、投票システムはできるだけ公平であるべきということです。 @@ -808,18 +808,18 @@ -- para -投票で最も難しいのは、いつ投票を行うかということです。一般的には、 +投票で最も難しいのは、いつ投票を行うかです。一般的には、 投票に実際に踏み切ることは滅多にすべきではありませんmdash; つまり、他のあらゆる手段が失敗したときの最後の手段にすべきです。 投票が議論を解決する素晴らしい手段だと看做さないでください。 -実際、そうではありません。投票は議論を終結させ、 +実際、そうではないのです。投票は議論を終結させ、 それによって問題について創造的に考えることもやめさせてしまうのです。 議論が続いている限り、皆が好む新しい解決策を誰かが思い付く可能性があります。 これは驚くほどたびたび起こります。活発な議論は、 問題について新しい考え方を生み出しますし、結局皆を満足させる提案にも繋がります。 たとえ新しい提案が生まれなくても、投票を行うよりは、 -妥協案を仲介してもらった方が通常はまだよいです。 -妥協したあとは、皆ちょっと悲しい思いをします。 +妥協案を仲介してもらった方が通常はまだマシです。 +妥協したあとは、皆がちょっと悲しい思いをします。 一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。 政治的な観点からは、前者の方が好ましいといえます。 なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。 @@ -848,15 +848,15 @@ para 投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。 しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、 -頭数で問題を解決してしまいます。オープンソースプロジェクトで経験を積めば積むほど、 +頭数で問題を解決してしまいます。私は、オープンソースプロジェクトで経験を積めば積むほど、 人々が問題を投票によって解決したがらなくなるのがわかってきました。 むしろ、以前考えたこともない解決策を探ったり、 -もともと計画よりも厳しい妥協をしようとします。 +もともとの計画よりも厳しい妥協をしようとします。 早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、 -まだ投票を実施する段階ではないと思うよ。といって、何故かを説明することです。 +まだ投票を実施する段階ではないと思うよ。 といって、何故かを説明することです。 別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。 その反応が明らかに一方に偏っていたら、 -正式に投票を行うことを避けるために、積極的に妥協することを人々に促すことになるでしょう。 +正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。 もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、 新しい解決策や、以前の提案に基づいた新しい視点を示すことです。 /para @@ -874,7 +874,7 @@ para まれなケースとして、示された全ての妥協案は、 -妥協をしていない全ての案よりも劣っていることで全員が一致することがあります。 +妥協していない全ての案よりも劣っていることで全員が一致することがあります。 この場合、投票を実施することに反対しにくくなります。なぜなら、 投票の方がより優れた解決に繋がる可能性がありますし、 どのような結果になっても全員が過度に悲しい思いをすることはないからです。 @@ -957,7 +957,7 @@ メーリングリスト上で破壊的な発言をしたり、 プロジェクトを妨害する傾向がある人がいる場合は、 プロジェクトはたとえその人が技術的に優れていたとしても、 -コミット権限を与える際には注意する必要があります。 +コミット権限を与える際に注意する必要があります。 /para !-- @@ -993,7 +993,7 @@ para 完全なコミット権限にせよ、限定的なものにせよ、 -新しいコミッタを選ぶのには投票システムそのものを使うべきですが、 +新しいコミッタを選ぶには投票システムを使うべきですが、 この場合は秘密投票が適切になるまれな事例のひとつです。 コミッタになる可能性がある人について、メーリングリストで投票を行うことはできません。 なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。 @@ -1015,7 +1015,7 @@ もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、 受け入れるか拒むかの回答を明示的に行うしかありません。 仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。 -たとえば 開発者チームは君のパッチを気に入っているけれども、量がまだ十分でなない とか、 +たと
[ProducingOSS commit] r1218 - trunk/ja
Author: mumumu Date: Mon Sep 24 19:02:38 2007 New Revision: 1218 Log: - translated part of Writing It All Down Section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Mon Sep 24 19:02:38 2007 @@ -1253,6 +1253,7 @@ 明らかになってきた事柄を反映させた形で、文書を改訂することができます。 /para +!-- paraDon't try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never @@ -1271,7 +1272,31 @@ emphasishow/emphasis to write good code, such as rules about documenting every API in a certain format, then those guidelines should be written down as completely as possible./para +-- + +para +文書を包括的なものにするのはやめましょう。 +どんな文書でも、プロジェクトに参加するのに必要なことを全て網羅することはできません。 +プロジェクトで生まれる多くの規約は、ずっと暗黙のもので、 +決して明示的に言及されることがないにもかかわらず、 +メンバー全員がかたくなに守っているものなのです。 +単に当り前過ぎるので言及されないものもありますし、 +重要だけど曖昧なのでただ避けているだけのものもあります。 +たとえば、メーリングリストでは礼儀正しくし、他人を尊重しましょう。 +また、フレームウォーを始めてはいけません。 とか、 +綺麗で、読みやすくバグのないコードを書きましょう。 といったことをガイドラインに書いても意味がありません。 +もちろん、これらは望ましいことではありますが、 +これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。 +メーリングリスト上で失礼な発言をしたり、バグだらけのコードを書いている人がいたとして、 +彼らはプロジェクトのガイドラインにやめろと書いてあるからといってやめはしないでしょう。 +こういう状況は包括的なガイドラインであらかじめ対処するものではなく、 +問題が起きたときに対処すべきものなのです。 +一方で、あるフォーマットですべてのAPIを文書化するルールのような +よいコードの書き方に関するガイドラインがプロジェクトにある場合は、 +できる限り完全なものを書いておくべきです。 +/para +!-- paraA good way to determine what to include is to base the document on the questions that newcomers ask most often, and on the complaints experienced developers make most often. This doesn't necessarily mean @@ -1279,6 +1304,16 @@ coherent narrative structure than FAQs can offer. But it should follow the same reality-based principle of addressing the issues that actually arise, rather than those you anticipate might arise./para +-- + +para +ガイドラインに盛りこむ内容を決めるよい方法は、初心者がよく尋ねる質問や、 +経験豊富な開発者がよくこぼす不満に関する文書を基にすることです。 +これは必ずしも FAQ を基にすべきというわけではありませんmdash; +ガイドラインは、FAQ よりわかりやすい物語風の構造が必要になるでしょうが、 +FAQ と同じく、将来起こりうる問題よりも、 +実際に起こった問題に取り組むという現実的な原則に従うべきです。 +/para paraIf the project is a benevolent dictatorship, or has officers endowed with special powers (president, chair, whatever), then the ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1195 - trunk/ja
Author: mumumu Date: Sat Sep 22 04:36:04 2007 New Revision: 1195 Log: - self review part 2. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 04:36:04 2007 @@ -16,7 +16,8 @@ -- para -通常、フリーソフトウェアについて人々がする最初の質問は プロジェクトはどういう仕組みで動くの？ +フリーソフトウェアについて人々がよくする最初の質問は、 +プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？ といったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 @@ -42,8 +43,8 @@ -- para -この章では、 -成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。 +この章では、成功しているオープンソースプロジェクトに共通している、 +基本的な仕組みを説明します。 成功している というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生き残る力が強いことを言います。 新しいコードや開発者を受け入れたり、 @@ -56,7 +57,7 @@ 技術的に成功することは難しくありません。 しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、 プロジェクトが初期段階で成功して膨張したり、 -カリスマ的な人がいなくなったときに、対処できないかもしれません。 +カリスマ的な人がいなくなったときに、対応できないかもしれません。 /para !-- @@ -75,11 +76,11 @@ -- para -構造的な基盤という意味で、プロジェクトを成功させる方法はたくさんあります。 +オープンソースプロジェクトを成功させる方法はたくさんあります。 議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、 新しい機能を企画するなどの、 -型にはまった管理の仕組みに関するものがあります。 -一方で、形として表れないものですが、 +型にはまった統治の仕組みもあれば、 +形になって表れないものとして、 メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、 より意識的に自制することも含まれます。 プロジェクトは、 @@ -88,7 +89,7 @@ これらの方法は、中央集権的なプロジェクトより、 自発的に成長するプロジェクトで重要になります。 自発的に成長するプロジェクトでは、少なくともしばらくは、 -よくないことが全体に影響することを皆が意識しているからです。 +よくないことが全体に影響することを参加する人が意識しているからです。 /para sect1 id=forkability @@ -111,7 +112,7 @@ -- para -開発者をフリーソフトウェアプロジェクトにつなぎ止め、 +開発者をフリーソフトウェアプロジェクトに繋ぎ止め、 必要な時に妥協してもらうのに不可欠な要素は、 コードが firstterm派生する/firstterm ことです。 逆説的なのは、コードが派生する emphasis可能性/emphasis の方が、 @@ -167,7 +168,7 @@ そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、 重要な決定をする段になると民主主義の仕組みを使います。 コードを複製できるということは、コードを派生できるということです。 -コードを派生できるということは、妥協を生むことを意味しています。 +コードを派生できるということは、それを避けるために合意が形成されることを意味しています。 全員がひとりのリーダーに従うこと（もっとも有名な例が、Linux kernel 開発の Linus Torvalds です）もあるかもしれませんが、 これは 完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを emphasis選んでいる/emphasis からです。 独裁者がプロジェクトを魔法のように支配しているわけではないのです。 @@ -197,7 +198,7 @@ プロジェクトを統率するやり方に重大な違いがあるわけではありません。 決断をするたびに、誰かコードを派生させようと思ってる人いる？ と質問したくはないはずです。 そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。 -次のふたつの節では、 +次のふたつのセクションでは、 ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。 そこではふたつ例をあげていますが、いささか極度に理想的なものです。 多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。 @@ -252,14 +253,14 @@ 優しい独裁者 （略して firsttermBD/firstterm ともいいます）という言葉は、 こうした役割に対して標準的に使われる用語ですが、 むしろ コミュニティーが認めた調停者 もしくは 審判 と考えた方がいいでしょう。 -一般的に、優しい独裁者が実際に全ての、 +一般的には、優しい独裁者が実際に全ての、 もしくはほとんどの決定を行っているわけではありません。 ある人がプロジェクトの全ての領域に渡って、 優れた決断を一貫して行う十分な技能があることはまれです。 -そして優れた開発者は、プロジェクトの方向性に影響を及ぼすことがなければ、 -結局プロジェクトに留まり続けたりはしません。 +そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、 +結局プロジェクトから去ってしまいます。 よって、優しい独裁者は普通多く指示を出したりはしません。 -むしろ、いつでも可能な限り、議論や実験を通じて働くのを開発者に任せておきます。 +むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。 優しい独裁者は議論そのものには参加しますが、普通の開発者として、 自分より優れた技能を持つメンテナの領域では、たびたび彼らに従います。 結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に emphasis望んでいる/emphasis 場合だけ、 @@ -298,12 +299,12 @@ 議論の最初の段階では、 自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。 人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。 -もちろん、優しい独裁者もたびたび愚かな考えを述べることも避けられません。 +もちろん、優しい独裁者であっても必ず愚かな考えをたびたび述べてしまいます。 だから、自分が悪い決断を下したときに、それを認識し、 受け入れる能力も必要になるのです。mdash; ですが、この資質は優れた開発者であれば、 特にプロジェクトに長い間留まっている人であればなおさら emphasis誰でも/emphasis 持っているはずの資質にすぎません。 -しかし、優しい独裁者が違う点は、 +しかし、優しい独裁者が違うのは、 自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、 たびたび間違いを犯す余裕があることです。 年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。 @@ -470,8 +471,7 @@ para こうした仕組みがどう機能するかを詳細に見ていくと、 -中身は変化に富んでいますが、 -共通した要素が二つあります。 +中身は変化に富んでいますが、共通した要素が二つあります。 ひとつは、グループはほとんどいつも合意に基づいて動くこと。 ふたつめは、合意に達しないときに投票の仕組みを使うことです。 /para @@ -512,9 +512,9 @@ para プロジェクトで交わされるほとんどの会話は技術的な話題です。 -たとえば、バグを直す正しい方法に関するものとか、 +たとえば、正しくバグを直す方法とか、 ある機能を追加するか、しないか、 -プログラムのインターフェイスをどの程度厳密に文書化するか、などといったものです。 +プログラムのインターフェイスをどの程度厳密に文書化するか、などです。 合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。 議論が終わるまでに、どの方向性をとるかに関して合意がよく成立します。 通常は議論を終了するという投稿をし、 @@ -549,7 +549,7 @@ 他の開発者はわざわざ同意すると口に出して言ったりしません。 なぜなら黙っていることは合意することだからです。 コミットされた修正が、合意を得られないと判明した場合、 -プロジェクトでは単にまだそれがコミットされていないかのように議論されます。 +プロジェクトでは単にそれがまだコミットされていないかのように議論されます。 このやり方がうまく行く理由は次の節で述べていきます。 /para ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1196 - trunk/ja
Author: mumumu Date: Sat Sep 22 06:13:53 2007 New Revision: 1196 Log: - partially translated vote section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 06:13:53 2007 @@ -655,6 +655,7 @@ sect2 id=voting title合意に至らなければ投票する/title +!-- paraInevitably, some debates just won't consense. When all other means of breaking a deadlock fail, the solution is to vote. But before a vote can be taken, there must be a clear set of choices on @@ -677,6 +678,31 @@ fairly represent others' views, and not let their partisan sentiments prevent them from summarizing the state of the debate in a neutral fashion./para +-- + +para +議論によっては、結論がでないことが必ずあります。 +行き詰まった状態を打開するあらゆる手段が失敗に終わった場合、 +投票が打開策になります。 +投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。 +ここで、普段やっている技術的な議論をしてみると、 +これが結論を出す過程と意外によく合っていることが再びわかるでしょう。 +投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。 +こういう複雑な議論では、 +firstterm仲裁人/firstterm の役割を果たす人が普通ひとりかふたりはいます。 +彼らは定期的にさまざまな主張をまとめたものをポストし、 +反対（賛成）意見の核がどこにあるのかを追いかけています。 +こうしたまとめは、議論がどの位進んでいるのかを知ったり、 +どういう問題に取り組んでいるのかを覚えておくのに役立ちます。 +また、実際に投票が必要になった場合に、投票用紙のひな型として役立つかもしれません。 +仲裁人が仕事をうまくこなせば、 +時が来れば皆に投票しましょうと呼びかけることもできるでしょうし、 +プロジェクトは彼らが作ったまとめをベースにした投票用紙を使うことができるでしょう。 +仲裁人自身は、議論に参加していても構いません。 +つまり、対立する人の意見を理解し、中立的に表現でき、 +自分の同志の気持ちが議論を中立的にまとめるのを妨げなければ、 +賛成、反対の立場を超越した立場にいる必要はないのです。 +/para paraThe actual content of the ballot is usually not controversial. By the time matters reach a vote, the disagreement has usually boiled ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1198 - trunk/ja
Author: mumumu Date: Sat Sep 22 08:58:25 2007 New Revision: 1198 Log: - translated When Consensus Cannot Be Reached, Vote section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 08:58:25 2007 @@ -733,6 +733,7 @@ xref linkend=difficult-people/ を参照してください。 /para +!-- paraRemember to specify the voting system, as there are many different kinds, and people might make wrong assumptions about which procedure is being used. A good choice in most cases is @@ -747,12 +748,41 @@ which voting system to use to decide the voting system!). One reason approval voting is a good choice is that it's very hard for anyone to object tomdash;it's about as fair as a voting system can be./para +-- + +para +投票システムを必ず決めるようにしましょう。なぜなら、 +投票システムにはたくさんの種類があり、どういった手続きがとられるのかについて +参加者が間違った想定をしている可能性があるからです。 +ほとんどの場合に適しているのは firstterm認定投票/firstterm です。 +このシステムでは投票者が自分が好む選択肢をできるだけ多く投票できます。 +認定投票は説明するのも、得票数を数えるのも簡単ですし、他の方法と異なり、 +一回の投票で済みます。認定投票と他の投票システムの詳細については、 +ulink url=http://en.wikipedia.org/wiki/Voting_system#List_of_systems/ を参照してください。 +しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。 +（なぜなら、当然のことながら、 +投票システムを決めるのにどの投票システムを使うかを議論することになるからです！） +認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。 +mdash; つまり、投票システムはできるだけ公平であるべきということです。 +/para +!-- paraFinally, conduct votes in public. There is no need for secrecy or anonymity in a vote on matters that have been debated publicly anyway. Have each participant post her votes to the project mailing list, so that any observer can tally and check the results for herself, and so that everything is recorded in the archives./para +-- + +para +最後に、投票は公開の場で行いましょう。 +どちらにせよ、公開の場で議論した問題について、 +秘密投票にしたり、匿名投票にしたりする必要はありません。 +オブザーバが投票を記録し、結果をチェックできるように、 +そしてすべてをアーカイブに記録するために、 +投票の参加者には、 +プロジェクトのメーリングリストに自分の投票をポストさせるようにしましょう。 +/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1200 - trunk/ja
Author: mumumu Date: Sat Sep 22 11:47:38 2007 New Revision: 1200 Log: - When to Vote section complete. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 11:47:38 2007 @@ -822,10 +822,11 @@ 妥協したあとは、皆ちょっと悲しい思いをします。 一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。 政治的な観点からは、前者の方が好ましいといえます。 -なぜなら、少なくともひとりひとりが自分が悲しい思いに対して対価を支払っているからです。 +なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。 満足はしないかもしれませんが、それは他の誰もが同じなのです。 /para +!-- paraVoting's main advantage is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion. The @@ -842,7 +843,25 @@ solution, or a new viewpoint on an old suggestion, so that people re-engage with the issues instead of merely repeating the same arguments./para +-- + +para +投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。 +しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、 +頭数で問題を解決してしまいます。オープンソースプロジェクトで経験を積めば積むほど、 +人々が問題を投票によって解決したがらなくなるのがわかってきました。 +むしろ、以前考えたこともない解決策を探ったり、 +もともと計画よりも厳しい妥協をしようとします。 +早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、 +まだ投票を実施する段階ではないと思うよ。といって、何故かを説明することです。 +別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。 +その反応が明らかに一方に偏っていたら、 +正式に投票を行うことを避けるために、積極的に妥協することを人々に促すことになるでしょう。 +もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、 +新しい解決策や、以前の提案に基づいた新しい視点を示すことです。 +/para +!-- paraIn certain rare cases, everyone may agree that all the compromise solutions are worse than any of the non-compromise ones. When that happens, voting is less objectionable, both because it is @@ -851,7 +870,20 @@ should not be rushed. The discussion leading up to a vote is what educates the electorate, so stopping that discussion early can lower the quality of the result./para +-- +para +まれなケースとして、示された全ての妥協案は、 +妥協をしていない全ての案よりも劣っていることで全員が一致することがあります。 +この場合、投票を実施することに反対しにくくなります。なぜなら、 +投票の方がより優れた解決に繋がる可能性がありますし、 +どのような結果になっても全員が過度に悲しい思いをすることはないからです。 +たとえそうであっても、投票を急ぐべきではありません。 +投票に至るまでの議論は有権者にいろいろなことを教えるので、 +議論を早い段階でやめてしまうと、投票の結果出てくるものの質が悪くなるかもしれません。 +/para + +!-- para(Note that this advice to be reluctant to call votes does not apply to the change-inclusion voting described in xref linkend=stabilizing-a-release/phrase output=printed @@ -859,6 +891,17 @@ is more of a communications mechanism, a means of registering one's involvement in the change review process so that everyone can tell how much review a given change has received.)/para +-- + +para +（投票をしたがるなというアドバイスは、 +phrase output=printedxref linkend=development-cycle//phrase の xref linkend=stabilizing-a-release/ で説明している、 +ソースコードに大幅な変更を加える投票には当てはまりません。 +そこでは、投票は対話のメカニズムとして働き、 +有権者を変更をレビューする手続きに参加させる手段となります。 +それによって、 +有権者は与えられた変更がどの程度のレビューを経ているのかを区別することができるのです。） +/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1201 - trunk/ja
Author: mumumu Date: Sat Sep 22 13:39:57 2007 New Revision: 1201 Log: - translated part of Who votes? section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 13:39:57 2007 @@ -908,11 +908,22 @@ sect2 id=electorate title誰が投票するのか?/title +!-- paraHaving a voting system raises the question of electorate: who gets to vote? This has the potential to be a sensitive issue, because it forces the project to officially recognize some people as being more involved, or as having better judgement, than others./para +-- + +para +投票システムは、有権者に関する疑問を提起します。 +誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。 +なぜなら、どの人が熱心にプロジェクトに参加しているかとか、 +どの人がよりよい判断を下せるか、 +ということをプロジェクトに公式に認めさせることになるからです。 +/para +!-- paraThe best solution is to simply take an existing distinction, commit access, and attach voting privileges to it. In projects that offer both full and partial commit access, the question of whether @@ -927,6 +938,27 @@ shows disruptive or obstructionist tendencies on the mailing list, the group should be very cautious about making him a committer, even if the person is technically skilled./para +-- + +para +一番よいのは、既にある権限の区別、 +つまりコミット権限を単純に利用し、その権限に投票権限も付加することです。 +完全なコミット権限と、限定的なコミット権限を提供しているプロジェクトで、 +限定的なコミット権限を持つ人に投票権を与えるかどうかは、 +コミット権限を与える手続きがどのようなものかに大きく依存します。 +たくさんのサードパーティーのツールをリポジトリで管理させるようなやり方で、 +プロジェクトがコミット権限を気前よく配分している場合、 +限定的なコミット権限が単にリポジトリにコミットする権限だけで、 +投票権限はないことを明確にすべきです。 +逆に考えると、同じことが当然当てはまります。 +つまり、完全なコミット権限を持つ人には投票権限もあるのだから、 +彼らはプログラマとしてではなく、投票権限のあるメンバとして選ばれなければならない。 +ということになります。 +メーリングリスト上で破壊的な発言をしたり、 +プロジェクトを妨害する傾向がある人がいる場合は、 +プロジェクトはたとえその人が技術的に優れていたとしても、 +コミット権限を与える際に注意する必要があります。 +/para paraThe voting system itself should be used to choose new committers, both full and partial. But here is one of the rare ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1202 - trunk/ja
Author: mumumu Date: Sat Sep 22 15:13:31 2007 New Revision: 1202 Log: - Who Votes? section complete. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 15:13:31 2007 @@ -960,6 +960,7 @@ コミット権限を与える際に注意する必要があります。 /para +!-- paraThe voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about @@ -988,7 +989,42 @@ change over time, though. Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail./para +-- + +para +完全なコミット権限にせよ、限定的なものにせよ、 +新しいコミッタを選ぶのに、投票システムそのものを使うべきですが、 +この場合は秘密投票が適切になるまれな事例のひとつです。 +コミッタになる可能性がある人について、メーリングリストで投票を行うことはできません。 +なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。 +代わりに普通使われるのは、 +コミッタのみで構成されるプライベートなメーリングリストに、 +コミット権限を与える提案をし、 +それに対して既にいるコミッタが投票する方法です。 +他のコミッタはそこで行われる議論がプライベートなことを知っているので、 +自分の思うところを自由に述べていきます。 +そこで反対意見が出ないために、投票が必要ないこともあります。 +他のコミッタに反対意見を述べるチャンスを必ず与えるために２、３日待ったあと、 +提案者はコミッタになる候補者にメールしてコミット権限を与えます。 +反対意見があった場合は、他の問題と同じように議論が行われ、おそらく投票が行われるでしょう。 +このプロセスをオープンかつ率直なものにするにせよ、 +議論はとにかく非公開で行うべきです。 +コミット権限を与えようと考えている人が、何が起きているのかを知っていて、 +権限を貰えなかった場合、自分は投票権も失ったんだと決めつけてしまったり、 +傷ついてしまったりする可能性もあるでしょう。 +もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、 +受け入れるか拒むかの回答を明示的に行うしかありません。 +仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。 +たとえば 開発者チームは君のパッチを気に入っているけれども、量がまだ十分でなない とか、 +開発チームは君のパッチを全て高く評価しているけど、適用する前にかなり調整が必要なんだ。 +だからコミット権限を与えるのが好ましいと思えない。 +このことは時間をかけて改善して欲しいと願っている。 という感じです。 +ただ、その人との信頼関係の度合によりますが、 +あなたの発言が相手にショックを与える可能性があることを忘れないようにしましょう。 +メールを書くときは、相手の視点からメールを眺めるようにしましょう。 +/para +!-- paraBecause adding a new committer is more consequential than most other one-time decisions, some projects have special requirements for the vote. For example, they may require that the proposal receive at @@ -1001,7 +1037,21 @@ linkend=committers/phrase output=printed in xref linkend=managing-volunteers//phrase for more on the non-voting aspects of adding and removing committers./para +-- +para +新しいコミッタを加えることは、 +他のほとんどの一度限りの決定よりもより重大なので、 +プロジェクトによっては投票に特別な要件を課すところもあります。 +たとえば、その提案には 少なくとも emphasisn/emphasis 票の賛成票が必須で、 +反対票があってはいけないとか、圧倒的多数の賛成票が必須、といったものです。 +正確な賛成票の数は重要ではありません。 +中心となる考え方は、開発チームが新しいコミッタを加えるのに慎重であるべき、というものです。 +コミット権限を emphasis奪う/emphasis 場合にも、投票には似たような、 +あるいはもっと厳格な要件が必要です。 +まぁしかし、こんなルールを必要としないのが望ましいのですが。 +コミッタ権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、 +phrase output=printedxref linkend=managing-volunteers//phrase の xref linkend=committers/ を参照してください。 /sect2 sect2 id=polls ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1203 - trunk/ja
Author: mumumu Date: Sat Sep 22 15:16:57 2007 New Revision: 1203 Log: - xml syntax error correct, sorry. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 15:16:57 2007 @@ -957,7 +957,7 @@ メーリングリスト上で破壊的な発言をしたり、 プロジェクトを妨害する傾向がある人がいる場合は、 プロジェクトはたとえその人が技術的に優れていたとしても、 -コミット権限を与える際に注意する必要があります。 +コミット権限を与える際には注意する必要があります。 /para !-- @@ -1052,6 +1052,8 @@ まぁしかし、こんなルールを必要としないのが望ましいのですが。 コミッタ権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、 phrase output=printedxref linkend=managing-volunteers//phrase の xref linkend=committers/ を参照してください。 +/para + /sect2 sect2 id=polls ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1204 - trunk/ja
Author: mumumu Date: Sat Sep 22 15:20:48 2007 New Revision: 1204 Log: - self review. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 22 15:20:48 2007 @@ -993,7 +993,7 @@ para 完全なコミット権限にせよ、限定的なものにせよ、 -新しいコミッタを選ぶのに、投票システムそのものを使うべきですが、 +新しいコミッタを選ぶのには投票システムそのものを使うべきですが、 この場合は秘密投票が適切になるまれな事例のひとつです。 コミッタになる可能性がある人について、メーリングリストで投票を行うことはできません。 なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。 @@ -1011,7 +1011,7 @@ 議論はとにかく非公開で行うべきです。 コミット権限を与えようと考えている人が、何が起きているのかを知っていて、 権限を貰えなかった場合、自分は投票権も失ったんだと決めつけてしまったり、 -傷ついてしまったりする可能性もあるでしょう。 +傷ついてしまう可能性もあるでしょう。 もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、 受け入れるか拒むかの回答を明示的に行うしかありません。 仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。 @@ -1020,7 +1020,7 @@ だからコミット権限を与えるのが好ましいと思えない。 このことは時間をかけて改善して欲しいと願っている。 という感じです。 ただ、その人との信頼関係の度合によりますが、 -あなたの発言が相手にショックを与える可能性があることを忘れないようにしましょう。 +あなたの発言が相手にショックを与える可能性があることを忘れないように。 メールを書くときは、相手の視点からメールを眺めるようにしましょう。 /para ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1192 - trunk/ja
Author: mumumu Date: Mon Sep 17 16:14:37 2007 New Revision: 1192 Log: - self review. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Mon Sep 17 16:14:37 2007 @@ -18,7 +18,7 @@ para 通常、フリーソフトウェアについて人々がする最初の質問は プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？ といったものです。 -私は、実力主義や、協力の精神、自己説明的なコード、 などについて当たり障りなく答えて、 +私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 @@ -42,15 +42,17 @@ -- para -この章では、成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。 -成功している というのは、ただ技術的に質が高いだけではなく、 +この章では、 +成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。 +成功している というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生き残る力が強いことを言います。 新しいコードや開発者を受け入れたり、 バグレポートに素早く反応することを継続できていれば、 プロジェクトは健全に運営されているといえます。 -特定の個人やスポンサーにも依存しなくてもプロジェクトを続けられれば、 -生き残る力が強いといえます。mdash; プロジェクトを立ち上げたメンバー全員が他に移ったとしても、 -プロジェクトが存続するか、といったことを考えてみてください。 +特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、 +生き残る力が強いといえます。mdash; +プロジェクトを立ち上げたメンバー全員が他に移ったとしても、 +プロジェクトが生き残る可能性があるかを考えてみてください。 技術的に成功することは難しくありません。 しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、 プロジェクトが初期段階で成功して膨張したり、 @@ -73,19 +75,20 @@ -- para -これらの観点から成功を収める方法はたくさんあります。 +構造的な基盤という意味で、プロジェクトを成功させる方法はたくさんあります。 議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、 新しい機能を企画するなどの、 -型にはまった管理の仕組みに関するものもあれば、 -型にはまっているものではありませんが、 -foreignphraseデファクト/foreignphrase な統率の方法だと人々が信頼できる公平な雰囲気を作り出すために、 +型にはまった管理の仕組みに関するものがあります。 +一方で、形として表れないものですが、 +メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、 より意識的に自制することも含まれます。 -参加している人達がよく理解している習慣や手続きに支えられて、 -組織がずっと続いていくという意味で、 -どちらのやり方も行き着くところは同じです。 -これらの方法は、中央集権的な組織より、自然に発展していく組織でより重要になります。 -なぜならそうした組織では、 -よくないものが全体に影響することを少なくともしばらくは皆が意識しているからです。 +プロジェクトは、 +参加する人達がよく理解している習慣や手続きに支えられて存続するという意味で、 +どちらも行き着くところは同じです。 +これらの方法は、中央集権的なプロジェクトより、 +自発的に成長するプロジェクトで重要になります。 +自発的に成長するプロジェクトでは、少なくともしばらくは、 +よくないことが全体に影響することを皆が意識しているからです。 /para sect1 id=forkability @@ -110,7 +113,7 @@ para 開発者をフリーソフトウェアプロジェクトにつなぎ止め、 必要な時に妥協してもらうのに不可欠な要素は、 -コードを firstterm派生させることができる/firstterm ことです。 +コードが firstterm派生する/firstterm ことです。 逆説的なのは、コードが派生する emphasis可能性/emphasis の方が、 まれながら実際に派生することよりも、 フリーソフトウェアプロジェクトにとって大きな力になるということです。 @@ -135,9 +138,9 @@ para コードが派生すること、いやむしろ派生する可能性と言った方がよいでしょう。 -この可能性こそが、フリーソフトウェアプロジェクトには本当の意味での独裁者が存在しない理由になっています。 +この可能性こそが、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由になっています。 これはオープンソースプロジェクトで 独裁者 とか 暴君 と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。 -しかし、この手の 圧政 という言葉は特別なもので、伝統的に理解されている圧政の意味とは違うものです。 +しかし、この手の 暴政 という言葉は特別なもので、伝統的に理解されている暴政の意味とは違うものです。 いつでも自分の王国をコピーでき、 いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。 そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？ するはずがないですよね。 @@ -189,11 +192,14 @@ -- para -しかし、コードを派生できることがプロジェクトで権力を行使することに歯止めをかけているからといって、 +しかし、 +コードを派生できることがプロジェクトで権力を行使することに歯止めをかけているからといって、 プロジェクトを統率するやり方に重大な違いがあるわけではありません。 決断をするたびに、誰かコードを派生させようと思ってる人いる？ と質問したくはないはずです。 -そんなことをすればすぐに疲れてしまい、仕事をすると活力が失われていきます。 - 次のふたつの節では、ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。そこではふたつ例をあげていますが、いささか極度に理想的なものです。 +そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。 +次のふたつの節では、 +ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。 +そこではふたつ例をあげていますが、いささか極度に理想的なものです。 多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。 /para @@ -216,7 +222,7 @@ firstterm優しい独裁者/firstterm モデルとは、 正確には次のようなものです。 つまり、最終的な決断を行う権限が、 -人柄や経験が優れているという理由で、 +人格や経験が優れているという理由で、 賢明に権限を行使できるひとりの人に委ねられていることです。 /para @@ -243,19 +249,20 @@ -- para -優しい独裁者 （または略して firsttermBD/firstterm ともいいます）という言葉は、 +優しい独裁者 （略して firsttermBD/firstterm ともいいます）という言葉は、 こうした役割に対して標準的に使われる用語ですが、 むしろ コミュニティーが認めた調停者 もしくは 審判 と考えた方がいいでしょう。 -一般的に、優しい独裁者が実際に全ての、もしくはほとんどの決定を行っているわけではありません。 +一般的に、優しい独裁者が実際に全ての、 +もしくはほとんどの決定を行っているわけではありません。 ある人がプロジェクトの全ての領域に渡って、 優れた決断を一貫して行う十分な技能があることはまれです。 そして優れた開発者は、プロジェクトの方向性に影響を及ぼすことがなければ、 結局プロジェクトに留まり続けたりはしません。 -それゆえに、優しい独裁者は普通多く指示を出したりはしません。 -むしろ、いつでも可能な限り、議論や実験を通して働くのは開発者に任せておきます。 -彼らは議論そのものには参加しますが、普通の開発者として、 +よって、優しい独裁者は普通多く指示を出したりはしません。 +むしろ、いつでも可能な限り、議論や実験を通じて働くのを開発者に任せておきます。 +優しい独裁者は議論そのものには参加しますが、普通の開発者として、 自分より優れた技能を持つメンテナの領域では、たびたび彼らに従います。 -結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを emphasis望んでいる/emphasis のが明らかな場合にだけ、 +結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に emphasis望んでいる/emphasis 場合だけ、 彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。 命令することで決定するのを我慢するのは、 成功している優しい独裁者に事実上共通する特性です。 @@ -289,18 +296,19 @@ まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、 これは言い替えれば自制を働かせるということです。 議論の最初の段階では、 -自分の意見に反対するのは的外れだと他の人が思っていると確信して意見や結論を述べてはいけません。 +自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。 人々には、たとえ
[ProducingOSS commit] r1170 - trunk/ja
Author: mumumu Date: Sat Sep 15 08:44:58 2007 New Revision: 1170 Log: - translated forkability section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 08:44:58 2007 @@ -16,15 +16,16 @@ -- para -通常、フリーソフトウェアについて人々がする最初の質問は プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？ といったものです。 -私は、実力主義や、協力の精神、自己説明的なコード、 -などについて当たり障りなく答えて、いつも釈然としない思いがします。 -実のところ、こうした質問に答えるのは簡単ではありません。 -実力主義、協力、そして動くコードは全て答えの一部ではありますが、 +通常、フリーソフトウェアについて人々がする最初の質問は プロジェクトはどういう仕組みで動くの？ +プロジェクトを維持しているものは何？ 誰に決定権があるの？ といったものです。 +私は、実力主義や、協力の精神、自己説明的なコード、 などについて当たり障りなく答えて、 +いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 +実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 -プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 +プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 /para +!-- paraThis chapter tries to show the structural underpinnings successful projects have in common. I mean successful not just in terms of technical quality, but also operational health and @@ -38,7 +39,25 @@ robust developer base and social foundation, a project may be unable to handle the growth that initial success brings, or the departure of charismatic individuals./para +-- +para +この章では、成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。 +成功している というのは、ただ技術的に質が高いだけではなく、 +プロジェクトが健全に運営されており、生き残る力が強いことを言います。 +新しいコードや開発者を受け入れたり、 +バグレポートに素早く反応することを継続できていれば、 +プロジェクトは健全に運営されているといえます。 +特定の個人やスポンサーにも依存しなくてもプロジェクトを続けられれば、 +生き残る力が強いといえます。mdash; プロジェクトを立ち上げたメンバー全員が他に移ったとしても、 +プロジェクトが存続するか、といったことを考えてみてください。 +技術的に成功することは難しくありません。 +しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、 +プロジェクトが初期段階で成功して膨張したり、 +カリスマ的な人がいなくなったときに、対処できないかもしれません。 +/para + +!-- paraThere are various ways to achieve this kind of success. Some involve a formal governance structure, by which debates are resolved, new developers are invited in (and sometimes out), new features @@ -51,10 +70,28 @@ more important in self-organizing systems than in centrally-controlled ones, because in self-organizing systems, everyone is conscious that a few bad apples can spoil the whole barrel, at least for a while./para +-- + +para +これらの観点から成功を収める方法はたくさんあります。 +議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、 +新しい機能を企画するなどの、 +型にはまった管理の仕組みに関するものもあれば、 +型にはまっているものではありませんが、 +foreignphraseデファクト/foreignphrase な統率の方法だと人々が信頼できる公平な雰囲気を作り出すために、 +より意識的に自制することも含まれます。 +参加している人達がよく理解している習慣や手続きに支えられて、 +組織がずっと続いていくという意味で、 +どちらのやり方も行き着くところは同じです。 +これらの方法は、中央集権的な組織より、自然に発展していく組織でより重要になります。 +なぜならそうした組織では、 +よくないものが全体に影響することを少なくともしばらくは皆が意識しているからです。 +/para sect1 id=forkability -titleforkできること/title +titleコードが派生する可能性/title +!-- paraThe indispensable ingredient that binds developers together on a free software project, and makes them willing to compromise when necessary, is the code's firsttermforkability/firstterm: the @@ -68,7 +105,22 @@ xref linkend=managing-volunteers//phrase), the more serious the threat of a fork becomes, the more willing people are to compromise to avoid it./para +-- +para +開発者をフリーソフトウェアプロジェクトにつなぎ止め、 +必要な時に妥協してもらうのに不可欠な要素は、 +コードを firstterm派生させることができる/firstterm ことです。 +逆説的なのは、コードが派生する emphasis可能性/emphasis の方が、 +まれながら実際に派生することよりも、 +フリーソフトウェアプロジェクトにとって大きな力になるということです。 +コードが派生することは万人にとってよくないことなので、 +(詳細な理由は、phrase output=printedxref linkend=managing-volunteers//phrase の xref linkend=forks/ で述べています。) +派生する恐れが大きくなればなるほど、 +人々はそれを避けようとして妥協する可能性が大きくなります。 +/para + +!-- paraForks, or rather the potential for forks, are the reason there are no true dictators in free software projects. This may seem like a surprising claim, considering how common it is to hear someone called @@ -79,7 +131,19 @@ see fit. Would not such a king govern very differently from one whose subjects were bound to stay under his rule no matter what he did?/para +-- + +para +コードが派生すること、いやむしろ派生する可能性と言った方がよいでしょう。 +この可能性こそが、フリーソフトウェアプロジェクトには本当の意味での独裁者が存在しない理由になっています。 +これはオープンソースプロジェクトで 独裁者 とか 暴君 と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。 +しかし、この手の 圧政 という言葉は特別なもので、伝統的に理解されている圧政の意味とは違うものです。 +いつでも自分の王国をコピーでき、 +いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。 +そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？ するはずがないですよね。 +/para +!-- paraThis is why even projects that are not formally organized as democracies are, in practice, democracies when it comes to important decisions. Replicability implies forkability; forkability implies @@ -94,7 +158,25 @@ restlessness, followed eventually by revolt and a fork. Except, of course, things rarely get that far, because the dictator compromises first./para +-- + +para +そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、 +重要な決定をする段になると民主主義の仕組みを使います。 +コードを複製できるということは、コードを派生できるということです。 +コードを派生できるということは、妥協を生むことを意味しています。 +全員がひとりのリーダーに従うこと（もっと
[ProducingOSS commit] r1171 - trunk/ja
Author: mumumu Date: Sat Sep 15 09:50:14 2007 New Revision: 1171 Log: - translated BD section. Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 09:50:14 2007 @@ -205,11 +205,22 @@ sect1 id=benevolent-dictator title優しい独裁者/title +!-- paraThe firsttermbenevolent dictator/firstterm model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely./para +-- + +para +firstterm優しい独裁者/firstterm モデルとは、 +正確には次のようなものです。 +つまり、最終的な決断を行う権限が、 +人柄や経験が優れているという理由で、 +賢明に権限を行使できるひとりの人に委ねられていることです。 +/para +!-- paraAlthough benevolent dictator (or firsttermBD/firstterm)is the standard term for this role, it would be better to think of it as community-approved arbitrator or judge. Generally, benevolent @@ -229,6 +240,27 @@ decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role./para +-- + +para +優しい独裁者 （または略して firsttermBD/firstterm ともいいます）という言葉は、 +こうした役割に対して標準的に使われる用語ですが、 +むしろ コミュニティーが認めた調停者 もしくは 審判 と考えた方がいいでしょう。 +一般的に、優しい独裁者が実際に全ての、もしくはほとんどの決定を行っているわけではありません。 +ある人がプロジェクトの全ての領域に渡って、 +優れた決断を一貫して行う十分な技能があることはまれです。 +そして優れた開発者は、プロジェクトの方向性に影響を及ぼすことがなければ、 +結局プロジェクトに留まり続けたりはしません。 +それゆえに、優しい独裁者は普通多く指示を出したりはしません。 +むしろ、いつでも可能な限り、議論や実験を通して働くのは開発者に任せておきます。 +彼らは議論そのものには参加しますが、普通の開発者として、 +自分より優れた技能を持つメンテナの領域では、たびたび彼らに従います。 +結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを emphasis望んでいる/emphasis のが明らかな場合にだけ、 +彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。 +命令することで決定するのを我慢するのは、 +成功している優しい独裁者に事実上共通する特性です。 +これが彼らが優しい独裁者という役割を維持している理由のひとつなのです。 +/para sect2 id=benevolent-dictator-qualifications title誰がよき「優しい独裁者」となれるか?/title ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1172 - trunk/ja
Author: mumumu Date: Sat Sep 15 10:52:23 2007 New Revision: 1172 Log: - translated part of Who Can Be a Good Benevolent Dictator? Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 10:52:23 2007 @@ -259,12 +259,13 @@ 彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。 命令することで決定するのを我慢するのは、 成功している優しい独裁者に事実上共通する特性です。 -これが彼らが優しい独裁者という役割を維持している理由のひとつなのです。 +これが、彼らが優しい独裁者という役割を維持している理由のひとつなのです。 /para sect2 id=benevolent-dictator-qualifications title誰がよき「優しい独裁者」となれるか?/title +!-- paraBeing a BD requires a combination of traits. It needs, first of all, a well-honed sensitivity to one's own influence in the project, which in turn brings self-restraint. In the early stages of a @@ -281,7 +282,29 @@ less seniority may not feel so secure, so the BD should phrase critiques or contrary decisions with some sensitivity for how much weight her words carry, both technically and psychologically./para +-- + +para +優しい独裁者になるには複数の特性が必要です。 +まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、 +これは言い替えれば自制を働かせるということです。 +議論の最初の段階では、 +反対するのは的外れだと他の人が感じていると確信して意見や結論を述べてはいけません。 +人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。 +もちろん、優しい独裁者もたびたび愚かなな考えを述べることも避けられません。 +だから、自分が悪い決断を下したときに、それを認識し、 +受け入れる能力も必要になるのです。mdash; +ですが、この資質は優れた開発者であれば、特にプロジェクトに長い間留まっている人であればなおさら emphasis誰でも/emphasis 持っているはずの資質にすぎません。 +しかし、優しい独裁者が違う点は、 +自分の信頼に長い間傷が付いてしまうんじゃないかと心配することなく、 +たびたび間違いを犯す余裕があることです。 +年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。 +だからこそ優しい独裁者は、 +技術的な面でも精神的な面でも自分の言葉が伝える重みに敏感になって、 +批判をしたり反対意見を述べるべきなのです。 +/para +!-- paraThe BD does emphasisnot/emphasis need to have the sharpest technical skills of anyone in the project. She must be skilled enough to work on the code herself, and to understand and comment on any @@ -291,6 +314,19 @@ design sensemdash;not necessarily the ability to produce good design on demand, but the ability to recognize good design, whatever its source./para +-- + +para +優しい独裁者は、 +プロジェクトにいる誰よりも技術的なスキルが優れている必要は emphasisありません/emphasis。 +コードを書く能力に十分優れ、 +コードに加えられたあらゆる変更を理解し、思いやりをもってそれにコメントしなければいけませんが、たったそれだけです。 +優しい独裁者の立場は、誰かから教わって得たものではありませんし、 +コードを書くスキルが恐ろしいほどあるという理由で得たものでもありません。 +emphasis重要なのは/emphasis 経験と総合的な設計センスです。mdash; +必要に応じて優れた設計を生み出す能力ではなく、 +優れた設計をソースコードから認識する能力なのです。 +/para paraIt is common for the benevolent dictator to be a founder of the project, but this is more a correlation than a cause. The sorts of ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1180 - trunk/ja
Author: mumumu Date: Sat Sep 15 16:06:18 2007 New Revision: 1180 Log: - minor fix Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 16:06:18 2007 @@ -437,7 +437,7 @@ 優しい独裁者が身を引いたり、決定を下す権限を多くの人に平等に与えようとするときはいつでも、 グループが新しい、独裁的でない仕組みに移行する機会になります mdash; これは言ってみれば組織化を行うということです。 -開発者のグループははじめの1、2回はこの機会を利用しませんが、 +開発者のグループは最初の1、2回はこの機会を利用しませんが、 結局は利用することになります。いったんそうしてしまえば、 もとの仕組みに戻ることはありません。このことは常識でわかることです。 仮に N人 からなるグループがある人に特別な権限を与えていると仮定すると、 @@ -482,7 +482,7 @@ 合意に達したんじゃないかと提案する人は、 合意とは何かということと、 仮に明らかでない場合は、 -合意の結果どのような行動がとられるのかについて具体的に述べるべきです。 +合意の結果どのような行動がとられるのかを具体的に述べるべきです。 /para !-- @@ -501,8 +501,8 @@ para プロジェクトで交わされるほとんどの会話は技術的な話題です。 たとえば、バグを直す正しい方法に関するものとか、 -ある機能を追加すべきかしないべきかとか、 -プログラムのインターフェイスをどの程度厳密に文書化すべきか、などといったものです。 +ある機能を追加するか、しないか、 +プログラムのインターフェイスをどの程度厳密に文書化するか、などといったものです。 合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。 議論が終わるまでに、どの方向性を採るかに関して合意がよく成立します。 通常は議論を終了するという投稿をし、 @@ -535,8 +535,8 @@ 彼はただ修正をコミットしただけですし、 他の開発者はわざわざ同意すると口に出して言ったりしません。 なぜなら黙っていることは合意することだからです。 -誰かがコミットした修正が、合意を得られないと判明した場合、 -まだそれがコミットされていないかのようにプロジェクトでは議論されるだけです。 +コミットされた修正が、合意を得られないと判明した場合、 +プロジェクトでは単にまだそれがコミットされていないかのように議論されます。 このやり方がうまく行く理由は次の節で述べていきます。 /para ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1182 - trunk/ja
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 +!-- paraThe 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 +!-- paraThis 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 + +!-- paraThus, 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 Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1187 - trunk/ja
Author: mumumu Date: Sat Sep 15 20:30:37 2007 New Revision: 1187 Log: - Veto section complete! and It's timed out! Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sat Sep 15 20:30:37 2007 @@ -888,6 +888,7 @@ 説明もされないのに行使された拒否権は無効なものと考えるべきでしょう。 /para +!-- paraWith vetoes comes the problem of veto abuse. Sometimes developers are too eager to raise the stakes by casting a veto, when really all that was called for was more discussion. You can prevent @@ -898,7 +899,24 @@ clear majority of developers wants X, then X is going to happen one way or another. Either the vetoing developer will back down, or the group will decide to weaken the meaning of a veto./para +-- + +para +拒否権を許すと、それが濫用されるという問題が起きます。 +開発者たちは、もっと議論が必要なときに拒否権を行使することで、 +リスクを増やしたくないと考えています。 +あなたは、自分自身が拒否権をとても慎重に行使し、 +そして誰かが拒否権を多く行使し続けている場合に、 +丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。 +必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、 +拒否権に拘束力を持たせるように求めることもできます mdash; +結局は、明らかに大多数の開発者が X を望んでいる場合は、 +その X が将来何かにつけ発生するでしょうから。 +その場合は、拒否権を行使している開発者がそれを取り下げるか、 +グループが拒否権の力を弱くする決定をすることになるでしょう。 +/para +!-- paraYou may see people write -1 to express a veto. This usage comes from the Apache Software Foundation, which has a highly structured voting and veto process, described at ulink @@ -909,13 +927,40 @@ veto even according to the Apache standards, but informally it is usually taken to mean a veto, or at least a very strong objection./para +-- +para +拒否権を行使するのに -1 と書く人を見かけるかもしれません。 +この使い方は、高度に組織化された投票と拒否権システムを持つ Apache Software Foundation で生まれたものです。 +これについては ulink url=http://www.apache.org/foundation/voting.html/ に説明があります。 +Apache プロジェクトの基準は他のプロジェクトにも広まっているので、 +オープンソース界の多くの場所で、 +彼らの規約が程度を変えて使われているのを見ることになるでしょう。 +技術的には、Apache プロジェクトの基準に照らしても、 +-1 という表現が必ずしも正式に拒否権を行使していることを示すわけではありません。 +しかし、非公式には拒否権の発動、 +もしくは少なくとも強い反対の意志を示していると普通は受け取られます。 +/para + +!-- paraLike votes, vetoes can apply retroactively. It's not okay to object to a veto on the grounds that the change in question has already been committed, or the action taken (unless it's something irrevocable, like putting out a press release). On the other hand, a veto that arrives weeks or months late isn't likely to be taken very seriously, nor should it be./para +-- + +para +投票のように、拒否権の効果は遡って適用できます。 +疑問が持たれている変更が既にコミットされている、 +もしくはアクションが既に起こされているという理由で、 + （既にプレスリリースが出ている場合のように、 +取り返しが付かないものでなければ） 拒否権に対して異議を唱えるのはよくありません。 +言いかえれば、何週間、何ヶ月もたったあとに拒否権が行使されても、 +それが真面目に取り上げられる可能性は少ないですし、 +真面目に取り上げるべきでもありません。 +/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1159 - trunk/ja
Author: mumumu Date: Sun Sep 9 13:07:59 2007 New Revision: 1159 Log: - translated 'release numbering' section. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sun Sep 9 13:07:59 2007 @@ -127,7 +127,7 @@ 彼らはプロジェクトで起こっていることがスケジュールと衝突しているかどうかを気にせずに作業できるのです。 プロジェクトが別の作業をやめてある作業に専念させるようなマスタ－スケジュールに縛られていると、 多くの開発者が長い間何もしない状態が発生します mdash; これは非効率であるばかりか、 -退屈なものなので危険です。退屈した開発者は、すぐに辞めてしまうでしょう。 +退屈なので危険です。退屈した開発者は、すぐに辞めてしまうでしょう。 /para !-- @@ -167,7 +167,7 @@ リリースを行なう方法を議論する前に、 リリースに対する名前の付け方をみておきましょう。 これは、リリースがユーザにとって何を意味するのかを知らせるのに必要なものです。 -リリースとは、次のようなものです : +リリースとは、次のようなものです。 /para itemizedlist @@ -180,7 +180,7 @@ para 古いバグが直っています。 -これは多分全てのリリースに当てはまるとユーザが期待していいことでしょう。 +これは全てのリリースに当てはまると多分ユーザが期待していいことでしょう。 /para /listitem @@ -195,7 +195,7 @@ para 新しいバグが入り込んでいます。 -これは時々行なわれるセキュリティリリース(phrase output=printedこの章の後半の/phrasexref linkend=security-releases/を参照してください)や他の単発リリースを除いて、普通は十分に考えられることです。 +これは時々行なわれるセキュリティリリース(phrase output=printedこの章の後半の/phrasexref linkend=security-releases/を参照してください)や他の単発リリースを除いて、普通は十分過ぎるほどあり得ることです。 /para /listitem @@ -241,19 +241,43 @@ /itemizedlist +!-- paraAs you can see, not all of these are good things. This is why experienced users approach new releases with some trepidation, especially when the software is mature and was already mostly doing what they wanted (or thought they wanted). Even the arrival of new features is a mixed blessing, in that it may mean the software will now behave in unexpected ways./para +-- + +para +見てわかる通り、全てが良いことばかりではありません。 +よって経験豊富なユーザーは、新しいリリースを少し恐る恐る扱います。 +特にそのソフトウェアが成熟しており、 +既にユーザーが求めた（または欲しいと思った）動きをほとんどしてくれていた場合はなおさらです。 +たとえ新機能が追加されても、 +それはソフトウェアが意図しない振舞いをするかもしれないという点で、 +ありがた迷惑なものなのです。 +/para +!-- paraThe purpose of release numbering, therefore, is twofold: obviously the numbers should unambiguously communicate the ordering of releases (i.e., by looking at any two releases' numbers, one can know which came later), but also they should indicate as compactly as possible the degree and nature of the changes in the release./para +-- +para +よって、リリースに番号を付ける目的はふたつあります。 +当然、 +リリース番号はリリースの順番を明確に伝える（i.e. ふたつのリリース番号を見れば、 +どちらが新しいものかがわかる）べきですが、 +それだけではなくて、 +変更の性質や程度をできるだけ簡潔に示すものでなければなりません。 +/para + +!-- paraAll that in a number? Well, more or less, yes. Release numbering strategies are one of the oldest bikeshed discussions around (see xref linkend=bikeshed/phrase output=printed in @@ -263,10 +287,23 @@ universally agreed-on principle: emphasisbe consistent/emphasis. Pick a numbering scheme, document it, and stick with it. Your users will thank you./para +-- + +para +そんなことを全部数字で表現するのかって？ +まあ、程度の差はありますが答えはYESです。 +リリース番号の付け方は、 +些細な話題なのに最も古くからあちこちで議論されてきたもののひとつですが、 +近い将来、唯一の完全な標準に落ち着く気配はありません。 +しかし、emphasis一貫していること/emphasis という普遍的に受け入れられた原則に基づいて、 +優れた戦略がいくつか現れてきています。 +番号の付け方を選び、それを文書化し、守るようにしましょう。 +番号の付け方をはっきりさせれば、ユーザーはあなたに感謝することでしょう。 +/para !-- == subsection === -- sect2 id=release-number-components -titleRelease Number Components/title +titleリリース番号の構成要素/title paraThis section describes the formal conventions of release numbering in detail, and assumes very little prior knowledge. It is ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1160 - trunk/ja
Author: mumumu Date: Sun Sep 9 13:12:51 2007 New Revision: 1160 Log: - added missing link, sorry. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sun Sep 9 13:12:51 2007 @@ -256,7 +256,7 @@ 特にそのソフトウェアが成熟しており、 既にユーザーが求めた（または欲しいと思った）動きをほとんどしてくれていた場合はなおさらです。 たとえ新機能が追加されても、 -それはソフトウェアが意図しない振舞いをするかもしれないという点で、 +それによってソフトウェアが意図しない振舞いをするかもしれないという点で、 ありがた迷惑なものなのです。 /para @@ -272,7 +272,7 @@ よって、リリースに番号を付ける目的はふたつあります。 当然、 リリース番号はリリースの順番を明確に伝える（i.e. ふたつのリリース番号を見れば、 -どちらが新しいものかがわかる）べきですが、 +どちらが新しいものかがわかる）べきものですが、 それだけではなくて、 変更の性質や程度をできるだけ簡潔に示すものでなければなりません。 /para @@ -293,7 +293,7 @@ そんなことを全部数字で表現するのかって？ まあ、程度の差はありますが答えはYESです。 リリース番号の付け方は、 -些細な話題なのに最も古くからあちこちで議論されてきたもののひとつですが、 +些細な話題なのに最も古くからあちこちで議論されてきた（phrase output=printedxref linkend=communications/ の /phrase xref linkend=bikeshed/ を参照してください）もののひとつですが、 近い将来、唯一の完全な標準に落ち着く気配はありません。 しかし、emphasis一貫していること/emphasis という普遍的に受け入れられた原則に基づいて、 優れた戦略がいくつか現れてきています。 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1161 - trunk/ja
Author: mumumu Date: Sun Sep 9 14:14:01 2007 New Revision: 1161 Log: - translated introduction part of ch04.xml Modified: trunk/ja/ch04.xml Modified: trunk/ja/ch04.xml == --- trunk/ja/ch04.xml (original) +++ trunk/ja/ch04.xml Sun Sep 9 14:14:01 2007 @@ -4,6 +4,7 @@ simplesect +!-- paraThe first questions people usually ask about free software are How does it work? What keeps a project running? Who makes the decisions? I'm always dissatisfied with bland responses about @@ -12,6 +13,17 @@ cooperation, and running code are all part of it, but they do little to explain how projects actually run on a day-to-day basis, and say nothing about how conflicts are resolved./para +-- + +para +通常、フリーソフトウェアについて人々がする最初の質問は プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？ といったものです。 +私は、実力主義や、協力の精神、自己説明的なコード、 +などについて当たり障りなく答えて、いつも釈然としない思いがします。 +実のところ、こうした質問に答えるのは簡単ではありません。 +実力主義、協力、そして動くコードは全て答えの一部ではありますが、 +日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 +プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 +/para paraThis chapter tries to show the structural underpinnings successful projects have in common. I mean successful not just in ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1128 - trunk/ja
Author: mumumu Date: Fri Aug 31 08:54:57 2007 New Revision: 1128 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 08:54:57 2007 @@ -3991,7 +3991,7 @@ paraThe classic issue life cycle looks like this: -- -para問題の典型的なライフサイクルは次のようなものです。: +para問題の典型的なライフサイクルは次のようなものです。 orderedlist listitem @@ -4440,6 +4440,7 @@ sect2 id=bug-filtering titleフィルタ済みのバグ追跡システム/title +!-- paraMost issue databases eventually suffer from the same problem: a crushing load of duplicate or invalid issues filed by well-meaning but inexperienced or ill-informed users. The first step in combatting @@ -4447,6 +4448,19 @@ the bug tracker, explaining how to tell if a bug is really a bug, how to search to see if it's already been filed, and finally, how to effectively report it if one still thinks it's a new bug./para +-- + +para +ほとんどのバグ追跡システムは結局同じ問題に悩まされます。 +バグを報告した経験が少なかったり、 +肝心な部分を知らない善意のユーザーが、 +既に報告されている問題やバグではない問題を大量に報告してくるのです。 +この傾向に対処するはじめのステップとして、 +バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。 +そこで本当にバグかどうかを区別する方法や、 +既に報告されている問題かどうかを検索する方法、 +そして最後に、それが本当に新規のバグであった場合に効果的にそれを報告する方法を説明しておくのです。 +/para paraThis will reduce the noise level for a while, but as the number of users increases, the problem will eventually come back. No ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1129 - trunk/ja
Author: mumumu Date: Fri Aug 31 09:37:59 2007 New Revision: 1129 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 09:37:59 2007 @@ -4370,7 +4370,7 @@ para バグ追跡システムがディスカッションフォーラムにならないようにしましょう。 バグ追跡システムに人間が顔を出し続けることは大事ですが、 -それがリアルタイムに行なわれる議論に合っているわけではありません。 +それがリアルタイムに議論するのに適しているわけではありません。 バグ追跡システムは、起こった事実や他の議論に対する参照、 メーリングリストで起きた議論をまとめるアーカイバと考えるようにしましょう。 /para @@ -4459,9 +4459,10 @@ バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。 そこで本当にバグかどうかを区別する方法や、 既に報告されている問題かどうかを検索する方法、 -そして最後に、それが本当に新規のバグであった場合に効果的にそれを報告する方法を説明しておくのです。 +そして最後に、本当に新規のバグであった場合に効果的に報告する方法を説明しておくのです。 /para +!-- paraThis will reduce the noise level for a while, but as the number of users increases, the problem will eventually come back. No individual user can be blamed for it. Each one is just trying to @@ -4470,12 +4471,32 @@ involved and file better issues in the future. In the meantime, though, the project needs to keep the issue database as free of junk as possible./para +-- + +para +こうすることでしばらくは報告されてくる問題のノイズは下げられますが、 +ユーザーが増えてくるにつれてこの問題は結局再燃します。 +このことでユーザーを責めることはできません。 +ひとりひとりのユーザーはただプロジェクトをよいものにするために貢献しようとしているだけですし、 +たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 +あなたは彼らにひき続きプロジェクトに参加してもらって将来はよりよいバグ報告をして欲しいと思うでしょう。 +しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。 +/para +!-- paraThe two things that will do the most to prevent this problem are: making sure there are people watching the bug tracker who have enough knowledge to close issues as invalid or duplicates the moment they come in, and requiring (or strongly encouraging) users to confirm their bugs with other people before filing them in the tracker./para +-- + +para +この問題を避けるために何より実行すべきことがふたつあります。 +バグではない問題や、 +重複したバグ報告を報告されたらすぐにクローズできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 +そしてバグ報告システムにバグを報告する前に他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。 +/para paraThe first technique seems to be used universally. Even projects with huge issue databases (say, the Debian bug tracker at ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1130 - trunk/ja
Author: mumumu Date: Fri Aug 31 10:05:49 2007 New Revision: 1130 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 10:05:49 2007 @@ -4477,7 +4477,7 @@ こうすることでしばらくは報告されてくる問題のノイズは下げられますが、 ユーザーが増えてくるにつれてこの問題は結局再燃します。 このことでユーザーを責めることはできません。 -ひとりひとりのユーザーはただプロジェクトをよいものにするために貢献しようとしているだけですし、 +ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、 たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 あなたは彼らにひき続きプロジェクトに参加してもらって将来はよりよいバグ報告をして欲しいと思うでしょう。 しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。 @@ -4495,9 +4495,11 @@ この問題を避けるために何より実行すべきことがふたつあります。 バグではない問題や、 重複したバグ報告を報告されたらすぐにクローズできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 -そしてバグ報告システムにバグを報告する前に他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。 +そしてバグ報告システムにバグを報告する前に、 +他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。 /para +!-- paraThe first technique seems to be used universally. Even projects with huge issue databases (say, the Debian bug tracker at ulink url=http://bugs.debian.org//, which contained 315,929 issues @@ -4513,6 +4515,22 @@ guesses right or wrong when filing, issue watching is still distributed more or less evenly among the developers, so each issue is able to receive a timely response./para +-- + +para +はじめのテクニックはあらゆるところで使われているようです。 +巨大なバグデータベースを持つ（たとえば ulink url=http://bugs.debian.org// にある Debian のバグ追跡システムは、執筆時点で315,929個のバグ情報があります）プロジェクトでも、バグが報告されるたびに emphasis誰かが/emphasis 見張るようにシステムを改造しています。 +問題のカテゴリによって見張る人は違うかもしれません。 +たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、 +自動的にそれぞれの問題を適切なパッケージメンテナに転送しています。 +もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。 +そういう場合は、そのバグははじめは間違った人に転送されるので、 +転送された人が再度転送し直さなければなりません。 +しかし重要なのは、その負担が共有されているということです +mdash; ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、 +報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。 +よって問題が報告されるたびに、適切なタイミングで応答することができるのです。 +/para paraThe second technique is less widespread, probably because it's harder to automate. The essential idea is that every new issue gets ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1132 - trunk/ja
Author: mumumu Date: Fri Aug 31 11:57:41 2007 New Revision: 1132 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 11:57:41 2007 @@ -4438,7 +4438,7 @@ /sect2 sect2 id=bug-filtering -titleバグ追跡システムをあらかじめフィルタしておく/title +titleバグ追跡システムをあらかじめフィルタする/title !-- paraMost issue databases eventually suffer from the same problem: a @@ -4479,7 +4479,8 @@ このことでユーザーを責めることはできません。 ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、 たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 -あなたは彼らにひき続きプロジェクトに参加してもらって将来はよりよいバグ報告をして欲しいと思うでしょう。 +あなたは彼らにひき続きプロジェクトに参加してもらって、 +将来はよりよいバグ報告をして欲しいと思うでしょう。 しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。 /para @@ -4519,7 +4520,7 @@ para はじめのテクニックはあらゆるところで使われているようです。 -巨大なバグデータベースを持つ（たとえば ulink url=http://bugs.debian.org// にある Debian のバグ追跡システムは、執筆時点で315,929個のバグ情報があります）プロジェクトでも、バグが報告されるたびに emphasis誰かが/emphasis 見張るようにシステムを改造しています。 +巨大なバグデータベースを持つ（たとえば ulink url=http://bugs.debian.org// にある Debian のバグ追跡システムは、執筆時点で 315,929個 のバグ情報があります）プロジェクトでも、バグが報告されるたびに emphasis誰かが/emphasis 見張るようにシステムを改造しています。 問題のカテゴリによって見張る人は違うかもしれません。 たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、 自動的にそれぞれの問題を適切なパッケージメンテナに転送しています。 @@ -4568,6 +4569,7 @@ 喜んで検索するものです。 /para +!-- paraThe buddy system can really keep the issue database clean, but it has some disadvantages too. Many people will file solo anyway, either through not seeing, or through disregarding, the instructions @@ -4581,6 +4583,24 @@ buddying system in the future, so that there is an ever-growing pool of people who understand the issue-filtering system. On seeing an unbuddied issue, the ideal steps are:/para +-- + +para +仲間を巻き込むシステムはバグデータベースをきれいにしてくれますが、 +欠点もいくつかあります。 +多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、 +軽視するかして、結局ひとりでバグ報告をしてしまうことです。 +よって、ボランティアにはやはりバグデータベースを見張ってもらう必要があります。 +さらに、ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らないので、 +ガイドラインを無視しているからといって厳しく注意するのはフェアではありません。 +よってボランティアは、 +誰かに見てもらっていないバグ報告を報告者にどう差し戻すのかについては、 +用心深く、なおかつ慎重でなければなりません。 +これは、問題をフィルタする仕組みを理解する人々をますます増やすために、 +報告者にゆくゆくは仲間を巻き込んでバグ報告をしてもらうことが目的です。 +誰かに見てもらっていないバグ報告を見つけたら、 +とるべき理想的な対処のステップは次のようなものです。 +/para orderedlist listitem ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1133 - trunk/ja
Author: mumumu Date: Fri Aug 31 14:02:53 2007 New Revision: 1133 Log: - ch03.xml translation complete! WoW! Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 14:02:53 2007 @@ -3977,7 +3977,7 @@ para この本では バグ追跡システム という用語を、 -物事を追跡するソフトウェアを指すものとします。 +バグを追跡するソフトウェアを指すものとします。 なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。 しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、 firstterm問題/firstterm という用語を使います。 @@ -4032,10 +4032,10 @@ consciousness./para -- -paraいったん問題が報告されると、その問題は firsttermopen/firstterm な状態にあるといいます。 +paraいったん問題が報告されると、その問題は firstterm保留中/firstterm の状態にあるといいます。 なぜなら、それに対して何らアクションがとられていないからです。 システムによっては、 -firsttermunverified/firstterm とか firsttermunstarted/firstterm といったラベルを付与するものもあります。 +firstterm未確認/firstterm とか firstterm未着手/firstterm といったラベルを付与するものもあります。 まだ誰もこの問題を担当していません。システムによっては、 担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。 この時点では、問題は一時的な領域に置かれています。つまり、 @@ -4065,7 +4065,7 @@ -- para -問題はやがて firsttermreproduced/firstterm という状態になります。 +問題はやがて firstterm再現済み/firstterm という状態になります。 これは問題のライフサイクルの中で最も重要かもしれません。これは、 まだ解決されたわけではないが、 報告した人以外の誰かが問題を再現でき、 @@ -4088,7 +4088,7 @@ -- para -そして firsttermdiagnosed/firstterm という状態になります。 +そして firstterm診断済み/firstterm という状態になります。 問題の原因が特定され、可能なら解決に必要な労力が見積もられます。 これらのことは必ず追跡システムに記録するようにしましょう。 原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、 @@ -4112,8 +4112,8 @@ para この段階か、もうひとつ前の段階で、 -開発者が問題を 自分が解決することにして、 自分自身を firsttermアサイン/firstterm するかもしれません。 -(アサインの手続きをさらに詳細に調べるには +開発者が問題を 自分が解決することにして、 自分自身を firstterm担当者にする/firstterm するかもしれません。 +(担当者を決める手続きをさらに詳細に調べるには phrase output=printedxref linkend=managing-volunteers/の/phrase、 xref linkend=delegation-assignment/ を参照してください) この段階で、問題にfirstterm優先度/firstterm も割り当てられるかもしれません。 @@ -4155,8 +4155,8 @@ para 問題が解決されます。（タスクが終了したり、 パッチが適用されたりとか、そういったものです） -行った変更は、問題がfirsttermクローズされた/firsttermり、 -firsttermresolved/firstterm とマークされたあとに、 +行った変更は、問題のfirstterm処理が完了/firsttermしたり、 +firstterm解決済み/firstterm とマークされたあとに、 コメントとして記録するようにしましょう。 /para /listitem @@ -4188,12 +4188,12 @@ para 問題のライフサイクルには共通のバリエーションがいくつかあります。 -問題によっては、バグではなくユーザー側が誤解していたという理由ですぐにクローズされることがあります。 +問題によっては、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることがあります。 プロジェクトが多くのユーザを獲得するにつれ、 バグではない問題が報告される回数も増えていき、 -開発者は次第にぶっきらぼうな返事をして問題をクローズしていくようになります。 +開発者は次第にぶっきらぼうな返事をして問題を処理済みとするようになります。 こういう風潮にならないよう努力しましょう。 -ぶっきらぼうにクローズしてもいいことは何もありません。 +ぶっきらぼうに問題を処理済みにしてもいいことは何もありません。 バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。 それに報告される問題が統計的にどういった傾向にあるかは、 開発者のみわかることで、ユーザーにはわからないことです。 @@ -4222,12 +4222,12 @@ para 別のバリエーションとして、 -1. のすぐ後で問題が firstterm重複している/firstterm としてクローズされる場合があります。 +1. のすぐ後で問題が firstterm重複している/firstterm として 処理済み とされる場合があります。 重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。 -重複した状態は open されている問題で発生するとは限りません。 -解決したあとで再び報告される(この状態を firsttermregression/firstterm と呼びます)こともあります。 +重複した状態は 保留中 の問題で発生するとは限りません。 +解決したあとで再び報告される(この状態を firsttermリグレッション（回帰）/firstterm と呼びます)こともあります。 こういう場合は、重複の元となった問題を reopen の状態にして、 -重複した問題はクローズしてしまうのが普通は望ましいでしょう。 +重複した問題は 処理済み としてしまうのが普通は望ましいでしょう。 バグ追跡システムは、 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 問題同士の関連を追跡しているはずです。 @@ -4243,8 +4243,8 @@ -- para -開発者が問題をクローズする3つ目のバリエーションは、 -問題を解決したと思い込んでクローズするパターンです。 +開発者が問題を処理済みとする3つ目のバリエーションは、 +問題を解決したと思い込んで処理済みにするパターンです。 これは結局、問題を報告した人がそれを拒んで reopen する結果になります。 これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、 問題を再現する手順に正確に従ってテストをしなかったために発生します。 @@ -4287,7 +4287,7 @@ para 1. が暗に示すとおり、 バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。 -誰でも問題を報告し、調べることができますし、現在 open されている問題の一覧を見ることができます。 +誰でも問題を報告し、調べることができますし、現在保留中とされている問題の一覧を見ることができます。 よって、報告されている問題の進捗を何人の人が知りたがっているのかが、 開発者にはわからないということになります。 問題が解決される割合は開発者コミュニティの規模やスキルに左右されますが、 @@ -4495,7 +4495,7 @@ para この問題を避けるために何より実行すべきことがふたつあります。 バグではない問題や、 -重複したバグ報告を報告されたらすぐにクローズできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 +重複したバグ報告を報告されたらすぐに 処理済み とマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 そしてバグ報告システムにバグを報告する前に、 他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。 /para @@ -4553,7 +4553,8 @@ para ふたつめのテクニックは広く使われているわけではありませんが、 これはおそらく自動化が難しいからでしょう。 -アイディアの要点は、新しく報告されてくる問題をデータベースに登録する前に仲間を巻き込むことです。 +アイディアの要点は、新しく報告されてくる問題をデータベースに登録する前に、 +仲間を 巻き込むことです。 ユーザーが問題を見つけたと思ったときは
[ProducingOSS commit] r1134 - trunk/ja
Author: mumumu Date: Fri Aug 31 14:14:35 2007 New Revision: 1134 Log: - fix xml compilation error, sorry - reopen word fix. Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 14:14:35 2007 @@ -4226,7 +4226,7 @@ 重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。 重複した状態は 保留中 の問題で発生するとは限りません。 解決したあとで再び報告される(この状態を firsttermリグレッション（回帰）/firstterm と呼びます)こともあります。 -こういう場合は、重複の元となった問題を reopen の状態にして、 +こういう場合は、重複の元となった問題を 再度保留中の状態にして、 重複した問題は 処理済み としてしまうのが普通は望ましいでしょう。 バグ追跡システムは、 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 @@ -4245,7 +4245,7 @@ para 開発者が問題を処理済みとする3つ目のバリエーションは、 問題を解決したと思い込んで処理済みにするパターンです。 -これは結局、問題を報告した人がそれを拒んで reopen する結果になります。 +これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。 これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、 問題を再現する手順に正確に従ってテストをしなかったために発生します。 /para @@ -4587,7 +4587,7 @@ -- para -仲間を巻き込むシステムはバグデータベースをきれいにしてくれますが、 +仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、 欠点もいくつかあります。 多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、 軽視するかして、結局ひとりでバグ報告をしてしまうことです。 @@ -4642,8 +4642,8 @@ -- para そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークしましょう。 -しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、reopen して欲しいと伝えます。 -それで reopen する場合、報告した人は確認をとったスレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するはずです。 +しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、再度保留中にして欲しいと伝えます。 +この場合、報告した人は確認をとったスレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するはずです。 /para /listitem /orderedlist @@ -4669,7 +4669,7 @@ できるだけ多くの人達の助けを得ようとした方がよいでしょう。 /para -paraphrase output=printedxref linkend=managing-volunteers/ の /phrasexref linkend=issue-manager/ も参照してください。/para +paraphrase output=printedxref linkend=managing-volunteers/ の /phrasexref linkend=issue-manager/ も参照してください。/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1135 - trunk/ja
Author: mumumu Date: Fri Aug 31 14:27:27 2007 New Revision: 1135 Log: - trivial fix - deleted useless space Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 14:27:27 2007 @@ -4155,7 +4155,7 @@ para 問題が解決されます。（タスクが終了したり、 パッチが適用されたりとか、そういったものです） -行った変更は、問題のfirstterm処理が完了/firsttermしたり、 +行った変更は、問題の firstterm処理が済んだ/firstterm り、 firstterm解決済み/firstterm とマークされたあとに、 コメントとして記録するようにしましょう。 /para @@ -4222,12 +4222,12 @@ para 別のバリエーションとして、 -1. のすぐ後で問題が firstterm重複している/firstterm として 処理済み とされる場合があります。 +1. のすぐ後で問題が firstterm重複している/firstterm として処理済みにされる場合があります。 重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。 重複した状態は 保留中 の問題で発生するとは限りません。 解決したあとで再び報告される(この状態を firsttermリグレッション（回帰）/firstterm と呼びます)こともあります。 こういう場合は、重複の元となった問題を 再度保留中の状態にして、 -重複した問題は 処理済み としてしまうのが普通は望ましいでしょう。 +重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。 バグ追跡システムは、 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 問題同士の関連を追跡しているはずです。 @@ -4243,7 +4243,7 @@ -- para -開発者が問題を処理済みとする3つ目のバリエーションは、 +開発者が問題を処理済みにする3つ目のバリエーションは、 問題を解決したと思い込んで処理済みにするパターンです。 これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。 これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、 @@ -4321,9 +4321,9 @@ -- para -問題を報告することを含めた、問題の状態を変更するあらゆる行動が、 -何が起きているのかを説明した上でメールで投稿されるように、 バグ追跡システムをメーリングリストと接続しなければいけません。 +これは、問題を報告することを含めた、問題の状態を変更するあらゆる行動が、 +メールで投稿されるようにするためです。 このメーリングリストは通常使う開発用のものとは違うのが普通です。 なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。 しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。 @@ -4495,7 +4495,7 @@ para この問題を避けるために何より実行すべきことがふたつあります。 バグではない問題や、 -重複したバグ報告を報告されたらすぐに 処理済み とマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 +重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 そしてバグ報告システムにバグを報告する前に、 他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。 /para @@ -4629,7 +4629,7 @@ 報告された問題が明らかに正しいもので重複していない場合は、 とりあえずそれを受け入れて通常のライフサイクルを開始します。 結局、報告した人はバグかどうかを誰かに見てもらうべきだと言われているので、 -正しいバグ報告を処理済みとするまで労力を無駄にする点はありません。 +正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。 /para /listitem listitem @@ -4669,7 +4669,7 @@ できるだけ多くの人達の助けを得ようとした方がよいでしょう。 /para -paraphrase output=printedxref linkend=managing-volunteers/ の /phrasexref linkend=issue-manager/ も参照してください。/para +paraphrase output=printedxref linkend=managing-volunteers/ の /phrasexref linkend=issue-manager/ も参照してください。/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1136 - trunk/ja
Author: mumumu Date: Fri Aug 31 14:31:08 2007 New Revision: 1136 Log: - garbled link fix. Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 14:31:08 2007 @@ -4114,7 +4114,7 @@ この段階か、もうひとつ前の段階で、 開発者が問題を 自分が解決することにして、 自分自身を firstterm担当者にする/firstterm するかもしれません。 (担当者を決める手続きをさらに詳細に調べるには -phrase output=printedxref linkend=managing-volunteers/の/phrase、 +phrase output=printedxref linkend=managing-volunteers/ の /phrase、 xref linkend=delegation-assignment/ を参照してください) この段階で、問題にfirstterm優先度/firstterm も割り当てられるかもしれません。 たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1139 - trunk/ja
Author: mumumu Date: Fri Aug 31 17:12:14 2007 New Revision: 1139 Log: - changed translation of word problem Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Fri Aug 31 17:12:14 2007 @@ -4451,7 +4451,7 @@ -- para -ほとんどのバグ追跡システムは結局同じ問題に悩まされます。 +ほとんどのバグ追跡システムは結局同じ課題に悩まされます。 バグを報告した経験が少なかったり、 肝心な部分を知らない善意のユーザーが、 既に報告されている問題やバグではない問題を大量に報告してくるのです。 @@ -4475,7 +4475,7 @@ para こうすることでしばらくは報告されてくる問題のノイズは下げられますが、 -ユーザーが増えてくるにつれてこの問題は結局再燃します。 +ユーザーが増えてくるにつれてこの課題は結局再燃します。 このことでユーザーを責めることはできません。 ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、 たとえ彼らのバグ報告がはじめは役に立たなかったとしても、 @@ -4493,7 +4493,7 @@ -- para -この問題を避けるために何より実行すべきことがふたつあります。 +この課題を避けるために何より実行すべきことがふたつあります。 バグではない問題や、 重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。 そしてバグ報告システムにバグを報告する前に、 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1125 - trunk/ja
Author: mumumu Date: Wed Aug 29 12:28:27 2007 New Revision: 1125 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Wed Aug 29 12:28:27 2007 @@ -3932,7 +3932,7 @@ ここでは バグ追跡システムをセットアップすることと、 その作業に関する技術的な考察に集中しようと思います。 その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。 -: 具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか? +具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか? /para !-- @@ -4066,7 +4066,7 @@ para 問題はやがて firsttermreproduced/firstterm という状態になります。 -これは問題のライフサイクルの中で最も重要なものかもしれません。これは、 +これは問題のライフサイクルの中で最も重要かもしれません。これは、 まだ解決されたわけではないが、 報告した人以外の誰かが問題を再現でき、 この問題が本物だと証明したことをいいます。 @@ -4112,7 +4112,7 @@ para この段階か、もうひとつ前の段階で、 -開発者が問題の 所有権を得て 自分自身を firsttermアサイン/firstterm するかもしれません。 +開発者が問題を 自分が解決することにして、 自分自身を firsttermアサイン/firstterm するかもしれません。 (アサインの手続きをさらに詳細に調べるには phrase output=printedxref linkend=managing-volunteers/の/phrase、 xref linkend=delegation-assignment/ を参照してください) @@ -4187,7 +4187,7 @@ -- para -このライフサイクルには共通のバリエーションがいくつかあります。 +問題のライフサイクルには共通のバリエーションがいくつかあります。 問題によっては、バグではなくユーザー側が誤解していたという理由ですぐにクローズされることがあります。 プロジェクトが多くのユーザを獲得するにつれ、 バグではない問題が報告される回数も増えていき、 @@ -4344,7 +4344,7 @@ para 問題を報告するときの記入フォームは、 -報告する人の電子メールアドレスの入力欄にフォーカスを当てておくべきです。 +報告する人の電子メールアドレスの欄にフォーカスを当てておくべきです。 (しかし、匿名で報告したいと思う人もいるので、 電子メールアドレスを emphasis必須/emphasis にすべきではありません。 匿名の重要性については、 @@ -4358,13 +4358,24 @@ sect2 id=bug-tracker-mailing-list-interaction titleメーリングリストを使って交流する/title +!-- paraMake sure the bug tracker doesn't turn into a discussion forum. Although it is important to maintain a human presence in the bug tracker, it is not fundamentally suited to real-time discussion. Think of it rather as an archiver, a way to organize facts and references to other discussions, primarily those that take place on mailing lists./para +-- + +para +バグ追跡システムがディスカッションフォーラムにならないようにしましょう。 +バグ追跡システムに人間が顔を出し続けることは大事ですが、 +それがリアルタイムに行なわれる議論に合っているわけではありません。 +バグ追跡システムは、起こった事実や他の議論に対する参照、 +メーリングリストで起きた議論をまとめるアーカイバと考えるようにしましょう。 +/para +!-- paraThere are two reasons to make this distinction. First, the bug tracker is more cumbersome to use than the mailing lists (or than real-time chat forums, for that matter). This is not because bug @@ -4380,7 +4391,24 @@ xref linkend=bug-tracker-usage/phrase output=printed in xref linkend=communications/,/phrase we'll look at ways to make sure people don't accidentally siphon discussions out of appropriate forums and into the bug tracker./para +-- +para +こうした区別をするのはふたつの理由があります。 +ひとつめは、バグ追跡システムがメーリングリストに比べて（ついでにいうと、リアルタイムに会話ができるチャットシステムと比べても）使いにくいからです。 +これはバグ追跡システムのインターフェイス設計が悪いからではなく、 +単にメーリングリストやチャットシステムが、連続していない状態、つまり自由に流れていく議論を取り込めるように設計されているからです。 +ふたつめは、ある議論に参加している人が、 +バグ追跡システムを見ているとは限らないからです。 +よい問題管理のやり方(phrase output=printedxref linkend=managing-volunteers/の、/phrase xref linkend=share-management/ を参照してください)は、 +開発者全員に起こっている問題全部を追いかけさせるのではなく、 +適切な人の注意をひくようにすることです。 +phrase output=printedxref linkend=communications/の/phrase xref linkend=bug-tracker-usage/では、 +適切なフォーラム以外に偶然議論が波及しないようにする方法や、 +バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。 +/para + +!-- paraSome bug trackers can monitor mailing lists and automatically log all emails that are about a known issue. Typically they do this by recognizing the issue's identifying number in the subject line of @@ -4391,6 +4419,21 @@ this is a very useful feature; if your tracker has it, make sure both to turn it on and to remind people to take advantage of it./para +-- + +para +バグ追跡システムによっては、メーリングリストをモニタし、 +既知の問題に関する電子メールを全て自動的に記録するものがあります。 +通常、こうしたシステムはメールの件名の行にある問題の番号を、 +特別な文字列として認識することでこれを行います。 +開発者達は、バグ追跡システムの注意を引くために、 +電子メールにこうした文字列を含めることができるようになります。 +バグ追跡システムに電子メール全体を記録させてもいいですし、 +(よりよいのは)通常のメーリングリストのアーカイブにあるメールへのリンクを記録させてもよいでしょう。 +どちらの方法でも、これはとても役に立つ機能です。 +あなたが使っているバグ追跡システムにこの機能があるなら、 +それを有効にして人々が利用するように知らせておきましょう。 +/para /sect2 ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1126 - trunk/ja
Author: mumumu Date: Wed Aug 29 15:17:06 2007 New Revision: 1126 Log: - fix title - insertd space - trivial fix Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Wed Aug 29 15:17:06 2007 @@ -4153,7 +4153,7 @@ -- para -問題は解決されます。（タスクが終了したり、 +問題が解決されます。（タスクが終了したり、 パッチが適用されたりとか、そういったものです） 行った変更は、問題がfirsttermクローズされた/firsttermり、 firsttermresolved/firstterm とマークされたあとに、 @@ -4356,7 +4356,7 @@ /para sect2 id=bug-tracker-mailing-list-interaction -titleメーリングリストを使って交流する/title +title議論の場としてメーリングリストを使う/title !-- paraMake sure the bug tracker doesn't turn into a discussion forum. @@ -4400,10 +4400,10 @@ 単にメーリングリストやチャットシステムが、連続していない状態、つまり自由に流れていく議論を取り込めるように設計されているからです。 ふたつめは、ある議論に参加している人が、 バグ追跡システムを見ているとは限らないからです。 -よい問題管理のやり方(phrase output=printedxref linkend=managing-volunteers/の、/phrase xref linkend=share-management/ を参照してください)は、 +よい問題管理のやり方(phrase output=printedxref linkend=managing-volunteers/ の、/phrase xref linkend=share-management/ を参照してください)は、 開発者全員に起こっている問題全部を追いかけさせるのではなく、 適切な人の注意をひくようにすることです。 -phrase output=printedxref linkend=communications/の/phrase xref linkend=bug-tracker-usage/では、 +phrase output=printedxref linkend=communications/ の/phrase xref linkend=bug-tracker-usage/では、 適切なフォーラム以外に偶然議論が波及しないようにする方法や、 バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。 /para ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1117 - trunk/ja
Author: mumumu Date: Tue Aug 28 02:03:23 2007 New Revision: 1117 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Tue Aug 28 02:03:23 2007 @@ -4032,7 +4032,7 @@ consciousness./para -- -paraいったん問題が報告されると、その問題は firsttermopen/firsttermな状態にあるといいます。 +paraいったん問題が報告されると、その問題は firsttermopen/firstterm な状態にあるといいます。 なぜなら、それに対して何らアクションがとられていないからです。 システムによっては、 firsttermunverified/firstterm とか firsttermunstarted/firstterm といったラベルを付与するものもあります。 @@ -4117,7 +4117,7 @@ phrase output=printedxref linkend=managing-volunteers/の/phrase、 xref linkend=delegation-assignment/ を参照してください) この段階で、問題にfirstterm優先度/firstterm も割り当てられるかもしれません。 -たとえば、とても深刻なので解決は次のリリースにまわすべき場合、 +たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、 その事実は早い段階で確認する必要があります。 よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。 /para @@ -4164,6 +4164,7 @@ /para +!-- paraThere are some common variations on this life cycle. Sometimes an issue is closed very soon after being filed, because it turns out not to be a bug at all, but rather a misunderstanding on the part of @@ -4183,6 +4184,27 @@ an issue manager monitoring the bug database; see xref linkend=issue-manager/phrase output=printed in xref linkend=managing-volunteers//phrase./para +-- + +para +このライフサイクルには共通のバリエーションがいくつかあります。 +問題によっては、バグではなくユーザー側が誤解していたという理由ですぐにクローズされることがあります。 +プロジェクトが多くのユーザを獲得するにつれ、 +バグではない問題が報告される回数も増えていき、 +開発者は次第にぶっきらぼうな返事をして問題をクローズしていくようになります。 +こういう風潮にならないよう努力しましょう。 +ぶっきらぼうにクローズしてもいいことは何もありません。 +バグではない問題を報告したそれぞれのユーザは、以前報告された問題には何の責任もないのですから。 +それに報告される問題が統計的にどういった傾向にあるかは、 +開発者のみわかることで、ユーザーにはわかりません。 +(phrase output=printedこの章の後半の/phrase xref linkend=bug-filtering/ で、 +バグではない問題の数を減らすテクニックについて見ていきます) +また、異なったユーザが繰り返し同じような誤解をする場合は、 +誤解を生む部分を再設計する必要があるということかもしれません。 +この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。 +phrase output=printedxref linkend=managing-volunteers/ の/phrase、 +xref linkend=issue-manager/ を参照してください。 +/para paraAnother common life cycle variation is for the issue to be closed as a firsttermduplicate/firstterm soon after Step 1. A duplicate ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1118 - trunk/ja
Author: mumumu Date: Tue Aug 28 03:41:52 2007 New Revision: 1118 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Tue Aug 28 03:41:52 2007 @@ -4194,18 +4194,19 @@ 開発者は次第にぶっきらぼうな返事をして問題をクローズしていくようになります。 こういう風潮にならないよう努力しましょう。 ぶっきらぼうにクローズしてもいいことは何もありません。 -バグではない問題を報告したそれぞれのユーザは、以前報告された問題には何の責任もないのですから。 +バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。 それに報告される問題が統計的にどういった傾向にあるかは、 -開発者のみわかることで、ユーザーにはわかりません。 +開発者のみわかることで、ユーザーにはわからないことです。 (phrase output=printedこの章の後半の/phrase xref linkend=bug-filtering/ で、 バグではない問題の数を減らすテクニックについて見ていきます) -また、異なったユーザが繰り返し同じような誤解をする場合は、 +また、異なったユーザーが繰り返し同じような誤解をする場合は、 誤解を生む部分を再設計する必要があるということかもしれません。 この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。 phrase output=printedxref linkend=managing-volunteers/ の/phrase、 xref linkend=issue-manager/ を参照してください。 /para +!-- paraAnother common life cycle variation is for the issue to be closed as a firsttermduplicate/firstterm soon after Step 1. A duplicate is when someone files an issue that's already known to the project. @@ -4217,20 +4218,55 @@ track of this relationship bidirectionally, so that reproduction information in the duplicates is available to the original issue, and vice versa./para +-- + +para +別のバリエーションとして、 +1. のすぐ後で問題が firstterm重複している/firstterm としてクローズされる場合があります。 +重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。 +重複した状態は open されている問題で発生するとは限りません。 +解決したあとで再び報告される(この状態を firsttermregression/firstterm と呼びます)こともあります。 +こういう場合は、重複の元となった問題を reopen の状態にして、 +重複した問題はクローズしてしまうのが普通は望ましいでしょう。 +バグ追跡システムは、 +問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、 +問題同士の関連を追跡しているはずです。 +/para +!-- paraA third variation is for the developers to close the issue, thinking they have fixed it, only to have the original reporter reject the fix and reopen it. This is usually because the developers simply don't have access to the environment necessary to reproduce the bug, or because they didn't test the fix using the exact same reproduction recipe as the reporter./para +-- + +para +開発者が問題をクローズする3つ目のバリエーションは、 +問題を解決したと思い込んでクローズするパターンです。 +これは結局、問題を報告した人がそれを拒んで reopen する結果になります。 +これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、 +問題を再現する手順に正確に従ってテストをしなかったために発生します。 +/para +!-- paraAside from these variations, there may be other small details of the life cycle that vary depending on the tracking software. But the basic shape is the same, and while the life cycle itself is not specific to open source software, it has implications for how open source projects use their bug trackers./para +-- + +para +これらのバリエーションのほかにも、 +バグ追跡システムによっては細かい部分が変わる場合がありますが、 +基本的なパターンは同じです。 +問題のライフサイクルそのものもオープンソースソフトウェアに特有のものではありませんが、 +オープンソースプロジェクトのバグ追跡システムの使い方に影響を与えています。 +/para +!-- paraAs Step 1 implies, the tracker is as much a public face of the project as the mailing lists or web pages. Anyone may file an issue, anyone may look at an issue, and anyone may browse the list of currently @@ -4246,6 +4282,24 @@ project's consciousness, in the sense that that developer can be on the lookout for other instances of the issue, can talk about it with other developers, etc./para +-- + +para +1. が暗に示すとおり、 +バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。 +誰でも問題を報告し、調べることができますし、現在 open されている問題の一覧を見ることができます。 +よって、報告されている問題の進捗を何人の人が知りたがっているのかが、 +開発者にはわからないということになります。 +問題が解決される割合は開発者コミュニティの規模やスキルに左右されますが、 +プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。 +たとえ問題が解決されずにしばらく残り続けても、 +開発者からの返答は問題を報告する人に引き続き参加する意欲を与えます。 +なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、 +たとえば電子メールを送ること以上に労力がいることを思い出してください) +それ以上に、問題をいったん開発者が見れば、 +開発者が報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、 +プロジェクトが問題を認識したことになります。 +/para paraThe need for timely reactions implies two things: ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1119 - trunk/ja
Author: mumumu Date: Tue Aug 28 04:13:33 2007 New Revision: 1119 Log: - translated part of ch03.xml Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Tue Aug 28 04:13:33 2007 @@ -4037,7 +4037,7 @@ システムによっては、 firsttermunverified/firstterm とか firsttermunstarted/firstterm といったラベルを付与するものもあります。 まだ誰もこの問題を担当していません。システムによっては、 -担当が決まっていないことを表すためにダミーの担当者をあてがうものもあります。 +担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。 この時点では、問題は一時的な領域に置かれています。つまり、 システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。/para /listitem @@ -4293,18 +4293,24 @@ 問題が解決される割合は開発者コミュニティの規模やスキルに左右されますが、 プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。 たとえ問題が解決されずにしばらく残り続けても、 -開発者からの返答は問題を報告する人に引き続き参加する意欲を与えます。 +開発者が返答すると、問題を報告した人は引き続き参加したいと考えます。 なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、 たとえば電子メールを送ること以上に労力がいることを思い出してください) それ以上に、問題をいったん開発者が見れば、 -開発者が報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、 +報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、 プロジェクトが問題を認識したことになります。 /para +!-- paraThe need for timely reactions implies two things: +-- + +para +適切なタイミングで問題に返答するには、次の二つが必要です。 itemizedlist listitem +!-- paraThe tracker must be connected to a mailing list, such that every change to an issue, including its initial filing, causes a mail to go out describing what happened. This mailing list @@ -4312,8 +4318,20 @@ all developers may want to receive automated bug mails, but (just as with commit mails) the Reply-to header should be set to the development mailing list./para +-- + +para +問題を報告することを含めた、問題の状態を変更するあらゆる行動が、 +何が起きているのかを説明した上でメールで投稿されるように、 +バグ追跡システムをメーリングリストと接続しなければいけません。 +このメーリングリストは通常使う開発用のものとは違うのが普通です。 +なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。 +しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。 +/para + /listitem listitem +!-- paraThe form for filing issues should capture the reporter's email address, so she can be contacted for more information. (However, it should not emphasisrequire/emphasis the @@ -4322,6 +4340,16 @@ xref linkend=anonymity/phrase output=printed later in this chapter/phrase for more on the importance of anonymity.)/para +-- + +para +問題を報告するときの記入フォームは、 +報告する人の電子メールアドレスの入力欄にフォーカスを当てておくべきです。 +(しかし、匿名で報告したいと思う人もいるので、 +電子メールアドレスを emphasis必須/emphasis にすべきではありません。 +匿名の重要性については、 +phrase output=printedこの章の後半にある/phrase xref linkend=anonymity/ を参照してください。 +/para /listitem /itemizedlist ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1099 - trunk/ja
Author: mumumu Date: Sat Aug 25 14:52:06 2007 New Revision: 1099 Log: - translated part of ch07. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Aug 25 14:52:06 2007 @@ -49,10 +49,10 @@ 新機能の開発や重大でないバグフィックスは、 リリースが終わるまで脇に置いてくれと開発チーム全体に求めることができます。 ボランティアの集団はそんな一枚岩ではありません。 -オープンソースプロジェクトの人々は様々な理由で動いています。 +オープンソースプロジェクトの人々は様々な理由で働いています。 よってリリース作業を手伝うことに興味がない人たちは、 たとえリリース作業が進行中でも日々の開発作業を続けたいと考えます。 -開発は止まることがありませんので、 +開発が止まることはないので、 オープンソースソフトウェアのリリース作業は、 プロプラエタリなそれに比べて時間がかかりがちですが、 混沌としたものではありません。 @@ -63,7 +63,7 @@ もうひとつは、一度にひとつの車線でだけ作業を行い、 もう一方は通行できるようにしておくことです。 はじめのやり方は emphasis修理を行なう作業員にとっては/emphasis 効率がいいやり方ですが、 -作業員以外の人には効率がよくありません mdash; 作業が終わるまで道路全体が閉鎖されるからです。 +それ以外の人にはよくありません mdash; 作業が終わるまで道路全体が閉鎖されるからです。 ふたつめのやり方は時間がかかり、修理する作業員は大変です（少ない人数、少ない機械、 窮屈な環境での作業を強いられる上、 通行する車を徐行させて交通整理をする旗振り役も置かなければいけない、など）が、 @@ -71,7 +71,7 @@ /para - +!-- paraOpen source projects tend to work the second way. In fact, for a mature piece of software with several different release lines being maintained simultaneously, the project is sort of in a permanent state @@ -79,7 +79,19 @@ consistent but low level of background inconvenience is always being tolerated by the development group as a whole, so that releases get made on a regular schedule./para +-- +para +オープンソースプロジェクトはよくふたつめのやり方で動いています。 +実際、複数の異なったリリースラインがある状態で、 +成熟したソフトウェアのモジュールを管理するために、 +プロジェクトはずっと小規模な道路修理を続けているような状態です。 +いつも二つの車線が閉鎖して作業をしています。つまり、 +リリースを定期的なスケジュールに従って行なえるように、 +開発チームは裏で起こるささいな不都合にはいつも目をつぶっているのです。 +/para + +!-- paraThe model that makes this possible generalizes to more than just releases. It's the principle of parallelizing tasks that are not mutually interdependentmdash;a principle that is by no means unique @@ -98,13 +110,45 @@ lot of developers sitting idle a lot of the timemdash;which would be not only inefficient but boring, and therefore dangerous, in that a bored developer is likely to soon be an ex-developer./para +-- +para +この作業モデルはリリース作業以外にも一般化できます。 +互いに依存していないタスクは平行して処理をするという原則です。mdash; +これはオープンソースソフトウェアの開発に限ったものではありませんが、 +オープンソースプロジェクトは、独自のやり方でこの原則を実践しています。 +プロジェクトで作業をしているボランティア達は、 +道路工事の作業員や通行する車を気にする余裕はそんなにありませんし、 +カラーコーンの傍に待機して車に旗を振らせることに作業員を専念させる余裕もないのです。 +つまり、彼らはプロジェクト管理の負荷の変化が激しい管理プロセスよりは、 +負荷が一定か、変化が少なくなるようなプロセスを好みます。 +ボランティアたちは、ちょっと不便だなと思う状態が続いても嫌がりません。 +自分にかかる負荷が予想できるからこそ、 +彼らはプロジェクトで起こっていることがスケジュールと衝突しているかどうかを気にせずに作業できるのです。 +プロジェクトが別の作業をやめてある作業に専念させるようなマスタ－スケジュールに縛られていると、 +多くの開発者が長い間何もしない状態が発生します mdash; これは非効率であるばかりか、 +退屈なものなので危険です。退屈した開発者は、すぐに辞めてしまうでしょう。 +/para + +!-- paraRelease work is usually the most noticeable non-development task that happens in parallel with development, so the methods described in the following sections are geared mostly toward enabling releases. However, note that they also apply to other parallelizable tasks, such as translations and internationalization, broad API changes made gradually across the entire code base, etc./para +-- + +para +リリース作業は、 +平行して行なわれる作業のなかでも開発とは関係ないもっとも目立つタスクです。 +よって次の節で説明するやり方で、 +リリース作業を行なうタイミングを調整しています。 +しかし、リリース作業と平行して行なえる作業、 +たとえば翻訳や国際化、 +コードベース全体に徐々に浸透するようにAPIを大規模に変更する、 +などが同時に行なわれていることに注意してください。 +/para /simplesect ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1101 - trunk/ja
Author: mumumu Date: Sat Aug 25 16:08:04 2007 New Revision: 1101 Log: - fix xml parse error, sorry. Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Sat Aug 25 16:08:04 2007 @@ -196,7 +196,8 @@ para 新しいバグが入り込んでいます。 これは時々行なわれるセキュリティリリース(phrase output=printedこの章の後半の/phrasexref linkend=security-releases/を参照してください)や他の単発リリースを除いて、普通は十分に考えられることです。 -/listitem +/para + /listitem listitem !-- @@ -235,6 +236,7 @@ para 互換性のない変更が入っているかもしれません。たとえば、 古いバージョンで使われていたデータフォーマットはある種の変換を（多分手動で）しないともはや使えなくなっているといったものです。 + /para /listitem /itemizedlist ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1087 - trunk/ja
Author: mumumu Date: Fri Aug 24 04:09:55 2007 New Revision: 1087 Log: - newly started chapter 7 translation for a change. :) Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml == --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Fri Aug 24 04:09:55 2007 @@ -1,13 +1,22 @@ chapter id=development-cycle -titlePackaging, Releasing, and Daily Development/title +titleパッケージの作成、リリース、そして日々の開発/title simplesect +!-- paraThis chapter is about how free software projects package and release their software, and how overall development patterns organize around those goals./para +-- +para +この章では、フリーソフトウェアのプロジェクトが、 +ソフトウェアをパッケージングしてリリースする方法と、 +開発パターン全体がこれらの目標にどう繋がっているのかについて述べていきます。 +/para + +!-- paraA major difference between open source projects and proprietary ones is the lack of centralized control over the development team. When a new release is being prepared, this difference is especially @@ -30,6 +39,38 @@ with fewer people and less equipment, in cramped conditions, with flaggers to slow and direct traffic, etc.), but at least the road remains useable, albeit not at full capacity./para +-- + +para +オープンソースプロジェクトとプロプラエタリなプロジェクトの主な違いは、 +開発チームに対して中央集権的な管理が行なわれているかどうかにあります。 +新しいリリースを準備しているとき、この違いは特にはっきりします。 +プロプラエタリな企業は、今度のリリースにかかわる作業に集中し、 +新機能の開発や重大でないバグフィックスは、 +リリースが終わるまで脇に置いてくれと開発チーム全体に求めることができます。 +ボランティアの集団はそんな一枚岩ではありません。 +オープンソースプロジェクトの人々は様々な理由で動いています。 +よってリリース作業を手伝うことに興味がない人たちは、 +たとえリリース作業が進行中でも日々の開発作業を続けたいと考えます。 +開発は止まることがありませんので、 +オープンソースソフトウェアのリリース作業は、 +プロプラエタリなそれに比べて時間がかかりがちですが、 +混沌としたものではありません。 +これは高速道路の修復にちょっと似ています。 +道路を直すには二つやり方があります。 +ひとつは、道路全体に作業員が群がって問題が解決するまで全力で働けるように、 +道路を完全に閉鎖することです。 +もうひとつは、一度にひとつの車線でだけ作業を行い、 +もう一方は通行できるようにしておくことです。 +はじめのやり方は emphasis修理を行なう作業員にとっては/emphasis 効率がいいやり方ですが、 +作業員以外の人には効率がよくありません mdash; 作業が終わるまで道路全体が閉鎖されるからです。 +ふたつめのやり方は時間がかかり、修理する作業員は大変です（少ない人数、少ない機械、 +窮屈な環境での作業を強いられる上、 +通行する車を徐行させて交通整理をする旗振り役も置かなければいけない、など）が、 +作業員が全力を出さなくても少なくとも道路は使いやすい状態のままです。 +/para + + paraOpen source projects tend to work the second way. In fact, for a mature piece of software with several different release lines being ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1082 - trunk/ja
Author: mumumu Date: Thu Aug 23 17:05:59 2007 New Revision: 1082 Log: - translated part of bug tracking section. Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Thu Aug 23 17:05:59 2007 @@ -3977,12 +3977,12 @@ para この本では バグ追跡システム という用語を、 -物事を追跡するソフトウェアを指すものとして使うことにします。 +物事を追跡するソフトウェアを指すものとします。 なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。 しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、 firstterm問題/firstterm という用語を使います。 これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、 -バグの発見、診断、解決に関する emphasis記録/emphasis を区別できるからです。 +バグの発見、診断、解決の emphasis記録/emphasis を区別できるからです。 殆どの問題は実際に起こったバグに関するものですが、 他のタスクに関することでも問題という用語が使えるということを覚えておいてください。 /para @@ -4050,7 +4050,7 @@ para 誰か他の人が問題を読み、コメントを付けます。 -おそらく問題を報告をした人に、不明な点について説明を求めるでしょう。 +おそらく問題を報告した人に、不明な点について説明を求めるでしょう。 /para /listitem listitem @@ -4069,7 +4069,7 @@ これは問題のライフサイクルの中で最も重要なものかもしれません。これは、 まだ解決されたわけではないが、 報告した人以外の誰かが問題を再現でき、 -この問題が本物であると証明したことをいいます。 +この問題が本物だと証明したことをいいます。 そして同じくらい重要なことですが、 報告した人が本物のバグを報告することで、 プロジェクトに貢献したと確認することでもあります。 @@ -4092,7 +4092,7 @@ 問題の原因が特定され、可能なら解決に必要な労力が見積もられます。 これらのことは必ず追跡システムに記録するようにしましょう。 原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、 -誰かがその穴を埋められるようにしておくべきだからです。 +誰かが穴を埋められるようにしておくべきだからです。 /para !-- @@ -4111,8 +4111,8 @@ -- para -この段階、もしくはひとつ前の段階で、 -ある開発者が問題の 所有権を得て 自分自身を firsttermアサイン/firstterm するかもしれません。 +この段階か、もうひとつ前の段階で、 +開発者が問題の 所有権を得て 自分自身を firsttermアサイン/firstterm するかもしれません。 (アサインの手続きをさらに詳細に調べるには phrase output=printedxref linkend=managing-volunteers/の/phrase、 xref linkend=delegation-assignment/ を参照してください) @@ -4122,20 +4122,43 @@ よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。 /para /listitem - listitemparaThe issue gets scheduled for resolution. + listitem +!-- +paraThe issue gets scheduled for resolution. Scheduling doesn't necessarily mean naming a date by which it will be fixed. Sometimes it just means deciding which future release (not necessarily the next one) the bug should be fixed by, or deciding that it need not block any particular release. Scheduling may also be dispensed with, if the bug is quick to fix./para +-- + +para +問題をいつ解決するかという予定が立てられます。 +予定を決めるということは、 +いつまでに直すという日程を決めることとは限りません。 +将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、 +特定のリリースで直すと決めない場合もあります。 +バグが素早く直せる場合には、予定を立てないこともあります。 +/para /listitem - listitemparaThe bug gets fixed (or the task completed, or + listitem +!-- +paraThe bug gets fixed (or the task completed, or the patch applied, or whatever). The change or set of changes that fixed it should be recorded in a comment in the issue, after which the issue is firsttermclosed/firstterm and/or marked as firsttermresolved/firstterm./para +-- + +para +問題は解決されます。（タスクが終了したり、 +パッチが適用されたりとか、そういったものです） +行った変更は、問題がfirsttermクローズされた/firsttermり、 +firsttermresolved/firstterm とマークされたあとに、 +コメントとして記録するようにしましょう。 +/para /listitem /orderedlist ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1063 - trunk/ja
Author: mumumu Date: Wed Aug 22 03:43:17 2007 New Revision: 1063 Log: - fix translation by convention.txt Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Wed Aug 22 03:43:17 2007 @@ -1880,7 +1880,7 @@ 同じ URL を保つようにしておけば、サーチエンジンに捕捉されやすくなります。 これは、利用者にとって大きな利点となるでしょう。 URL を保ち続けるよう心がけるもうひとつの理由としては、 -メーリングリストの投稿やスレッドがバグトラッカー +メーリングリストの投稿やスレッドがバグ追跡システム (phrase output=printed本章の後半/phraseの xref linkend=bug-tracker/ を参照してください) や他のプロジェクトのドキュメントからリンクされることが多いということもあります。 @@ -3030,7 +3030,7 @@ para 「編集可能なデータはすべてバージョン管理下におかなければならない」 という規則には、残念ながらひとつだけ例外があります。 - それがバグトラッカーです。 + それが バグ追跡システム です。 バグデータベースは編集可能なデータを大量に保持していますが、 技術的な理由により、このデータをバージョン管理することはできません (バグトラッカーの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。 @@ -3666,7 +3666,7 @@ para これまで説明してきたことからも何となくお分かりでしょうが、 特定のリビジョンを参照する際の表記方法は統一しておいたほうがいいでしょう。 - これは、ログメッセージだけでなくメールやバグトラッカーなどでも同じです。 + これは、ログメッセージだけでなくメールやバグ追跡システムなどでも同じです。 CVS を使っているのなら、 literalpath/to/file/in/project/tree:REV/literal という形式をお勧めします。ここで、REV は CVS のリビジョン番号 @@ -3927,12 +3927,12 @@ -- para -バグ追跡は扱う範囲が広い話題です。 -つまり、この本ではバグ追跡についての様々な側面を議論しています。 -ここではバグ追跡システムをセットアップすることと、 -その作業に関する技術的な考察をすることに集中したいと思います。 -その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。 -: 具体的にどんな情報をバグ追跡システムに保存すべきなのでしょうか? +バグ追跡 は扱う範囲が広い話題です。 +この本では バグ追跡 についての様々な側面を議論しています。 +ここでは バグ追跡システム をセットアップすることと、 +その作業に関する技術的な考察をすることに集中しようと思います。 +その話題に入る前に、バグ追跡 の方針に関する質問から始めましょう。 +: 具体的にどんな情報を バグ追跡システム に保存すべきなのでしょうか? /para !-- @@ -3953,16 +3953,17 @@ firsttermバグ追跡システム/firstterm は、誤解を招きやすい用語です。 バグ追跡システム は、新しい機能要望や、一度限りのタスク、 送られてきたパッチ mdash; はじまりと終わりの状態があるすべてのもの、 -存在している間に情報が発生するものをすべて追跡するためによく使われます。 -このため、バグ追跡システムは、 +存在している間に情報が発生するすべてのものを追跡するためによく使われます。 +このため、バグ追跡システム は、 firstterm問題追跡システム/firstterm、 firstterm不具合追跡システム/firstterm、 firstterm影響追跡システム/firstterm、 firstterm要望追跡システム/firstterm、 firsttermチケットシステム/firstterm などとも呼ばれています。 -バグ追跡システムのソフトウェアの一覧は、xref linkend=bug-trackers/ を参照してください。 +バグ追跡システム のソフトウェアの一覧は、xref linkend=bug-trackers/ を参照してください。 /para +!-- paraIn this book, I'll continue to use bug tracker for the software that does the tracking, because that's what most people call it, but will use firsttermissue/firstterm to refer to a single @@ -3972,6 +3973,19 @@ bug's discovery, diagnosis, and eventual resolution. Keep in mind that although most issues are about actual bugs, issues can be used to track other kinds of tasks too./para +-- + +para +この本では バグ追跡システム という用語を、 +物事を追跡するソフトウェアを指すものとして使うことにします。 +なぜなら、殆どの人が バグ追跡システム と呼んでいるからです。 +しかし、バグ追跡システム のデータベースに登録される個々のアイテムを指すものとして、 +firstterm問題/firstterm という用語を使います。 +これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、 +バグの発見、診断、解決に関する emphasis記録/emphasis を区別できるからです。 +殆どの 問題 は実際に起こったバグに関するものですが、 +他のタスクに関することでも 問題 という用語が使えるということを覚えておいてください。 +/para paraThe classic issue life cycle looks like this: ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1060 - trunk/ja
Author: mumumu Date: Tue Aug 21 16:05:50 2007 New Revision: 1060 Log: - test commit - translated one paragraph of bug tracking section. Modified: trunk/ja/ch03.xml Modified: trunk/ja/ch03.xml == --- trunk/ja/ch03.xml (original) +++ trunk/ja/ch03.xml Tue Aug 21 16:05:50 2007 @@ -3935,6 +3935,7 @@ : 具体的にどんな情報をバグ追跡システムに保存すべきなのでしょうか? /para +!-- paraThe term firsttermbug tracker/firstterm is misleading. Bug tracking systems are also frequently used to track new feature requests, one-time tasks, unsolicited patchesmdash;really anything @@ -3946,6 +3947,21 @@ trackers/firstterm, firsttermtrouble ticket systems/firstterm, etc. See xref linkend=bug-trackers/ for a list of software. /para +-- + +para +firsttermバグ追跡システム/firstterm は、誤解を招きやすい用語です。 +バグ追跡システム は、新しい機能要望や、一度限りのタスク、 +送られてきたパッチ mdash; はじまりと終わりの状態があるすべてのもの、 +存在している間に情報が発生するものをすべて追跡するためによく使われます。 +このため、バグ追跡システムは、 +firstterm問題追跡システム/firstterm、 +firstterm不具合追跡システム/firstterm、 +firstterm影響追跡システム/firstterm、 +firstterm要望追跡システム/firstterm、 +firsttermチケットシステム/firstterm などとも呼ばれています。 +バグ追跡システムのソフトウェアの一覧は、xref linkend=bug-trackers/ を参照してください。 +/para paraIn this book, I'll continue to use bug tracker for the software that does the tracking, because that's what most people call ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r1062 - trunk/ja
Author: mumumu Date: Tue Aug 21 17:20:14 2007 New Revision: 1062 Log: - initially added Added: trunk/ja/conventions.txt ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
[ProducingOSS commit] r886 - trunk/ja
Author: mumumu Date: Tue Aug 7 02:32:55 2007 New Revision: 886 Log: - fixed title, author, copyright. Modified: trunk/ja/book.xml Modified: trunk/ja/book.xml == --- trunk/ja/book.xml (original) +++ trunk/ja/book.xml Tue Aug 7 02:32:55 2007 @@ -20,7 +20,7 @@ ] book id=poss lang=ja -titleオープンソースのつくりかた/title +titleオープンソースソフトウェアのつくりかた/title subtitleフリーソフトウェアプロジェクトを成功させるコツ/subtitle bookinfo @@ -31,11 +31,13 @@ contrib(著者)/contrib/author authorfirstname正弘/firstnamesurname高木/surname contrib(翻訳者)/contrib/author +authorfirstnameYoshinari/firstnamesurnameTakaoka/surname +contrib(翻訳者)/contrib/author /authorgroup editorfirstnameAndy/firstnamesurnameOram/surname/editor pagenums272 pages/pagenums !-- pubdate2005/pubdate -- - copyrightyear2005, 2006, 2007/yearholderKarl Fogel, 高木正弘, under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0)/holder/copyright + copyrightyear2005, 2006, 2007/yearholderKarl Fogel, 高木正弘, Yoshinari Takaoka, under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0)/holder/copyright /bookinfo !-- External entity refs -- ___ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
