[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal.sgml
かねこ＠ひたちです。まず残り。
At 6:09 PM +0900 99.10.27, NAKANO Takeo wrote:
> <!--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 で
> 閲覧できるはずです。
ここポリシーではなく方針になっています。
> <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% 以上の賛成多数が必要です。
「修正案を可決するには」。75% の根拠は憲章です。
> <!--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>
「影響する場合は」じゃないでしょうか？
--
Seiji Kaneko skaneko@xxxxxxxxxxxx
--------------------------- http://plaza25.mbn.or.jp/~efialtes