[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