blob: 8087f24bf27ce0bb52c03046f9333ab5515a619d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
#use wml::debian::translation-check translation="beb188a1e37dd39a8004ebd9faddc4b43118a184"
<define-tag pagetitle>一般決議の提案や修正案を提出するための手順</define-tag>
#use wml::debian::template title="<pagetitle>" BARETITLE="true" NOHEADER="true" NOHOMELINK="true"
#use wml::debian::votebar
<h1><pagetitle></h1>
<p>憲章の以下の部分において</p>
<div style="border: solid; padding: 1ex">
<blockquote>
<ul>
<li>
4. 開発者の集団 (一般決議および選挙による)
<ul>
<li>
2. 意思決定手順
<ul>
<li>
5. 提案、賛同、修正、投票の要請などの正式な手続きは、
プロジェクトリーダ代行者が管理する、
一般から閲覧可能なメーリングリスト上で行われる。
全ての開発者はそのメーリングリストに投稿できる。
</li>
<li>
6. 投票はプロジェクト書記が適切とする方法で、
電子メールにて行われる。プロジェクト書記は、
各投票において、
投票者による投票内容の変更を認めるかどうかを決める。
</li>
</ul>
</li>
</ul>
</li>
</ul>
<ul>
<li>
A. 標準議事手順 (Standard Resolution Procedure)
<ul>
<li>
3. 投票手続き
<ul>
<li>
4. 不明確な点が現われたら、
手続き的な問題はプロジェクト書記が決定する。
</li>
</ul>
</li>
</ul>
</li>
</ul>
</blockquote>
</div>
<p>
以下の手順は一般決議の提案と同意について述べるものです。
</p>
<ol style="list-style-type: decimal">
<li>
指定された電子メーリングリストは
<tt>debian-vote@lists.debian.org</tt> です。これが
サポートやその他の内容と同様にすべての決議においても
権威あるソースとなります。他のメーリングリストに送られた場合は、
提案や同意者の募集として認められないこととします。
</li>
<li>
すべての提案及び同意者になるというメールは、
Debian キーリングにある暗号鍵により署名されていなければなりません。
キーリングは誰が Debian 開発者であるか、またはないかを示す、
権威のある返答の一部となります。
</li>
<li>
すべての提案は明確に提案であることを示さなければならず、
そのメールの前後の文で明示しなければなりません。
すべての同意者も、範囲を限定して同意する場合は、
同意者になるという文を示さなければなりません。
</li>
<li>
投票を要求する際、提案者または提案や修正案のすべての同意者は、
提案または修正案の最終版を、Debian
プロジェクトのウェブページに掲載できるよう、wml
形式で提出しなければなりません。この wml
には範囲や同意を示す文が正確に含まれることを確認しなければなりません。
</li>
<li>
投票を要求する際、提案者または提案や修正案のすべての同意者は、
一行 (60 文字) で提案または修正案の概要を提出しなければなりません。
この概要は書記が投票用紙を作成する時に取り入れられることになるでしょう。
</li>
</ol>
<p>
項目 4 及び 5 に該当するものがない場合は、
書記のバージョンが最終版だと判断します。
これらのアイテムが欠けていることによって投票を遅らせることのないよう、
提案者と同意者には最低議論期間の終わりまでに問題点を
洗い出しておくことを強く提案します。
</p>
<h1>推奨する方法と様式</h1>
<p>
基準とは対照的に、以下は参考になるでしょう。以下に挙げる点により、
提案の理解、追跡、投票しやすくなります。出発点として<a
href="sample_vote.template">テンプレート</a>のサンプルを提供しています。
</p>
<p>
提案の簡潔な説明をメールのサブジェクト行に含めることはよい方法です。
subject 行は <q><em>Subject: Proposal - 説明文</em></q>
というような形式を推奨します。これにより、
提案に関連するメールを選別しやすくなります。
</p>
<p>
提案が独立した提案なのか、
既存の提案への正式な修正であるのかを示してください。
独立した提案を既存の提案と同じ問題に対して提起することもできます
— その時期以外の違いはほとんどありません。
修正は完全な議論期間を取られないかもしれません
— 修正案を練っている間に投票期間になってしまうかもしれません。
独立した提案の場合は、言い換えれば、
既存の提案と同じ投票用紙になるとも限りません。
時期によっては、独立した二件の投票、既存の提案に対するものと、
新しい、独立した提案に対するものになるかもしれません。
最終的に決めるのは自分自身です。
</p>
<p>
提案が既存の文書のテキストを変更するものである場合、
実際のパッチファイル (<code>diff -u</code> で生成されるもの)
を提出するのはよい方法です。そうすることで提案している変更が正確に示され、
提案が通った際、その文書の担当者にとって助けにもなります。
</p>
<p>
提案者及び同意者への提案として、提案や修正案の全文を個別の
(できればインラインで) 署名済み text/plain MIME
パートとして添付することがあります。
これにより曖昧さが完全になくなります。
</p>
<h2><a name="amend">修正</a></h2>
<div style="border: solid; padding: 1ex">
<blockquote>
<ul>
<li>
A. 標準議事手順 (Standard Resolution Procedure)
<ul>
<li>
1. 議事と修正動議
<ul>
<li>
5. 決議文の提案者は、修正案の字句に対して変更を示唆できる。
この示唆は修正案の提案者が受け入れ、
修正案の賛同者から異論が出なければ有効となる。
この場合には、変更された修正案が原案の代わりに
投票に付されることになる。
</li>
<li>
6. 決議の提案者は些細なエラー (例えば誤字や矛盾点)
あるいは解釈を変えない変更であれば、24
時間以内に反対意見が出ないことを条件に、
修正することができる。
この場合、最低議論期間の再始動はしない。
</li>
</ul>
</li>
</ul>
</li>
</ul>
</blockquote>
</div>
|
