[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proposal.sgml
中野＠成蹊大です。
さる事情で debian-policy_3.0.1.1.tar.gz に含まれる
proposal.sgml を半分くらい訳す機会がありました。
そちらの用途は終わったものの、死蔵させるのももったいない
ので、こちらに投げておきます。 取り扱いはおまかせします :-)
日本語訳も GPL2 となりますね。
--
中野＠成蹊大
<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
<debiandoc>
<book>
<titlepag>
<!--O
<title>PROPOSAL: A mechanism for updating Debian Policy documents</title>
-->
<titel>提案: Debian ポリシー文書の更新メカニズムについて</title>
<author>
<name>Manoj Srivastava</name>
<email>srivasta@debian.org</email>
</author>
<version>$Revision: 1.8 $</version>
<copyright>
<copyrightsummary>Copyright © 1998 by Manoj Srivastava.
</copyrightsummary>
<p>
You are given permission to redistribute this document
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2, or (at your option) any later version.</p>
<p>
この文書は Free Software Foundation が公開している
GNU General Public License の下で再配布・修正可能です。
バージョン 2、あるいはそれ以降のバージョンが適用できます
</p>
<p>日本語訳は中野武雄 nakano@xxxxxxxxxxxxxxxx が行いました</p>
<p>
<!--O
On Debian GNU/Linux systems, the complete text of the GNU
General Public License can be found in
`<var>/usr/doc/copyright/GPL</var>'. </p>
-->
Debian GNU/Linux システムでは、 GNU General Public License は
`<var>/usr/doc/copyright/GPL</var>' 以下にあります。</p>
</copyright>
</titlepag>
<chapt>
<!--O
<heading>Introduction, and Administrivia</heading>
-->
<heading>序論: この文書について</heading>
<p>
<!--O
This is a proposal for creating a process through which the
Debian Policy documents are to be maintained and updated, it
sets forth the processes, and also calls for the creation of a
team responsible for the task of updating policy, however,
this team does not act as author or editor of Policy itself,
that is the task of the Debian Policy mailing list.
-->
これは Debian ポリシー文書を作成・維持・更新していくプロセスに
関する提案です。この文書では提案プロセスに関して示し、
ポリシーの更新作業に責任を持つチームをつくることを呼びかけています。
しかしこのチームはポリシーの著者・編集者として振る舞うものでは
ありません。それは Debian Policy メーリングリストの役割です。
</p>
<p>
<!--O
It should also be pointed out that this proposal itself does
not call for the modification of the Policy documents
themselves. I would rather not rush into anything as serious
as modification of the formal policy documents themselves, and
I suspect that we would learn and refine this process in
practice. I would rather that the formal modifications be
deferred until after the kinks of this process have been
worked out.
-->
これも断っておきたいのですが、この文書はポリシー文書そのものを
修正しようという呼びかけではありません。正式なポリシー文書
をいきなり修正するような、拙速なことはしたくありません。
このプロセスは実地で学び、より良いものにしていくべきだと思います。
正式な修正は、このプロセスの問題点がすべて解決してからに
すべきだと考えます。
</p>
<p>
<!--O
Another thing that bears mentioning is that this proposal is
only for the every day routine functioning of the policy
group. Traditionally, the policy group, under the aegis of the
Policy editor, worked on the basis of a consensus derived in
the group. This proposal merely removes the need of a
dedicated policy editor, and passes the Debian packages that
contain the policy into the hands of a few people who no
longer exercise editorial control, and, paying homage to our
growth, relaxes the requirement for a consensus.
-->
もう一つ、触れておくべきと思いますが、この提案は
ポリシーグループによる毎日のルーチンだけに関するものです。
これまで、ポリシーグループは、ポリシー編集者の指導のもと、
グループ内部でのコンセンサスに基づいて活動してきました。
この提案は、専任のポリシー編集者がいなくても良いようにして、
ポリシーが含まれている Debianパッケージを何人かの人の手に
ゆだねようとするものです。もう編集者によるコントロールは
受けず、我々の発展だけに留意でき、コンセンサスの必要性を
小さくした状態で。
</p>
<p>
<!--O
This is not supposed to change the way the group works, except
in minor detail. There are some policy changes are light
weight and can be decided upon within the policy group, by
near consensus. In most day-to-day cases, the Policy group
should and must be able to conduct Policy discussions and
amendments without the intervention of the Technical Committee
or other Constitutional issues. Only in cases of extreme
dispute (formal objection) should the intervention of
Constitutional bodies come into play. In any other situation,
the Policy group should be able to conduct business
unfettered. This is the only way we can continue to improve
Debian.
-->
これはグループの作業方法を根本から変えようとするものではありません。
ポリシーの変更には比較的重要度が小さいものがあり、これらは
ポリシーグループの内部で、ほぼ総意に近いかたちでの決定が
できています。日々の作業のほとんどでは、ポリシーグループは
ポリシーに関する議論や修正を技術委員会 (Technical Committee) などの
グループによる調停なしで行うべきですし、そうできるようにしておく
べきです。他のグループの出番は、
特に議論が分かれた問題 (正式な反対が出た問題) に限るべきです。
その他の場合では、ポリシーグループは自由に仕事ができるようにする
必要があります。 Debian を今後も続けてより良くしていくためには、
これが唯一の方法なのです。
</p>
<p>
<!--O
<em>In the following, the term developer refers to registered
Debian developers.</em>
-->
<em>以下では「開発者」という言葉は、登録された
Debian 開発者のことをさすものとします</em>
</p>
<!--O
<p>A copy of this document should also be found at <url
id="http://master.debian.org/%7Esrivasta/policy/";></p>
-->
<p>この文書のコピーは
<url id="http://master.debian.org/%7Esrivasta/policy/";>
にも置くようにします。</p>
<sect>
<!--O
<heading>Deadline for tabling the discussion</heading>
-->
<heading>議論する期間の締め切り</heading>
<p>
<!--O
I decided to use the suggested "usual" period of two weeks
for this proposal. Therefore, this proposal needs to be
acted upon before August the 22nd, 1998.
-->
この提案に関しても、中で述べられている「通常の」期間を
使うことにします。したがってこの提案は August the 22nd, 1998
までに取り扱われる必要があります。
</p>
</sect>
<sect>
<!--O
<heading>People Seconding the Proposal</heading>
-->
<heading>この提案への賛同者</heading>
<p>
<!--O
Well, since Michael Alan Dorman, Phil Hands, and Richard
Braakman have volunteered to serve on the policy maintainer
team, I think they have no objection to being
seconds.
-->
ええと、 Michael Alan Dorman, Phil Hands, Richard Braakman の 3 人は
ポリシー管理チームのボランティアに参加してくれることに
なりましたので、彼らはこの提案の賛同者となることには
否はないと考えます。
<enumlist>
<item>
<p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
</item>
<item>
<p>Richard Braakman <email>dark@xxxxxxxxx</email></p>
</item>
<item>
<p>Philip Hands <email>phil@xxxxxxxxx</email></p>
</item>
</enumlist>
</p>
</sect>
</chapt>
<chapt>
<!--O
<heading>Archives and Personnel</heading>
-->
<heading>アーカイブと担当者</heading>
<sect>
<heading>The policy maintainers team</heading>
<p>
<!--O
I propose we select/install a group of people who have
access to the CVS repository for the Policy documents;
however, this set of people behave more like maintainers
rather than authors/editors. This group does not create
policy, nor does it exercise editorial control, Policy is
decided "upstream". The group that decides on policy should
be the group of developers on the Debian-policy mailing
lists, which is how it was always done; so the group of
policy maintainers have no real power over policy. Since
they would have access to the CVS repository I guess it is
desirable that the people so appointed be ``mature'',
however that is determined.
-->
何人かの人を選んでグループを作り、ポリシー文書を収める
CVS リポジトリへのアクセスを与えることを提案します。
しかしこれらの人々は、著者/編集者としてではなく、管理者として
振る舞うことになります。このグループはポリシーは作成しませんし、
編集者としてのコントロールも行いません。ポリシーは "upstream"
で決定されるのです。ポリシーを決定するグループは、これまで常に
そうであったように、 Debian-policy メーリングリストに参加している
開発者グループであるべきです。したがってポリシー管理者は、
実際にはポリシーに関する権限を持たないことになります。
でもこの人たちは CVS リポジトリに対するアクセスを持つことになるので、
選ぶ際には「慣れている人」望ましいと個人的には思います。
</p>
<p>
<!--O
I think that since the policy maintainers have no special
powers, there is no need to restrict their participation in
the discussion. We do need to have at least 4-5 people on
the job, preferably closer to 8, so that policy does not
languish when any maintainer goes missing (we do need
vacations, you know, once in a while), and since little
creative power is vested in the maintainers, we do not need
a central control. And the archives of the list can be used
as a record of the action decided upon even if all
maintainers are away at some time.
-->
ポリシー管理者は特別な権限を何も持たないので、議論に参加
しなければならない、といった制限をする必要はありません。
少なくともこの作業には 4-5 人が必要で、可能なら 8 人程度が
確保できれば、誰かがいなくなったときでも作業が遅れずに
すむでしょう (ご存じのとおり我々にはときどき休暇が必要ですから)。
創造的な権限は管理者にはほとんど与えられませんから、
中央からの管理は必要ないでしょう。いつか管理者が全員いなく
なったりしても、メーリングリストのアーカイブで、作業や
決定の記録を取っておくことができるでしょう。
</p>
</sect>
<sect>
<!--O
<heading>The CVS Repository</heading>
-->
<heading>CVS リポジトリ</heading>
<p>
<!--O
There should be a repository set up on
<tt>cvs.debian.org</tt> for this, with the people on the
policy maintainer team having write access to it.
-->
<tt>cvs.debian.org</tt> に、この目的のためのリポジトリを
設け、ポリシー管理者チームの人たちがアクセスできるように
します。
</p>
<p>
<!--O
The repository should contain all the packages under the
control of the team, and also should have an area where the
weekly status document is kept; once the document is under
CVS, it should be a simple matter to script exporting the
document out to a place where the web server can serve it,
as well as create the weekly posting to
<tt>debian-policy</tt> and <tt>debian-devel</tt> mailing
lists. This document could also be kept under CVS then.</p>
-->
このリポジトリにはチームの管理下にあるパッケージを収めます。
また週刊のステータス文書を保存する領域も設けます。
文書が CVS に置かれたら、その文書を web でも公開できるような
スクリプトを書くのは、難しいことではないでしょう。
同様に <tt>debian-policy</tt> と <tt>debian-devel</tt> に
週刊のポストをするのも簡単でしょう。その時には、
この文書も CVS に収めるといいでしょうね。</p>
<p>
<!--O
If possible, a separate mailing list (<tt>debian-policy-admin</tt>)
maybe created which gets copies of all the CVS commit
notices.
-->
可能なら、別のメーリングリスト (<tt>debian-policy-admin</tt>)
を作って、 CVS commit のお知らせを全部流すようにするといいかも
しれません。
</p>
</sect>
</chapt>
<chapt>
<!--O
<heading>Procedures and Processes</heading>
-->
<heading>手続きと過程</heading>
<sect>
<!--O
<heading>Proposing amendments to the Policy</heading>
-->
<heading>Policy の改正案を提案する</heading>
<p>
<!--O
Unlike before, when the policy editor gathered in issues
which, in his view, were candidates for inclusion in policy,
I propose that issues are brought up in the policy group,
and, if the initial discussion warrants it, any developer,
with at least two(?) seconds can formally propose as a
policy amendment.
-->
以前には、ポリシー文書に入れるべき項目 (issue) は、
ポリシー編集者が (彼の判断の下に) 収集していました。
しかしここで私は、以下のような提案をしたいと思います。
方針文書の項目はポリシーグループから上げていくべきだと考えます。
もし初期段階の議論が正当なものであれば、
開発者は誰でもポリシーの改正を提案できることと
したいのです。ただし提案には、最低二名 (?) の賛同者が
必要なこととします。
</p>
<p>
<!--O
The rationale behind the requirement for seconders is that
it would<enumlist>
-->
賛同者を必要とする理由は以下の通りです。
<enumlist>
<item>
<p>
<!--O
Encourage people to test the waters on the policy
mailing list, and this could help create an proposal
with a better chance of success</p>
-->
ポリシーメーリングリストで提案に対する公聴が行われるようになり、
提案が通る可能性が大きくなります。
</item>
<item>
<p>
<!--O
Prevent frivolous or ill conceived proposals from
wasting peoples time (If the proposal does not even
convince two developers, surely this is not ready for
inclusion in Policy?)</p>
-->
浮ついた提案やよく考えられていない提案によって、
人々の時間が無駄にされずに済みます。
(開発者二人を納得させられない提案は、ポリシー文書に
入れる準備ができていない、と言われてもしょうがないでしょう？)
</item>
</enumlist>
</p>
<p>
<!--O
The whole discussion process is meant to be light weight; If
you wish the proposals to be amended, talk to the proposer,
and get the amendment in. Or else, post an alternative, and
let the group decide which one is better.
-->
議論のプロセス全体はあまり重くならないようにしたいです。
提案が修正されるべきだと思うなら、
提案者に伝えて修正を施してもらいましょう。
あるいは代案をポストして、
グループにどちらがベターかを判断してもらいましょう。
</p>
<p>
<!--O
If the process gets very contentious, and needs something
like votes on amendments and withdrawal of proposal, then
this is not the correct forum for this, and the procedures
outlined in the constitution should be followed. Note that
only non-technical issues can be resolved using the general
resolution protocol; technical issues would hopefully be
resolved in the group itself, or the technical committee can
be called upon to render a decision.
-->
議論が対立し、提案を適用するか却下するかについて投票が必要になった場合、
ここは投票を行うにふさわしい場所ではありません。
定款 (constitution) に書いてある方法に従うべきでしょう。
なお、総決 (General Resolution) のプロトコルに
かけるのは技術的ではない項目に限るべきでしょう。
技術的な項目は、できればそのグループの内部で解決するか、
あるいは決裁を行うために Technical Committee を招集するのが良いでしょう。
</p>
<p>
<!--O
This document is not supposed to supplant the processes
outlined in the constitution, nor is it an end run around
them.
-->
この文書は定款に書いてあるプロセスに取って代わるものではなく、
そのプロセスをごまかして何かするためのものでもありません。
</p>
<sect1>
<!--O
<heading>Notifications and Status Reports</heading>
-->
<heading>通知と状況報告</heading>
<p>
<!--O
Periodically, possibly weekly, a summary of current policy
topics can be posted to the Developers mailing list, as
well as to the policy mailing list. Since the BTS is used
for keeping track of policy amendments, the list of
current amendments shall always be on the web.</p>
-->
定期的に (たとえば一週間おきくらいに) ポリシーに関する進行中の議題の
まとめが開発者メーリングリストやポリシーメーリングリストに
ポストされるといいでしょう。
BTS (Bug Tracking System: バグ追跡システム) が方針文書の変更記録追跡に
用いられていますから、現在の修正提案は常に web で
閲覧できるはずです。
<p>
<!--O
Amendments to policy that have been accepted by the policy
group shall also be part of the notification. (recently
resolved bugs)
-->
ポリシーグループによって受け入れられた修正案も、
その通知に含まれていると良いでしょう
(「最近解決されたバグ」として)。
</p>
</sect1>
</sect>
<sect>
<!--O
<heading>Deadlines for Tabling Discussions</heading>
-->
<heading>議論する期間の締切</heading>
<p>
<!--O
It has been observed in the past that discussions on the
mailing list devolve into endless arguments. In order to get
away from the debating society aspect, at the time of the
formal proposal, a deadline can be set (probably by the
proposer, since they are likely to have an idea how
contentious the discussion is likely to be) for ending
discussion on the issue, which should rarely be less than 10
days, and typically two weeks or so. I hope that a hard
minimum period need not be set, and that the proposers would
be reasonable, and not set too short or too long a time for
discussion.
-->
メーリングリストでの議論がエンドレスな論争に陥るようなことも
これまでは多く見られました。「議論のための議論」を避けるために、
その項目に関する議論の締切を設けることができることとします
(おそらく締切の設定は提案者によってなされるべきでしょう。
どのくらい対立した意見が出るかの予測ができるのは提案者でしょうから)。
期間は 10 日以上にするべきで、二週間くらいが妥当でしょう。
最低の期間に関する厳密な規則は設けたくありません。
提案者は理性的になり、短すぎず長すぎない議論期間を設定してほしいと
思います。
</p>
<p>
<!--O
If a consensus is reached by the policy group, then the
maintainers shall enter the amendment into the Policy
document, announce the inclusion in the periodic report, and
release a new version.</p>
-->
ポリシーグループで合意に達することができたら、
管理者は修正を方針文書に施し、その旨を定期報告に加え、
新しい版をリリースします。</p>
<sect1>
<!--O
<heading>Extensions to Deadlines?</heading>
-->
<heading>締切を延長するか？</heading>
<p>
<!--O
If a deadline is approaching, and the discussion s almost
concluded (in other words, it has not reached an impasse),
and the consensus on the policy group is that an extension
of a week would resolve the issues better, a one-time
extension could be granted. Care should be taken in
exercising this option, since abusing this would merely
postpone closures. Anything that is still not resolved is
too contentious not to be sent to the full set of
developers in a general resolution proposal.
-->
締切が近づいて、議論もそろそろ終わりそうな場合
(つまり、手詰まりにはなっていない場合)、
グループ内で「一週間くらい延長すれば改訂案をより良くできる」
という合意が得られれば、一回に限り延長が可能です。
このオプションの利用には慎重になってください。
濫用すると単に議論を長引かせるだけです。
議論を延長しても解決されなかった提案は、
対立要素が強すぎるのでしょうから、
開発者全員からなる総決に送るべきでしょう
</p>
</sect1>
</sect>
<sect>
<!--O
<heading>Deadlock resolution</heading>
-->
<heading>手詰まり状態の解決</heading>
<p>
<!--O
Formerly, arriving at a consensus was the only way to amend
Policy. That worked well when the Project was small,
however, we have apparently grown out of that phase, and even
the policy mailing list has grown more fractious than in the
days of yore. We now need a formal process of deadlock
resolution, and we need to recognize that on non-technical
issues a small minority should not always hold up deployment
of policy.</p>
-->
以前には合意が取れなければポリシー文書の変更はなされませんでした。
これはプロジェクトが小さいうちはうまく機能していましたが、
現在は明らかにその段階は過ぎています。
既にポリシーメーリングリストだけでも、
このルールでは手に負えなくなっています。
今や我々は、手詰まり (deadlock) 状態を解決するための
正式な手続きを必要としています。
また技術的ではない項目に関しては、ごくわずかの人数によって
ポリシー文書の整備が停止されるべきでは
必ずしもないことを認識すべきです。</p>
<p>
<!--O
If a consensus is not reached, (or if someone submits a
formal objection to the proposal) and the end of the
discussion period is near, then one is faced with a dilemma.
-->
議論の期限に近づいても合意に達することができなければ
(あるいは誰かが提案に対する正式な反対意見を提出したら)、
ジレンマに直面することになります。
</p>
<sect1>
<!--O
<heading>Impasse on Technical Issues</heading>
-->
<heading>技術的項目での行き詰まり</heading>
<p>
<!--O
On technical issues, popularity is a bad way of arriving
at conclusions. Hopefully, the policy group would arrive
at a consensus on their own. If that fails to happen, or
if there is a formal objection raised on the issue, and
the issue is a technical one, then the technical committee
may be consulted. This should be a rare occurrence. </p>
-->
技術的な項目においては、多数決は結論を出すのに良い方法ではありません。
できればポリシーグループの内部で合意に達することが望ましいですが、
これが不可能だった場合や正式な反対意見が出た場合には、
技術的な項目変更提案については technical committee に諮るべきでしょう。
しかしこのようなことはあまり起こらないでしょう。
</sect1>
<sect1>
<!--O
<heading>Non Technical and Subjective Disagreements</heading>
-->
<heading>非技術的問題における主観的対立</heading>
<p>
<!--O
However, if the issue is non-technical and subjective,
then a vote of the developers may be taken (USENET voting
software should be available all over the place, right?);
and a super-majority of 75% is needed to carry the
amendment through. Failing the super-majority, the issue
should be shelved. It may be re-submitted as a a fresh
proposal after a suitable cooling off period (which should
be no less than a month, typically three months being
desirable, unless there are significant new
developments). (Demote bug, if the BTS is being used)</p>
-->
しかし、もし項目が技術的な物ではなく主観的なものなら、
開発者による投票を行っても良いでしょう
(USENET の投票ソフトが使えますよね?)。
項目修正を行うためには 75% 以上の賛成多数が必要です。
これだけの票数が集まらない場合は、その項目は棚上げにします。
適当な冷却期間の後に、その項目を新たに提案することは可能です
(冷却期間は 1ヶ月以上置くべきで、通常は
3ヶ月程度が望ましいでしょう。ただし新たな進展が
あった場合にはこの限りではありません)。
(BTS が利用されていた場合には、バグも降格 (demote) させましょう)</p>
<p>
<!--O
If the issue raised is especially contentious, or is
deemed to be suitable for review by the full set of
developers, then four or more developers can call for a
hold on the proposal, and move to send the proposal to the
larger developer body as a General
Resolution. <strong>Note:</strong> The constitution may
have additional requirements for submitting a General
Resolution, for example, a minimum number of seconders,
etc.
-->
その項目が強い対立を産み出した場合や、
全ての開発者によってレビューされるべきであると合意された場合は、
4 名以上の開発者が集まれば提案の待機 (hold) を要求することができ、
その提案を開発者全体に移して総決にかけることもできます。
<strong>付記:</strong> 定款には総決に持ち込むための条件を
加えるべきではないかと思います。例えば支持者の最低人数などです。
</p>
</sect1>
</sect>
<sect>
<!--O
<heading>Using the Bug Tracking System</heading>
-->
<heading>バグ追跡システムを用いる</heading>
<p>
<!--O
A fascinating sub proposal has been that we use the bug
tracking system to track policy amendments in progress. If
this is used, we may initiate discussions in the policy
group by filing wish-list bugs (note: this should be open to
anyone at all) This simplifies how me manage and track open
amendments and issues. I think both re-titling and the
severity of the bugs can and should be used.</p>
-->
ここで強く主張したいのは、バグ追跡システムを
議論中のポリシー変更提案に利用することです。
これが実現すれば、ポリシーグループにおける議論の開始は
wish-list バグを投稿することからはじまります (注: これは
グループ外の人からも可能であるべきでしょう)。
これによって議論中の方針変更提案を管理したり追跡したりすることが
簡単になります。
バグタイトルの変更や重要度の変更も用いると良いかと思います。</p>
<p>
<taglist>
<!--O
<tag>Issue raised</tag>
-->
<tag>項目の提案</tag>
<item>
<p>
<!--O
wishlist bug opened in BTS, with a subject of
"[PROPOSED] ...". This is the pre discussion period,
when the idea is kicked around, and polished. There is
no preset time limit, but at some point, if it is
stalled, the bug should be closed. Only registered
Debian developers may formally create proposals.
-->
wishlist バグを "[PROPOSED] ..." という subject をつけて BTS で
開きます。これは議論の準備段階で、この間に
アイディアを練ったり洗練させたりします。タイムリミットを
設ける必要は特にありませんが、動きが見られなくなったら、
ある時期にバグは閉じるべきでしょう。正式に提案を行うことが
できるのは、登録された Debian 開発者だけです。
</p>
<p>
<!--O
developers may second the issue by emailing "seconded"
to the BTS. Only registered Debian developers may
second proposals.
-->
その項目に賛同する開発者は、 BTS に "seconded"
というメールを送って賛同者となります。
登録されている Debian 開発者でなければ、賛同の提案は
出せないものとします。
</p>
</item>
<!--O
<tag>Amendment</tag>
-->
<tag>変更提案</tag>
<item>
<p>
<!--O
when a proposed issue becomes a formal amendment (when
it has acquired the required number of seconds), the
bug severity is raised to "normal" and the bug is
retitled to "[AMENDMENT DD/MM/YYY] ...". Actually it
might be better to close the proposal and reopen so
the bug date reflects when the clock starts ticking on
the bug.
-->
提案された項目が正式なものになったら (必要な人数の賛同者を得たら)、
バグの重要度 (severity) を "normal" に上げ、
そしてバグのタイトルを "[AMENDMENT DD/MM/YYY] ...";
に変更します。
実際には提案を一度クローズして、
もう一度オープンするのがいいかもしれません。
そうすればバグの日付に議論開始の情報が自動的に入るからです。
</p>
<p>
<!--O
This sets up the table for a discussion period,
normally 10 days to a month. At the end of the
discussion period, a proposal is either accepted, or
rejected.
-->
ここで議論の期間に関する予定を設定します。通常は 10 日から
1ヶ月程度が良いでしょう。議論期間の終わりには、
提案は受理された (accepted) か却下された (rejected) かのいずれかになります。
</item>
<!--O
<tag>Accepted</tag>
-->
<tag>受理</tag>
<item>
<p>
<!--O
if the amendment is accepted, the bug is marked
forwarded and retitled "[ACCEPTED DD/MM/YYY]...".
-->
変更提案が受理されたら、バグに forwarded とマークし、
タイトルを "[ACCEPTED DD/MM/YYY]..." に変更します。
</p>
</item>
<!--O
<tag>Rejected</tag>
-->
<tag>却下</tag>
<item>
<p>
<!--O
if the amendment is closed, it is retitled as
"[REJECTED DD/MM/YYY] ..." and closed
-->
<!--NAKANO 原文 if rejected の間違いっぽい -->
変更提案が却下されたら、タイトルを
"[REJECTED DD/MM/YYY] ..." に変更してクローズします。
</p>
</item>
<!--O
<tag>Incorporated</tag>
-->
<tag>反映</tag>
<item>
<p>
<!--O
When the proposal is actually integrated into Policy
and uploaded and moved into the archive, the bug is
closed.
-->
提案が実際にポリシーに組み込まれ、アップロードされ、
アーカイブに移動されたら、そのバグをクローズします。
</p>
</item>
</taglist>
</p>
<p>
<!--O
I think that the Policy is critical enough for the project
that any real flaws in the policy be automatically be deemed
important bugs, unless they affect release management.</p>
-->
方針文書はプロジェクトにとって非常に重要なものですから、
方針文書にある実際の瑕疵は自動的に「重要なバグ」と認識されるべきだと
筆者は考えます。ただしそれらがリリース管理に影響しない場合は別ですが。</p>
</sect>
</chapt>
</book>
</debiandoc>