[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
devel/constitution (1.18)
こんばんわBです
devel/constitution;
http://kmuto.jp/debian/web-trans/index.rhtml の頭に有ったので(汗
タグ変えたらdiffが巨大になったので-iしたのと全文をつけてみます。
diffの最後はどーもよくわからないので放置(汗
--
victory
don't include my addresses in mail body...
--------------------------------------------------------
Index: constitution.wml
===================================================================
RCS file: /cvs/webwml/webwml/japanese/devel/constitution.wml,v
retrieving revision 1.10
diff -u -u -i -r1.10 constitution.wml
--- constitution.wml 20 Dec 2004 19:49:14 -0000 1.10
+++ constitution.wml 2 Oct 2006 08:32:44 -0000
@@ -1,11 +1,11 @@
#use wml::debian::template title="Debian 憲章" BARETITLE="true"
-#use wml::debian::translation-check translation="1.16"
+#use wml::debian::translation-check translation="1.18"
-<H1>Debian プロジェクト憲章 (v1.2)</H1>
+<h1>Debian プロジェクト憲章 (v1.3)</h1>
<H2>1. はじめに</H2>
-<P>Version 1.2 は 2003 年 10 月 29 日に批准され、Version 1.1 を更新した。
+<p>Version 1.3 は 2006 年 9 月 24 日に批准され、Version 1.1 を更新した。
<a href="constitution.1.1">Version 1.1</a> は 2003 年 6 月 21 日に批准され、
Version 1.0 を更新した。
<a href="constitution.1.0">Version 1.0</a> は 1998 年 12 月 2 日に批准された。
@@ -134,11 +134,13 @@
</LI>
<LI>
- <P>プロジェクトリーダおよび代行者の決定を覆すことができる。</P>
+ <p>プロジェクトリーダおよび代行者による決定に対して、
+ 最終判断や無効化ができる。</p>
</LI>
<LI>
- <P>2:1 の賛成多数をもって、技術委員会の判断を覆すことができる。</P>
+ <p>2:1 の賛成多数をもって、技術委員会の決定に対して、
+ 最終判断や無効化ができる。</p>
</LI>
<LI>
@@ -155,25 +157,30 @@
<OL style="list-style: decimal;">
<LI>「基本文書 (Foundation Document)」とは、
Debian プロジェクトの使命や目的にとって
- 決定的に重要とみなされる文書または声明である。
+ 決定的に重要とみなされる文書または声明である。</li>
<LI>「基本文書」は、
<q>「Debian 社会契約 (Debian Social Contract)」</q>
および <q>「Debian フリーソフトウェアガイドライン
(Debian Free Software Guidelines)」</q>
- というタイトルの文書である。
+ というタイトルの文書である。</li>
<LI>「基本文書」を更新するためには、3:1 の多数決を必要とする。
新たな「基本文書」の発行や既存の「基本文書」の撤回は、
この憲章のリストを修正することによってなされる。
#J-TODO このへんの固有名詞の訳語要 check (or regist)
+ </li>
</OL>
</LI>
<LI>
- <P>プロジェクトリーダおよび SPI と協力して、
- Debian に関連する目的のために保有されている
+ <p>Debian に関連する目的のために保有されている
資産に関する決定をする。 (9.1節を見よ。)</P>
</LI>
+
+ <li>
+ <p>プロジェクトリーダーと書記の間で意見が統一できない場合は、
+ 新しい書記を擁立する。</p>
+ </li>
</OL>
<H3>4.2. 意思決定手順</H3>
@@ -195,7 +202,7 @@
<LI>プロジェクトリーダ、その代行者、
技術委員会のいずれかが何らかの決定をした場合、
開発者は修正決議を通すことによりその決定を覆すことができる。
- 4.1節(3) を見よ。</LI>
+ 4.1 節 (3) を見よ。</li>
<LI>そのような決議文が、2*K 人以上の開発者が賛同者となっているか、
もしくは技術委員会によって提案されている場合には、
@@ -263,7 +270,7 @@
<OL>
<LI>
- <P>代行者を任命する。または決定を技術委員会に委任する。
+ <p>代行者を任命する。または決定を技術委員会に委任する。</p>
<P>プロジェクトリーダは、その職責の一部や特定の決断事項を定義して、
その責任や決定を他の開発者や技術委員会に委任できる。</P>
@@ -299,7 +306,7 @@
</LI>
<LI>
- <P>技術委員会とともに、委員会の新メンバーを任命する (6.2節を見よ)。</P>
+ <p>技術委員会とともに、委員会の新メンバーを任命する (6.2 節を見よ)。</p>
</LI>
<LI>
@@ -323,8 +330,20 @@
</LI>
<LI>
- <P>SPI と共に、Debian に関連した目的のために
- 信託されている財産に関わる決定をする (9.1節を見よ)。</P>
+ <p>開発者と協議して、Debian
+ に関連する目的のために保有されている資産に関する決定をする。
+ (9.1 節を見よ。)
+ この種の決定事項はプロジェクトリーダ (または代行者)
+ がメンバーに通知する。主な経費については、
+ 支払いの前にメーリングリストで提案、協議すべきである。</p>
+ </li>
+ <li>
+ <p>信頼された組織 (9.3 節を見よ)
+ のリストに対する追加や削除。この種の決定にあたっては、
+ プロジェクトリーダまたは代行者が指定する、
+ どの開発者でも投稿可能な電子によるメーリングリストにおいて評価、
+ 協議する。信頼された組織のリストへの追加にあたっては、
+ その決定前に最低二週間以上、協議の期間をおく。</p>
</LI>
</OL>
@@ -354,8 +373,8 @@
<LI>
決定は「標準議事手順 (Standard Resolution Procedure)」の
- A.6節で指定される方法によって行われる。
- 必要最低得票数は一般決議 (4.2節) の場合と同じで、
+ A.6 節で指定される方法によって行われる。
+ 必要最低得票数は一般決議 (4.2 節) の場合と同じで、
デフォルトの選択肢は「全員不可」である。
</LI>
@@ -383,9 +402,8 @@
<LI>
<P>技術的な方針に関するあらゆる事項に関して決定をする。</P>
- <P>これには、技術的方針マニュアルの内容、
- 開発者のリファレンス類、見本パッケージ、
- 実用段階のパッケージ構築ツールの動作などが含まれる
+ <p>これには、技術的方針マニュアルの内容、開発者のリファレンス類、
+ 見本パッケージ、実用段階のパッケージ構築ツールの動作などが含まれる
(しかし各事項に対する最初の決定は、
まずそのソフトウェアや文書のメンテナが行う。6.3節(5) を見よ)。</P>
</LI>
@@ -394,11 +412,9 @@
<P>複数の開発者の管轄権が絡む技術的問題を判断する。</P>
<P>複数の開発者間で技術的方針や立場を調整する必要があるとき
- (たとえば競合するパッケージ間の優先順位、
- コマンド名の所有権、
+ (たとえば競合するパッケージ間の優先順位、コマンド名の所有権、
あるバグが (バグであることは関係者全員が認めているとして)
- どのパッケージの責任なのか、
- あるパッケージのメンテナが誰か、
+ どのパッケージの責任なのか、あるパッケージのメンテナが誰か、
などについて開発者間で意見の相違があるとき)、
技術委員会はその件に関する決定を行える。</P>
</LI>
@@ -424,8 +440,7 @@
<LI>
<P>答申をする。</P>
- <P>技術委員会は、どのような件に関しても、
- 委員会の正式見解を公表してよい。
+ <p>技術委員会は、どのような件に関しても委員会の正式見解を公表してよい。
<CITE>技術委員会の個々のメンバーは、
もちろん自分の見解や技術委員会の見解 (とそのメンバーが考えるもの)
に関する非公式な声明を発してよい。</CITE></P>
@@ -433,7 +448,7 @@
<LI>
<P>プロジェクトリーダとともに、技術委員会自身の新メンバーを任命し、
- また現在のメンバーを解任する (6.2節を見よ)。</P>
+ また現在のメンバーを解任する (6.2 節を見よ)。</p>
</LI>
<LI>
@@ -450,14 +465,14 @@
投票は全メンバーの投票が終了した時点、
あるいは投票期限が過ぎた時点で終了する。
結果は「標準議事手順 (Standard Resolution Procedure)」の
- A.6節で指定される方法によって決定される。
+ A.6 節で指定される方法によって決定される。
</P>
</LI>
<LI>
<P>議長はプロジェクト書記とともにリーダを代行できる。</P>
- <P>7.1節(2) に述べる通り、技術委員会の議長とプロジェクト書記とは、
+ <p>7.1 節 (2) に述べる通り、技術委員会の議長とプロジェクト書記とは、
リーダ不在の際に共同でリーダを代行できる。</P>
</LI>
</OL>
@@ -541,8 +556,7 @@
あるいは通常の技術方針立案の場で議論しながら共同で、
行われるべきものである。</P>
- <P>技術委員会がする作業は、
- 複数の解決法や決断の中から選択をしたり、
+ <p>技術委員会がする作業は、複数の解決法や決断の中から選択をしたり、
それらの折衷案を採ったりすることに限られる。
それらの案は、他の場所で提案され、
そこで充分な議論を受けたものであるべきである。</P>
@@ -579,8 +593,7 @@
<P>プロジェクトリーダが不在の際、
技術委員会の議長とプロジェクト書記の両名は、
- 両者が緊急と考えた場合には、
- 合意に基づいて決定を行える。</P>
+ 両者が緊急と考えた場合には、合意に基づいて決定を行える。</p>
</LI>
<LI>
@@ -593,14 +606,14 @@
</LI>
</OL>
-<H3>7.2. 任命 </H3>
+<h3>7.2. 任命</h3>
<P>プロジェクト書記は、プロジェクトリーダと
現在のプロジェクト書記とによって指名される。</P>
<P>プロジェクトリーダと現在のプロジェクト書記との間で、
-この指名に関して合意ができなかった場合には、
-両名は SPI の役員会 (9.1節を見よ) に書記の指名を依頼しなければならない。</P>
+この指名に関して合意ができなかった場合には、両名は一般決議を通して、
+開発者に書記の指名を依頼しなければならない。</p>
<P>プロジェクト書記が不在または職務を遂行できない状態であり、
かつ決定権限の委任をしていない場合は、
@@ -652,65 +665,66 @@
それが技術的に良いものであるよう、
また開発者の総意に則るよう、努めるべきである。</P>
-<H2>9. Software in the Public Interest</H2>
+<h2>9. Debian に信託されている資産</h2>
+
+<p>世界中のほとんどの法律では Debian
+プロジェクトは資産その他の財産を直接保有できる立場にはない。したがって、
+9.2 節で述べるように、財産はいくつかの組織が保有しなければならない。
+</p>
+
+<p>SPI はもともと Debian の資産や財産の保有を公認された唯一の組織でした。
+SPI は実際のところ、財産を保持するためにアメリカで作られた。</p>
<P><a href="http://www.spi-inc.org";>SPI</a>
と Debian は、いくつかの目的を共有する、別々の組織である。
Debian は SPI によって提供される法的支援の枠組みに感謝する。</P>
-<CITE>現在のところ Debian の開発者は、
-開発者であることをもって同時に SPI のメンバーとなる。</CITE>
-
-<H3>9.1. 権限</H3>
+<h3>9.1. 関連組織との関係</h3>
+
<OL>
- <LI>SPI は Debian の技術的・非技術的な決定に関連する権限は一切持たない。
- ただし SPI が保有する資産に関連する Debian の決定は、
- SPI に法的権限を外れて行動することを求めてはならない。
- また Debian の組織は、臨時に SPI を (他に手段がない場合の)
- 決定主体とすることができる。</LI>
-
- <LI>Debian は SPI に対して、SPI の特定の資産を利用する権利 (後述)
- 以外の権利を有しないが、Debian の各開発者は
- SPI の規則のもとに SPI 内部での権限を与えられる。</LI>
-
- <LI>Debian の開発者は SPI の代理人でも雇用者でもない。
- また開発者は集団としても個人としても Debian プロジェクトの代表者ではない。
- Debian 開発者として行動する個人は、
- 個人として自らの信念に従って行動する。</LI>
+ <li>
+ <p>Debian 開発者は Debian
+ に信託された資産を保有する組織の代理人や従業員となるわけではない。
+ その逆、あるいは Debian 開発者であることによる Debian
+ プロジェクトでの権限についても同様である。
+ 開発者として行動する個人はあくまで個人として、個人の目的で行動する。
+ この種の組織は、当事者同士の合意を持って Debian
+ 開発者である個人との関係を作ることができる。</p>
+ </li>
</OL>
-<H3>9.2. Debian に関係した目的のための資産の管理</H3>
-
-<P>Debian は金銭や財産を保有する権限を有しないため、
-Debian プロジェクトに対する寄付は、
-そのような事柄を管理する SPI に対してなされなければならない。</P>
-
-<P>SPI は以下を委託されている。</P>
+<h3>9.2. Authority</h3>
<OL>
- <LI>SPI は、金銭・商標およびその他の有形または無形の資産を保有し、
- その他 Debian に関連する目的のための事柄を管理する。</LI>
-
- <LI>そのような資産は個別に管理され、
- この節の記述に則って Debian と SPI とによって決定される
- 目的のために信託される。</LI>
-
- <LI>SPI は Debian からの承認がない限り、
- 信託された資産を処理も利用もしない。
- このような承認は、プロジェクトリーダによって、
- もしくは開発者の一般決議によって与えられる。</LI>
+ <li>
+ <p>Debian の資産を保有する組織は Debian
+ の技術的、非技術的な決定に関連する権限は一切持たない。
+ ただしこの組織が保有する資産に関連する Debian
+ の決定は、この組織に法的権限を外れて行動することを求めてはならない。
+ </p>
+ </li>
+ <li>
+ <p>Debian は資産を保有する組織に対して、Debian
+ に信託された資産を利用する権利(後述) 以外の権利を有しない。</p>
+ </li>
+</ol>
- <LI>SPI は、プロジェクトリーダからその旨の要請があった場合、
- Debian より信託された資産の利用ないし処理を検討する。</LI>
+<h3>9.3. 信頼された組織</h3>
- <LI>SPI は、開発者の一般決議によりその旨の要請があった場合、
- それが SPI の法的権限の及ぶ範囲であるならば、
- Debian より信託された資産を利用ないし処理する。</LI>
+<p>Debian プロジェクトへの寄付はプロジェクトリーダ (または代理人) が指定した、
+Debian プロジェクトのために使われる資産の処理を公認された
+組織のどれかに対して行われなければならない。
+</p>
+
+<p>Debian
+に信託された資産を保有する組織はこの種の資産について適切な責任を持つべきである。
+</p>
- <LI>Debian より信託された資産を利用ないし処理する際には、
- SPI は Debian プロジェクトのメーリングリストに電子メールを送り、
- 開発者に対して通知する。</LI>
-</OL>
+<p>Debian は寄付と Debian に信託された資産
+(これには有形財産も知的財産も含まれる)
+の保有を承認された、信頼された組織の公開リストを管理する。
+that includes the commitments those organisations have made as to how those assets will be handled.
+</p>
<H2>A. 標準議事手順 (Standard Resolution Procedure)</H2>
--------------------------------------------------------
#use wml::debian::template title="Debian 憲章" BARETITLE="true"
#use wml::debian::translation-check translation="1.18"
<h1>Debian プロジェクト憲章 (v1.3)</h1>
<h2>1. はじめに</h2>
<p>Version 1.3 は 2006 年 9 月 24 日に批准され、Version 1.1 を更新した。
<a href="constitution.1.1">Version 1.1</a> は 2003 年 6 月 21 日に批准され、
Version 1.0 を更新した。
<a href="constitution.1.0">Version 1.0</a> は 1998 年 12 月 2 日に批准された。
</p>
<p><cite>Debian プロジェクトは、
フリーなオペレーティングシステムを作る、
という共通の目的を持った人々の連合体である。</cite></p>
<p>この文書は、Debian プロジェクトの公式な意思決定に関わる
組織構成について記述する。
Debian プロジェクトの目的やその実現方法については記述しない。
また意思決定プロセスに直接関連するものを除き、
方針 (policy) についても記述しない。</p>
<h2>2. 意思決定機関と個人</h2>
<p>このプロジェクトの意思決定は、
以下のひとつまたは複数によってなされる。</p>
<ol>
<li>開発者 (Developer) の集団
(一般決議 (General Resolution) および選挙による)</li>
<li>プロジェクトリーダ</li>
<li>技術委員会 (Technical Committee) およびその議長</li>
<li>特定の作業に従事している開発者個人</li>
<li>プロジェクトリーダから特定の作業を委任された代行者 (Delegate)</li>
<li>プロジェクト書記 (Project Secretary)</li>
</ol>
<p>この文書の以降の大部分では、上記各主体の権限、
それらの構成、任命手続き、意思決定手順を概観していく。
上記の個人・組織の権限は、他者に監査もしくは制約される場合がある。
その場合、監査する側の組織・個人の項目にてそのことを示す。
<cite>上記のリストで先に挙げられている個人ないし組織は、
後に挙げられている者より一般に高い決定権を持つ。
あるいは前者は後者を任命する、という関係にある。
ただし先に挙げられている者が後に挙げられている者の決定を
常に変更できるわけではない。</cite></p>
<h3>2.1. 総則</h3>
<ol>
<li>
<p>この憲章におけるあらゆる記述は、
誰かにこのプロジェクトに対する作業を義務づけようとするものではない。
委任された、
または割り当てられた仕事をしたくない場合には、それをする必要はない。
しかし、この憲章の規則に反した、
またこの憲章に従って適切になされた決定に反した行動を、
意図的にとってはならない。</p>
</li>
<li>
<p>あるひとりの個人は複数のポストを兼任できるが、プロジェクトリーダ、
プロジェクト書記、技術委員会議長の三つのポストは例外であり、
この三つのポストには別々の人がつかなければならない。
またプロジェクトリーダは自分自身を代行者に選んではならない。</p>
</li>
<li>
<p>ある個人は、公にその旨を表明することによって、
いつなんどきでもこのプロジェクトを去ったり、
特定のポストから辞任できる。</p>
</li>
</ol>
<h2>3. 個々の開発者</h2>
<h3>3.1. 権限</h3>
<p>個々の開発者は以下の権限を持つ。</p>
<ol>
<li>自分の作業対象の範囲で、技術的あるいは非技術的な決定をする。</li>
<li>一般決議の草案を提案する、またはその賛同者となる。</li>
<li>選挙の際、プロジェクトリーダに立候補する。</li>
<li>一般決議およびリーダの選挙に対して投票する。</li>
</ol>
<h3>3.2. 構成と任命</h3>
<ol>
<li>
<p>開発者は、このプロジェクトに参加している間、
その目的を進めることに同意したボランティアの集まりである。
開発者はプロジェクトのパッケージの維持管理や、
(プロジェクトリーダ代行者が有意義であると考える)
その他の仕事に従事する。</p>
</li>
<li>
<p>プロジェクトリーダ代行者は新規の開発者を拒絶できる。
また既存の開発者を解任できる。
<cite>代行者がその権限を濫用していると開発者たちが考えた場合には、
もちろん一般決議によってその決定を変更できる。
4.1節(3) および 4.2節を見よ。</cite></p>
</li>
</ol>
<h3>3.3. 意思決定手順</h3>
<p>開発者は、自分が適切と考える通りに決定をしてよい。</p>
<h2>4. 開発者の集団 (一般決議および選挙による)</h2>
<h3>4.1. 権限</h3>
<p>開発者は集合体として以下の権限を持つ。</p>
<ol>
<li>
<p>プロジェクトリーダを任命、罷免できる。</p>
</li>
<li>
<p>3:1 の賛成多数をもって、この憲章を修正できる。</p>
</li>
<li>
<p>プロジェクトリーダおよび代行者による決定に対して、
最終判断や無効化ができる。</p>
</li>
<li>
<p>2:1 の賛成多数をもって、技術委員会の決定に対して、
最終判断や無効化ができる。</p>
</li>
<li>
<p>技術的なものではない方針
(policy) 文書や宣言を公表・更新・撤回できる。</p>
<p>これらには、このプロジェクトの目的を述べた文書、
他のフリーソフトウェア組織との関係を述べた非技術的な方針ガイドライン
(たとえば Debian のソフトウェアの満たすべきフリーソフトウェアの許諾条件)
などが含まれる。</p>
<p>また日時に関わる立場の表明などもこれらの文書に含まれる。</p>
<ol style="list-style: decimal;">
<li>「基本文書 (Foundation Document)」とは、
Debian プロジェクトの使命や目的にとって
決定的に重要とみなされる文書または声明である。</li>
<li>「基本文書」は、
<q>「Debian 社会契約 (Debian Social Contract)」</q>
および <q>「Debian フリーソフトウェアガイドライン
(Debian Free Software Guidelines)」</q>
というタイトルの文書である。</li>
<li>「基本文書」を更新するためには、3:1 の多数決を必要とする。
新たな「基本文書」の発行や既存の「基本文書」の撤回は、
この憲章のリストを修正することによってなされる。
#J-TODO このへんの固有名詞の訳語要 check (or regist)
</li>
</ol>
</li>
<li>
<p>Debian に関連する目的のために保有されている
資産に関する決定をする。 (9.1節を見よ。)</p>
</li>
<li>
<p>プロジェクトリーダーと書記の間で意見が統一できない場合は、
新しい書記を擁立する。</p>
</li>
</ol>
<h3>4.2. 意思決定手順</h3>
<ol>
<li>
<p>開発者の集団は後述する
「標準議事手順 (Standard Resolution Procedure)」に従う。
決議文ないし修正案は、ある開発者によって提案され、
K 人以上の開発者がその賛同者となれば、議事の対象となる。
またプロジェクトリーダまたは技術委員会から提案された
決議文ないし修正案は議事の対象となる。</p>
</li>
<li>
<p>プロジェクトリーダまたはその代行者による決定を保留する:</p>
<ol>
<li>プロジェクトリーダ、その代行者、
技術委員会のいずれかが何らかの決定をした場合、
開発者は修正決議を通すことによりその決定を覆すことができる。
4.1 節 (3) を見よ。</li>
<li>そのような決議文が、2*K 人以上の開発者が賛同者となっているか、
もしくは技術委員会によって提案されている場合には、
決議文にその旨を記すことによって、
その決議文の対象である決定を直ちに保留とすることができる。</li>
<li>問題となっている決定が討論期間もしくは
投票期間の変更に関するものであるか、
あるいはその決定が技術委員会の決定を覆すためのものである場合には、
K 人の開発者が賛同者となることにより、
問題となっている決定を直ちに保留とすることができる。</li>
<li>その決定が保留となった場合は、直ちに投票が実施され、
正規の投票が終了するまでのあいだ、
その決定の実施を有効とするか、実施せずに保留とするかを定める。
この緊急投票では必要最低得票数は定めない。</li>
<li>もしプロジェクトリーダ (または代行者) が
もともとの決定を撤回した場合には、
投票は未決とし、それ以上の処置はしない。</li>
</ol>
</li>
<li>
<p>投票はプロジェクト書記が処理する。
投票内容・集計・結果は、いずれも投票期間中には公表されない。
投票終了後、プロジェクト書記は投票内容のリストを公表する。
投票期間は二週間であるが、
プロジェクトリーダは一週間以内の範囲でこれを変更できる。
</p>
</li>
<li>
<p>最短の討論期間は二週間であるが、
プロジェクトリーダは一週間以内の範囲でこれを変更できる。
プロジェクトリーダは決定票 (casting vote) を持つ。
必要最低得票数は 3*Q である。</p>
</li>
<li>
<p>提案、賛同、修正、投票の要請などの正式な手続きは、
プロジェクトリーダ代行者が管理する、
一般から閲覧可能なメーリングリスト上で行われる。
全ての開発者はそのメーリングリストに投稿できる。</p>
</li>
<li>
<p>投票はプロジェクト書記が適切とする方法で、電子メールにて行われる。
プロジェクト書記は、各投票において、
投票者による投票内容の変更を認めるかどうかを決める。</p>
</li>
<li>
<p>Q は現在の開発者数の平方根の半分である。
K は Q と 5 のいずれか小さいほうである。
Q と K は整数である必要はないため、丸めはしない。</P>
</li>
</ol>
<h2>5. プロジェクトリーダ</h2>
<h3>5.1. 権限</h3>
<p><a href="leader">プロジェクトリーダ</a>は以下の権限を持つ。</p>
<ol>
<li>
<p>代行者を任命する。または決定を技術委員会に委任する。</p>
<p>プロジェクトリーダは、その職責の一部や特定の決断事項を定義して、
その責任や決定を他の開発者や技術委員会に委任できる。</p>
<p>特定の決断事項に対する委任がなされた後は、
プロジェクトリーダはその委任を撤回できない。
ただし、職責の一部に対する委任は撤回できる。</p>
</li>
<li>
<p>他の開発者を支持する。</p>
<p>プロジェクトリーダは、求められた場合 (あるいは求められなくても)、
ある意見やプロジェクトのメンバーに対する支持を表明できる。
ただしこの表明は、プロジェクトリーダがその問題に対する
決定権を持っている場合に限って強制力を持つ。</p>
</li>
<li>
<p>緊急を要する決定をする。</p>
<p>その決定の緊急性が (適切な対応がとられなかったために)
徐々に増してきたような場合については、これは適用されない。
ただしその事項に決まった締め切りがある場合は適用される。</p>
</li>
<li>
<p>他に誰も権限を持っていない事項に対する決定をする。</p>
</li>
<li>
<p>一般決議の草案と、その修正案を提案する。</p>
</li>
<li>
<p>技術委員会とともに、委員会の新メンバーを任命する (6.2 節を見よ)。</p>
</li>
<li>
<p>開発者の投票において、決定票を投ずる。</p>
<p>プロジェクトリーダは、このような投票において通常の投票権も持つ。</p>
</li>
<li>
<p>開発者投票において、討論期間を変更する (上記参照)。</p>
</li>
<li>
<p>開発者間の討論をリードする。</p>
<p>プロジェクトリーダが開発者間の議論に参加する際には、
議論の衝突点を明らかにするよう、
その助けとなるような態度を取るべきである。
プロジェクトリーダは、自らの個人的見解を通すために
そのリーダーシップを利用すべきではない。</p>
</li>
<li>
<p>開発者と協議して、Debian
に関連する目的のために保有されている資産に関する決定をする。
(9.1 節を見よ。)
この種の決定事項はプロジェクトリーダ (または代行者)
がメンバーに通知する。主な経費については、
支払いの前にメーリングリストで提案、協議すべきである。</p>
</li>
<li>
<p>信頼された組織 (9.3 節を見よ)
のリストに対する追加や削除。この種の決定にあたっては、
プロジェクトリーダまたは代行者が指定する、
どの開発者でも投稿可能な電子によるメーリングリストにおいて評価、
協議する。信頼された組織のリストへの追加にあたっては、
その決定前に最低二週間以上、協議の期間をおく。</p>
</li>
</ol>
<h3>5.2. 任命</h3>
<ol>
<li>プロジェクトリーダは開発者によって選出される。</li>
<li>選挙は、リーダのポストが空席となる九週間前
(あるいはすでにそれ以下の期間しかなくなっている場合には即時)
に開始される。</li>
<li>続く三週間の間、
開発者はプロジェクトリーダ候補者に立候補できる。</li>
<li>立候補期間の終了後の三週間は、新たな立候補者は受け付けられない。
この期間に候補者は選挙活動を行い、自らの経歴と立場の周知を図ることになる。
もしも立候補受付期間が終了した時点で立候補者がいなかった場合には、
受付期間は三週間単位で (必要に応じて繰り返し) 延長される。</li>
<li>次の三週間は投票期間であり、開発者はこの間に投票ができる。
リーダ選挙の投票は秘密投票であり、投票内容は選挙後も公開されない。</li>
<li>投票の選択肢は、立候補してその撤回をしていない候補者たちそれぞれと、
「全員不可」である。もし「全員不可」が最大得票を集めた場合には、
選挙手続きが (必要なだけ何度でも) 繰り返される。</li>
<li>
決定は「標準議事手順 (Standard Resolution Procedure)」の
A.6 節で指定される方法によって行われる。
必要最低得票数は一般決議 (4.2 節) の場合と同じで、
デフォルトの選択肢は「全員不可」である。
</li>
<li>選出されたプロジェクトリーダは一年の任期を務める。</li>
</ol>
<h3>5.3. 意思決定手順</h3>
<p>プロジェクトリーダは、
開発者の意見の総意に添う決定をするよう努めるべきである。</p>
<p>それが役に立つであろう場合には、
プロジェクトリーダは非公式に開発者の見解を求めるべきである。</p>
<p>リーダとしての裁量に基づいて決定をするにあたっては、
プロジェクトリーダは自らの見解を過度に打ち出すべきではない。</p>
<h2>6. 技術委員会</h2>
<h3>6.1. 権限</h3>
<p><a href="tech-ctte">技術委員会</a>は以下の権限を持つ。</p>
<ol>
<li>
<p>技術的な方針に関するあらゆる事項に関して決定をする。</p>
<p>これには、技術的方針マニュアルの内容、開発者のリファレンス類、
見本パッケージ、実用段階のパッケージ構築ツールの動作などが含まれる
(しかし各事項に対する最初の決定は、
まずそのソフトウェアや文書のメンテナが行う。6.3節(5) を見よ)。</p>
</li>
<li>
<p>複数の開発者の管轄権が絡む技術的問題を判断する。</p>
<p>複数の開発者間で技術的方針や立場を調整する必要があるとき
(たとえば競合するパッケージ間の優先順位、コマンド名の所有権、
あるバグが (バグであることは関係者全員が認めているとして)
どのパッケージの責任なのか、あるパッケージのメンテナが誰か、
などについて開発者間で意見の相違があるとき)、
技術委員会はその件に関する決定を行える。</p>
</li>
<li>
<p>要請された場合、決定をする。</p>
<p>あらゆる個人または組織は、
自らの決定を技術委員会に委任できる。
あるいは技術委員会に助言を求めることができる。</p>
</li>
<li>
<p>開発者の決定を覆す (3:1 の賛成多数が必要)。</p>
<p>技術委員会は開発者に対し、ある種の技術的な一連の作業を
(その開発者が望まない場合でも) するよう要求できる。
これには 3:1 の賛成多数を必要とする。
例えば、技術委員会はバグ報告者の修正要求を正当なものとし、
その報告者の提案する解決案を実施すべきであると決定できる。</p>
</li>
<li>
<p>答申をする。</p>
<p>技術委員会は、どのような件に関しても委員会の正式見解を公表してよい。
<cite>技術委員会の個々のメンバーは、
もちろん自分の見解や技術委員会の見解 (とそのメンバーが考えるもの)
に関する非公式な声明を発してよい。</cite></p>
</li>
<li>
<p>プロジェクトリーダとともに、技術委員会自身の新メンバーを任命し、
また現在のメンバーを解任する (6.2 節を見よ)。</p>
</li>
<li>
<p>技術委員会の議長を任命する。</p>
<p>
議長は技術委員会のメンバーのなかから互選される。
技術委員会の全メンバーが自動的に立候補したとみなされ、
議長が空席となる一週間前から
(あるいはすでにそれ以下の期間しかなくなっている場合には即時に)
委員会内部での投票が行われる。
委員会の各メンバーは、自分自身を含む委員会メンバーに対し、
公開票を投ずることができる。デフォルトの選択肢はない。
投票は全メンバーの投票が終了した時点、
あるいは投票期限が過ぎた時点で終了する。
結果は「標準議事手順 (Standard Resolution Procedure)」の
A.6 節で指定される方法によって決定される。
</p>
</li>
<li>
<p>議長はプロジェクト書記とともにリーダを代行できる。</p>
<p>7.1 節 (2) に述べる通り、技術委員会の議長とプロジェクト書記とは、
リーダ不在の際に共同でリーダを代行できる。</p>
</li>
</ol>
<h3>6.2. 構成</h3>
<ol>
<li>
<p>技術委員会は 8 名以下の開発者から構成される。
また通常は少なくとも 4 名のメンバーを持つべきである。</p>
</li>
<li>
<p>技術委員会のメンバー数が 8 名未満である場合、
技術委員会はプロジェクトリーダに新メンバーを推薦でき、
プロジェクトリーダは (各人ごとに) 任命の採否を決定できる。</p>
</li>
<li>
<p>技術委員会のメンバー数が 5 名以下である場合、
技術委員会は新メンバーを総メンバー数が 6 名に達するまで任命できる。</p>
</li>
<li>
<p>技術委員会のメンバー数が 5 名以下である状態が一週間以上続いた場合、
プロジェクトリーダは新メンバーを総メンバー数が 6 名に達するまで任命できる。
ただし、この場合は一人任命するごとに
一週間以上の間隔を取らなければならない。</p>
</li>
<li>
<p>技術委員会とプロジェクトリーダが合意した場合、
技術委員会のメンバーを解任もしくは交代させることができる。</p>
</li>
</ol>
<h3>6.3. 意思決定手順</h3>
<ol>
<li>
<p>技術委員会は「標準議事手順 (Standard Resolution Procedure)」
を用いる。</p>
<p>技術委員会の各メンバーは、決議文の草案あるいは修正案を提案できる。
最短の討論期間は定めない。投票期間は一週間、
または結果が確定するまで続く。
メンバーは自分の投票を変更できる。必要最低得票数は 2 である。</p>
</li>
<li>
<p>投票に関する詳細</p>
<p>議長は決定票を持つ。技術委員会の投票が、
委員会のメンバーでもある開発者の決定を覆すかどうかに関するものの場合は、
そのメンバーは投票してはならない
(ただしそれが議長の場合には、決定票の投票権だけは持つ)。</p>
</li>
<li>
<p>討論と決定の公開</p>
<p>技術委員会のメンバーによる討論、決議文の草案、修正案、投票は、
技術委員会の公開議論用メーリングリストにおいて公表される。
委員会にはメンバー以外の書記を置くことはしない。</p>
</li>
<li>
<p>任命に関する討議の秘密性</p>
<p>技術委員会メンバーの任命に関する議論においては、
技術委員会は個人宛て電子メールや非公開メーリングリストなどを用いて
非公開の議論をしてよい。
ただし任命に関する投票は公開しなければならない。</p>
</li>
<li>
<p>詳細な策定作業の禁止</p>
<p>技術委員会は新しい提案や方針の立案には関与しない。
そのような立案作業は、各個人がひとりで、
あるいは通常の技術方針立案の場で議論しながら共同で、
行われるべきものである。</p>
<p>技術委員会がする作業は、複数の解決法や決断の中から選択をしたり、
それらの折衷案を採ったりすることに限られる。
それらの案は、他の場所で提案され、
そこで充分な議論を受けたものであるべきである。</p>
<p><cite>技術委員会の個々のメンバーが個人の立場で、
計画や方針の策定作業の各段階に参加することは、
もちろん許される。</cite></p>
</li>
<li>
<p>技術委員会はやむを得ない場合に限って決定をする。</p>
<p>技術委員会が技術的な決定をするのは、
合意による解決の努力の試みが失敗した後、
または本来その決定に責任を持つ個人や組織から要請された場合、
に限られる。</p>
</li>
</ol>
<h2>7. プロジェクト書記</h2>
<h3>7.1. 権限</h3>
<p><a href="secretary">書記</a>は以下の権限を持つ:</p>
<ol>
<li>
<p>憲章に規定されている場合に、開発者からの投票を受け、
その計数と投票有効性の認証をする。</p>
</li>
<li>
<p>技術委員会の議長と共同で、リーダを代行できる。</p>
<p>プロジェクトリーダが不在の際、
技術委員会の議長とプロジェクト書記の両名は、
両者が緊急と考えた場合には、合意に基づいて決定を行える。</p>
</li>
<li>
<p>憲章の解釈に関する論争に対して裁定をする。</p>
</li>
<li>
<p>自己の権限の一部あるいは全体を他人に委任できる。
またその委任をいつでも撤回できる。</p>
</li>
</ol>
<h3>7.2. 任命</h3>
<p>プロジェクト書記は、プロジェクトリーダと
現在のプロジェクト書記とによって指名される。</p>
<p>プロジェクトリーダと現在のプロジェクト書記との間で、
この指名に関して合意ができなかった場合には、両名は一般決議を通して、
開発者に書記の指名を依頼しなければならない。</p>
<p>プロジェクト書記が不在または職務を遂行できない状態であり、
かつ決定権限の委任をしていない場合は、
技術委員会の議長が臨時代理としてプロジェクト書記のすべき決定をしたり、
適当な者に委任したりできる。</p>
<p>プロジェクト書記の任期は一年である。
期間満了後は、自分自身あるいは他の者を
(再) 指名しなければならない。</p>
<h3>7.3. 意思決定手順</h3>
<p>プロジェクト書記は、公正かつ妥当な、
またできれば開発者の総意に矛盾しないような決定をすべきである。</p>
<p>プロジェクトリーダが不在の際に
技術委員会の議長とプロジェクト書記の両名がその代理をする場合には、
決定をするのは絶対に必要不可欠な事柄に限るべきであり、
かつその決定は開発者の総意に矛盾しないようにすべきである。</p>
<h2>8. プロジェクトリーダ代行</h2>
<h3>8.1. 権限</h3>
<p>プロジェクトリーダ代行者は以下の権限を持つ。</p>
<ol>
<li>プロジェクトリーダから委任された権限を持つ。</li>
<li>プロジェクトリーダが直接できない事項について決定をする。
そのような事項には、開発者の承認と除名、
パッケージをメンテナンスしない開発者の解任、などがある。
<cite>これは、プロジェクトリーダに開発者の人選を委ねる事によって、
権限が過度に集中するのを避けるためである</cite>
</ol>
<h3>8.2. 任命</h3>
<p>代行者はプロジェクトリーダによって、
プロジェクトリーダの自由裁量に基づき、
任命されあるいは解任される。
ただしプロジェクトリーダは、
代行者の役職をその代行者の特定の判断によって左右したり、
代行者のした決定を変更したりすることはできない。</p>
<h3>8.3. 意思決定手順</h3>
<p>代行者は、当人が適切と考えるように決定をしてよいが、
それが技術的に良いものであるよう、
また開発者の総意に則るよう、努めるべきである。</p>
<h2>9. Debian に信託されている資産</h2>
<p>世界中のほとんどの法律では Debian
プロジェクトは資産その他の財産を直接保有できる立場にはない。したがって、
9.2 節で述べるように、財産はいくつかの組織が保有しなければならない。
</p>
<p>SPI はもともと Debian の資産や財産の保有を公認された唯一の組織でした。
SPI は実際のところ、財産を保持するためにアメリカで作られた。</p>
<p><a href="http://www.spi-inc.org";>SPI</a>
と Debian は、いくつかの目的を共有する、別々の組織である。
Debian は SPI によって提供される法的支援の枠組みに感謝する。</p>
<h3>9.1. 関連組織との関係</h3>
<ol>
<li>
<p>Debian 開発者は Debian
に信託された資産を保有する組織の代理人や従業員となるわけではない。
その逆、あるいは Debian 開発者であることによる Debian
プロジェクトでの権限についても同様である。
開発者として行動する個人はあくまで個人として、個人の目的で行動する。
この種の組織は、当事者同士の合意を持って Debian
開発者である個人との関係を作ることができる。</p>
</li>
</ol>
<h3>9.2. Authority</h3>
<ol>
<li>
<p>Debian の資産を保有する組織は Debian
の技術的、非技術的な決定に関連する権限は一切持たない。
ただしこの組織が保有する資産に関連する Debian
の決定は、この組織に法的権限を外れて行動することを求めてはならない。
</p>
</li>
<li>
<p>Debian は資産を保有する組織に対して、Debian
に信託された資産を利用する権利(後述) 以外の権利を有しない。</p>
</li>
</ol>
<h3>9.3. 信頼された組織</h3>
<p>Debian プロジェクトへの寄付はプロジェクトリーダ (または代理人) が指定した、
Debian プロジェクトのために使われる資産の処理を公認された
組織のどれかに対して行われなければならない。
</p>
<p>Debian
に信託された資産を保有する組織はこの種の資産について適切な責任を持つべきである。
</p>
<p>Debian は寄付と Debian に信託された資産
(これには有形財産も知的財産も含まれる)
の保有を承認された、信頼された組織の公開リストを管理する。
that includes the commitments those organisations have made as to how those assets will be handled.
</p>
<h2>A. 標準議事手順 (Standard Resolution Procedure)</h2>
<p>この規則は、委員会および構成員が、
上述してきたような局面で、
集団として意思決定をする際に適用される。</p>
<h3>A.1. 提案</h3>
<p>正式な手続きは、
議決文の草案が必要な人数の発起人とともに提案された時点から始まる。</p>
<h3>A.1. 議事と修正動議</h3>
#nakano a.1 がふたつある〜
<ol>
<li>提案に続き、決議文は討議に入る。
修正案は、新規の決議文の必要要件を満たす形で提案かつ賛同されるか、
もともとの決議文の提案者から提案された場合、
正式なものとして扱われる。</li>
<li>決議文の提案者はそのような正式修正案を受け入れることができる。
その場合、正式の決議文は即座に修正案に沿って変更される。</li>
<li>もし正式な修正案が受け入れられなかった場合、
または決議文の賛同者の一名以上が修正案の提案者の受け入れ処置に反対した場合、
修正案は修正案に留まり投票の対象となる。</li>
<li>原提案者に受け入れられた修正案が気に入らなかった人
(賛同者以外) は、その修正を元に戻す新たな修正案を提案できる
(この場合も提案者と賛同者の要件を満たさなければならない)。</li>
#nakano propser of a resolution の typo?
<li>決議文の提案者は、修正案の字句に対して変更を示唆できる。
この示唆は修正案の提案者が受け入れ、
修正案の賛同者から異論が出なければ有効となる。
この場合には、変更された修正案が原案の代わりに投票に付されることになる。</li>
</ol>
<h3>A.2. 投票動議</h3>
<ol>
<li>決議案または修正案の提案者または賛同者は
(最短討論期間がある場合にはその期間が経過したら)、
投票動議を発することができる。</li>
<li>
決議文の提案者または賛同者は、
その決議文および関連する修正案に関する投票を呼びかけることができる。
</li>
<li>投票動議を発する者は、決議案とそれに関連する修正案の文面について
(自らの見解に沿うかたちで) 明らかにし、
またその結果として、
どのような投票形態をとるべきかを明らかにしなければならない。
しかしながら、最終的な投票形態はプロジェクト書記が判断する
(7.1節(1), 7.1節(3), A.3節(4) を見よ)。</li>
<li>
最短討論期間の開始は、
最新の公式修正案が受け入れられた時点、
あるいは修正案がまったく提案・受け入れされていなければ
決議文が提案された時点、となる。
</li>
</ol>
<h3>A.3. 投票手続き</h3>
<ol>
<li>
各決議文と、それに関連する修正案とは、単一の投票用紙をもって
投票にかけられる。用紙には、当初の決議文・各修正案・
(適切な場合には) デフォルトの選択肢、が含まれる。
</li>
<li>
デフォルトの選択肢には超過半数 (supermajority) の要請を科してはならない。
超過半数の要請が明示されていない選択肢には、
1:1 の多数が要請される。
</li>
<li>
投票は A.6 に定める規則にしたがって集計される。
特に指定がなければ、
デフォルトの選択肢は「更に議論する "Further Discussion"」となる。
</li>
<li>不明確な点が現われたら、手続き的な問題はプロジェクト書記が決定する。
</ol>
<h3>A.4. 決議文および不採択修正案の撤回</h3>
<p>決議文や不採択となった修正案の提案者は、その提案を撤回できる。
その場合には、他の者が提案者となってその提案を引継ぐことができる。
引継ぐ場合には、最初に引継ぎを通告した人が新たな提案者となり、
それ以外の人は (まだ賛同者がいない場合は) 賛同者になる。</p>
<p>決議文や修正案の賛同者は、(それらがまだ採択されていない限り)
賛同を撤回できる。</p>
<p>提案者もしくは賛同者の撤回によって、
決議文の提案者がいなくなったり賛同者の人数要件を満たさなくなった場合には、
その決議文が期限切れによって廃案となる前にその状況が修復されない限り、
その決議文の投票は行われない。</p>
<h3>A.5. 期限切れ</h3>
<p>
もし提案された決議が四週間にわたって討論、修正、投票されず、
その他の何らかの処置の状態にもない場合には、
書記はその提案は撤回されたとの宣言を発することができる。
そのいずれかの提案の賛同者が、一週間以内に誰も反対しなければ、
その議題は撤回される。
</p>
<p>
適切な場合には、書記はその後どのようにするかを同時に提案しても良い。
</p>
<h3>A.6. 投票の集計</h3>
<ol>
<li>各投票者の用紙には、投票にかけられる選択肢が順位付けされる。
すべての選択肢に順位をつけなくても良い。順位をつけた選択肢は、
付けられなかった選択肢よりも優先されたとみなされる。
投票者は複数の選択肢を同じ順位にしても良い。
順位付けされなかった選択肢は、それぞれ同じ順位であるとみなされる。
投票用紙にどのように記入すればよいかに関する詳細は、
投票の呼びかけに含まれる。
</li>
<li>投票用紙に必要最低得票数の要請 R が存在する場合、
デフォルト以外の選択肢は、
デフォルトの選択肢よりもそれを上位とする投票を R 票以上集めなければ、
以降の処理から排除される。
</li>
<li>デフォルトの選択肢に、要求された多数比を持って勝つことができなかった
(デフォルト以外の) 選択肢は、以降の処理から排除される。
<ol>
<li>
選択肢 A と B に対し、V(A,B) は A よりも B を優先する
投票者の数とする。
</li>
<li>
ある選択肢 A がデフォルトの選択肢 D に多数比 N で勝つには、
V(A,D) が N * V(D,A) よりも多くなければいけない
(同数は含まない)。
</li>
<li>
超過半数 S:1 が A に要請されている場合、
A の多数比は S となる。それ以外の場合は多数比は 1 となる。
</li>
</ol>
</li>
<li>排除されなかった選択肢のリストから、
1 対 1 勝敗表を作成する。
<ol>
<li>
V(A,B) が V(B,A) よりも多ければ (同数は含まない)、
選択肢 A は選択肢 B に勝利する。
</li>
</ol>
</li>
<li>(排除されなかった) 選択肢同士の勝敗表より、
推移的な勝敗のセットが生成される。
<ol>
<li>
(1) 選択肢 A が選択肢 C に勝利しているか、あるいは
(2) A が別の選択肢 B に勝利
かつ B が C に推移的に勝利している場合、
A は C に推移的に勝利する。
</li>
</ol>
</li>
<li>この推移的勝敗の組から、Schwartz 集合を構成する。
<ol>
<li>
選択肢 A は、すべての選択肢 B に対して推移的に勝利しているか、
あるいは推移的に敗退していなければ、
Schwartz 集合に入る。
</li>
</ol>
</li>
<li>Schwartz 集合の内部にある選択肢同士に勝敗があれば、
その勝敗における最弱のものを先ほどの 1 対 1 勝敗表からを排除し、
ステップ 5 に戻る。
<ol>
<li>
V(A,X) が V(B,Y) より少ない場合、
勝敗 (A,X) は、勝敗 (B,Y) より弱い。
また V(A,X) が V(B,Y) と等しく、
かつ V(X,A) が V(Y,B) より多い場合、
勝敗 (A,X) は、勝敗 (B,Y) より弱い。
</li>
<li>
最弱の勝敗とは、他のどの勝敗よりも弱いものをいう。
そのような勝敗は複数存在することもある。
</li>
</ol>
</li>
<li>Schwartz 集合に勝敗がなくなったら、その集合から勝者を選ぶ。
残った選択肢が 1 つだけだったら、それが勝者となる。
複数の選択肢が残っていたら、決定票を持つ選挙人が、
どの選択肢が勝利するか選択する。
</li>
</ol>
<p>
<strong>注意:</strong>
投票者がデフォルトの選択肢よりも上位に置いた選択肢は、
受け入れられるとみなした選択肢である。
デフォルトの選択肢よりも下位に置かれた選択肢は、
受け入れられないとみなした選択肢である。
</p>
<p><cite>標準議事手順を用いようとする場合には、
その文脈で、決議文草案の提案・賛同に必要なもの、
最短の討論期間、投票期間、を定めなければならない。
また超過半数を必要とするかどうか、
必要最低得票数 (およびデフォルトの選択肢) を用いるかどうか
(用いる場合にはその数)、
についても記述しなければならない。</cite></p>
<h2>B. 語法および表示について</h2>
<p>現在形はその文が本憲章における規則であることを意味している。
「してもよい」または「できる」という語は、
個人もしくは組織が選択できることを示している。
「べきである」という記述は、
その文の内容に従うことが望ましいと考えられるが、
義務ではないことを示している。
<cite>引用としてマーキングされた文 (こんな風に) は注釈を示し、
憲章の一部ではない。
これは疑問が生じた場合の解釈の助けにのみ用いる。</cite></p>
----------------------------------------------------------------