[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Debian JP master SVN www commits (rev.693)
=======================================================
Repository: /org/svn.debian.or.jp/repos
Revision: 693
Commiter: nori
Date: 2008-06-11 18:56:33 +0900 (水, 11 6月 2008)
=======================================================
Log:
Delete proposal.ja.sgml from debian-policy-ja directory.
proposal.sgml was deleted in debian-policy version 3.5.1.0, so it should
be deleted from Debian JP's repository, too. Thanks to those who has
contributed to this translation!!
* src/community/devel/debian-policy-ja/proposal.ja.sgml:
* src/community/devel/debian-policy-ja/proposal.ja.html/*.tt2:
Delete.
=======================================================
Changed:
D www/trunk/src/community/devel/debian-policy-ja/proposal.ja.html/
D www/trunk/src/community/devel/debian-policy-ja/proposal.ja.sgml
Deleted: www/trunk/src/community/devel/debian-policy-ja/proposal.ja.sgml
===================================================================
--- www/trunk/src/community/devel/debian-policy-ja/proposal.ja.sgml 2008-06-11 09:25:37 UTC (rev 692)
+++ www/trunk/src/community/devel/debian-policy-ja/proposal.ja.sgml 2008-06-11 09:56:33 UTC (rev 693)
@@ -1,617 +0,0 @@
-<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
-<debiandoc>
- <book>
- <titlepag>
- <!-- <title>PROPOSAL: A mechanism for updating Debian Policy
-documents</title>-->
- <title>変更動議: Debian ポリシィ文書を変更するやり方</title>
- <!-- 昔の中野さんの訳を参考にしました。昔と言うほど前じゃないけど -->
- <author>
- <name>Manoj Srivastava</name>
- <email>srivasta@debian.org</email>
- </author>
- <version>$Revision: 1.1 $</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.-->
- Free Software Foundation から発行されている GNU General Public
- License 第二版 (もしくはお好みでそれ以降の版) に従った変更と配
- 布が許諾されています。</p>
- <p>
- On Debian GNU/Linux systems, the complete text of the GNU
- General Public License can be found in
- `<var>/usr/share/common-licenses/GPL</var>'. -->
- Debian GNU/Linux システムでは、GNU General Public License の
- 全文が <var>/usr/share/common-licenses/GPL</var> に置かれてい
- ます。</p>
- </copyright>
- </titlepag>
- <chapt>
- <!-- <heading>Introduction, and Administrivia</heading> -->
- <heading>はじめに、および編集前記</heading>
- <p><!--
- 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 Policy 関連文書を維持更新するための手続きの作成の
- 提案です。この文書はプロセスについての説明と、ポリシィの改訂と校
- 正に責任を持つチームを作成しようと言う呼びかけも兼ねています。
- 断っておきますと、このチームはポリシィの作成や編集を行うものでは
- ありません。それは Debian Policy メーリングリストの役回りです。
- </p>
- <p><!--
- 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><!--
- 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><!--
- 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>
- <!-- <em>In the following, the term developer refers to registered
- Debian developers.</em> -->
- <em>以下では「開発者」という言葉は、登録された Debian 開発者の
- ことをさすものとします</em>
- </p>
- <p><!-- A copy of this document should also be found at <url
- id="http://master.debian.org/%7Esrivasta/policy/";>-->
- この文書のコピーは
- <url id="http://master.debian.org/%7Esrivasta/policy/";>
- にも置くようにします。</p>
- <sect>
- <!-- <heading>Deadline for tabling the discussion</heading>-->
- <heading>本提案の討議期間の締め切り</heading>
- <p> <!--
- 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>
- <!-- <heading>People Seconding the Proposal</heading>-->
- <heading>本提案の賛同者</heading>
- <p> <!--
- 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.-->
- Alan Dorman, Phil Hands, Richard Baakman の三人には本提案中の
- ポリシィメンテナチームのボランティアを引き受けていただいたい
- たので、彼らは本提案の賛同者となるに異論はないと思います。
- <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>
- <!-- <heading>Archives and Personnel</heading>-->
- <heading>アーカイヴと担当者</heading>
- <sect>
- <!-- <heading>The policy maintainers team</heading>-->
- <heading>ポリシー管理者チーム</heading>
- <p><!--
- 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 リポ
- ジトリへのアクセスを与えることを提案します。但し、これらの人々は、
- 著者/編集者としてではなく、メンテナとして振る舞うことになります。
- このグループはポリシーを作成しませんし、編集作業も行いません。ポ
- リシーは上流で決定されるもの、すなわちポリシーを決定するグループ
- は、これまで常にそうであったように、Debian-policy メーリングリス
- トに参加している開発者のグループであるべきです。したがってここで
- 選ばれるポリシー管理者は、ポリシーに関する実権は持ちません。この
- 人たちは CVS リポジトリに対するアクセスを持つことになるので、選
- ぶ際には「慣れている人」が望ましいと個人的には思います。
- </p>
- <p><!--
- 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>
- <!-- <heading>The CVS Repository</heading>-->
- <heading>CVS リポジトリ</heading>
- <p><!--
- 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><!--
- 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.-->
- このリポジトリにはチームの管理下にあるパッケージを収めます。ま
- た週刊のステータス文書を保存する領域も設けます。文書が CVS に
- 置かれたら、その文書を web でも公開できるようなスクリプトを書
- くのは、難しいことではないでしょうし、同時に
- <tt>debian-policy</tt> と <tt>debian-devel</tt> に週刊のポスト
- をするようにするのも簡単でしょう。その時には、この文書も CVS
- に収めるといいでしょうね。
- </p>
- <p>
- <!-- 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>
- <!-- <heading>Procedures and Processes</heading>-->
- <heading>手続きと審議過程</heading>
- <sect>
- <!-- <heading>Proposing amendments to the Policy</heading>-->
- <heading>ポリシー改正案の提案</heading>
- <p><!--
- 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>
- <!-- The rationale behind the requirement for seconders is that
- it would-->
- ここで賛同者を要求する理由は以下の通りです。
- <enumlist>
- <item>
- <p><!--
- 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><!--
- 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><!--
- 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><!--
- 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.-->
- 議論が対立し、提案を適用するか却下するかについて投票が必要にな
- った場合には、Debian-policy メーリングリストは投票を行うにふさ
- わしい場所ではありません。Debian 憲章に書いてある方法に従うべ
- きでしょう。なお、総決手順にかけるのは技術的ではない項目に限る
- べきでしょう。技術的な項目は、できればそのグループの内部で解決
- するか、あるいは決裁を行うために技術委員会を招集するのが良いで
- しょう。
- </p>
- <p><!--
- This document is not supposed to supplant the processes
- outlined in the constitution, nor is it an end run around
- them.-->
- この文書は憲章に書いてあるプロセスに取って代わるものではなく、
- そのプロセスをごまかして何かするためのものでもありません。
- </p>
- <sect1>
- <!-- <heading>Notifications and Status Reports</heading>-->
- <heading>通知と状況報告</heading>
- <p><!--
- 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.-->
- 定期的に (たとえば一週間おきくらいに) ポリシーに関する進行中
- の議題のまとめが開発者メーリングリストやポリシーメーリングリ
- ストにポストされるようにするといいでしょう。BTS (Bug Tracking
- System: バグ追跡システム) が方針文書の変更記録追跡に用いられ
- ていますから、現在の修正提案は常に web で閲覧できるはずです。
-</p>
- <p><!--
- 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>
- <!-- <heading>Deadlines for Tabling Discussions</heading>-->
- <heading>議論する期間の締切</heading>
- <p><!--
- 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><!--
- 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>
- <sect1>
- <!-- <heading>Extensions to Deadlines?</heading>-->
- <heading>締切の延長</heading>
- <p><!--
- 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>
- <!-- <heading>Deadlock resolution</heading>-->
- <heading>手詰まり状態の解決</heading>
- <p><!--
- 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.-->
- 以前には合意が取れなければポリシー文書の変更はなされませんでし
- た。これはプロジェクトが小さいうちはうまく機能していましたが、
- 現在は明らかにその段階は過ぎています。既にポリシーメーリングリ
- ストだけでも、このルールでは手に負えなくなっています。今や我々
- は、手詰まり (deadlock) 状態を解決するための正式な手続きを必要
- としています。また技術的ではない項目に関しては、ごくわずかの人
- 数によってポリシー文書の整備が停止されるべきでは必ずしもないこ
- とを認識すべきです。</p>
- <p><!--
- 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>
- <!-- <heading>Impasse on Technical Issues</heading>-->
- <heading>技術的項目での行き詰まり</heading>
- <p><!--
- 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>
- </sect1>
- <sect1>
- <!-- <heading>Non Technical and Subjective Disagreements</heading>-->
- <heading>非技術的問題における主観的対立</heading>
- <p><!--
- 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)-->
- しかし、もし項目が技術的な物ではなく主観的なものなら、開発者
- による投票を行っても良いでしょう (USENET の投票ソフトが使えま
- すよね?)。項目修正を行うためには 75% 以上の賛成多数が必要で
- す。これだけの票数が集まらない場合は、その項目は棚上げにしま
- す。適当な冷却期間の後に、その項目を新たに提案することは可能
- です (冷却期間は 1ヶ月以上置くべきで、通常は 3ヶ月程度が望ま
- しいでしょう。ただし新たな進展があった場合にはこの限りではあ
- りません)。(BTS が利用されていた場合には、バグも降格 (demote)
- させましょう)</p>
- <p><!--
- 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>
- <!-- <heading>Using the Bug Tracking System</heading>-->
- <heading>バグ追跡システムを用いる</heading>
- <p><!--
- 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.-->
- ここで強く主張したいのは、バグ追跡システムを議論中のポリシー変
- 更提案に利用することです。これが実現すれば、ポリシーグループに
- おける議論の開始はwish-list バグを投稿することからはじまります
- (注: これはグループ外の人からも可能であるべきでしょう)。これ
- によって議論中の方針変更提案を管理したり追跡したりすることが
- 簡単になります。バグタイトルの変更や重要度の変更も用いると良
- いかと思います。</p>
- <p>
- <taglist>
- <!-- <tag>Issue raised</tag>-->
- <tag>項目の提案</tag>
- <item>
- <p><!--
- 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><!--
- developers may second the issue by emailing "seconded"
- to the BTS. Only registered Debian developers may
- second proposals. -->
- その項目に賛同する開発者は、 BTS に "seconded" というメ
- ールを送って賛同者となります。登録されている Debian 開発
- 者でなければ、賛同の提案は出せないものとします。
- </p>
- </item>
- <!-- <tag>Amendment</tag>-->
- <tag>修正提案</tag>
- <item>
- <p><!--
- 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><!--
- 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>
- <!-- <tag>Accepted</tag>-->
- <tag>受理</tag>
- <item>
- <p><!--
- if the amendment is accepted, the bug is marked
- forwarded and retitled "[ACCEPTED DD/MM/YYY]...".-->
- 変更提案が受理されたら、バグに forwarded とマークし、タ
- イトルを "[ACCEPTED DD/MM/YYY]..." に変更します。
- </p>
- </item>
- <!-- <tag>Rejected</tag>-->
- <tag>却下</tag>
- <item>
- <p><!--
- if the amendment is closed, it is retitled as
- "[REJECTED DD/MM/YYY] ..." and closed-->
- 変更提案が却下されたら、タイトルを"[REJECTED DD/MM/YYY] ..."
- に変更してクローズします。
- </p>
- </item>
- <!-- <tag>Incorporated</tag>-->
- <tag>ポリシーへの反映</tag>
- <item>
- <p><!--
- When the proposal is actually integrated into Policy
- and uploaded and moved into the archive, the bug is
- closed. -->
- 提案が実際にポリシーに組み込まれ、アップロードされ、アー
- カイブに移動されたら、そのバグはクローズです。
- </p>
- </item>
- </taglist>
- </p>
- <p><!--
- 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>
- </sect>
- </chapt>
- </book>
-</debiandoc>