===================================
Django プロジェクトに協力するために
===================================

:revision-up-to: 5583 (0.97pre SVN)

Django を *使う* のを楽しいと思ってもらえたなら， *使い続ける* 前にすこし待っ
てください．私達は多大な情熱をかけて，ユーザがコミュニティのメンバに貢献で
きるよう手助けしています．Django の開発を手伝うにはいくつもの方法があります:


    * Django について blog を書きましょう．私達は知っている限りの全ての
      Django 関係の blog を `コミュニティのページ`_ で配信しています．この
      ページに登録したい blog があるなら jacob@jacobian.org に連絡してくだ
      さい．

    * バグ報告や機能に関する要望を `チケットトラッカ`_ に提出しましょう．
      私達が望んでいるバグ報告の提出方法の詳細は `バグの報告`_ を読んで下さい．

    * 新たな機能を追加したり従来の機能を修正するパッチを提出しましょう．
      パッチの提出方法は `パッチの提出`_ を参照してください．

    * `django-developers`_ メーリングリストに参加して， Django をよりよくす
      るためのアイデアを皆で共有しましょう．どんな提案でも歓迎します．ただ
      し私達は後ろだてになるコードがないスケールの大きな話には懐疑的です．

    * 他のユーザが提出したパッチのトリアージ (選別) を行います．トリアージ
      の手順については，後述の  `チケットのトリアージ <#ticket-triage>`_ を
      参照してください．

Django 開発コミュニティに参加するのに必要な知識はこれだけです．このドキュメ
ントの残りの部分では，開発コミュニティがどのようになっていて，どうやってバ
グを処理しているかについて詳しく説明し，メーリングリストやその他こまごまと
した注意点について記述しています．

.. _Reporting bugs:

バグの報告
==============

上手に書かれたバグ報告は *信じられないくらい* 助けになります．とはいえ，バ
グ追跡システムでの作業はかなりのオーバヘッドを要するので，チケットトラッカ
をできるだけ有意義に使うよう協力していただけると助かります．特に:

    * **必ず** FAQ_ を読んで，自分の抱えている問題が既知のものでないか探し
      て下さい． 

    * **必ず** `トラッカを検索`_ して，自分の抱えている問題がファイルされて
      いないか探して下さい． 

    * **必ず** *最初に* `django-users`_ で質問して，自分の考えていることが
      バグだということを確認してください． 

    * **必ず** 完結した，再現可能な，的確なバグ報告を書いて下さい．完全なコー
      ド断片やテストセットなど，可能な限り多くの情報を含めて下さい．問題に
      対する詳細かつ明瞭な説明と，問題を再現するための手順を含めてください．
      小さなテストケースでバグを再現できれば最良のバグ報告になります．

    * **決して** サポート質問にチケットシステムを **使わないで下さい．** 質
      問は `django-users`_ リストや `#django`_ IRC チャネルでお願いします．

    * **決して** スケールの大きな機能の提案にチケットシステムを 
      **使わないで下さい．** Django のコアに関わる大きな変更は，
      取り掛かる前に必ず `django-developers`_ リストで議論します．

    * **決して** "wontfix" にマークされた問題を
      **開き直さないで下さい．** "wontfix" マークは決定事項であり，この問題
      についてはこれ以上修正できないか，修正する予定はないのです．納得でき
      なければ， `django-developers`_ で質問してください．

    * **決して** 長い議論をチケットシステムで **行わないで下さい．** チケッ
      トシステムでは議論内容がじきに失われてしまうからです．チケットの内容
      について議論になりそうなときは `django-developers`_ に場所を移して下
      さい．

.. _Reporting security issues:

セキュリティ問題の報告
=========================

セキュリティ問題の報告は security@djangoproject.com にお願いします．このメー
リングリスト経験豊かで信頼できる Django 開発者だけが購読でき，アーカイブは
非公開になっています．

Django に脆弱性が発見された場合，私達は以下のように行動します:

    * 報告者に対して，報告を受けとったことと，脆弱性がまもなく修正されるこ
      とを知らせます．修正までのおおまかなタイムラインを示し，報告者に対し
      て，アナウンスを行うまでにどのくらいの間この問題を秘密にしておけるか
      問い合わせます．

    * 現在のバージョンと，二つ前までのリリースに対するパッチを含む修正版の
      開発に必要な期間，他の全ての開発を停止します．

    * 脆弱性と修正版をアナウンスするする日取りを決めます． パッチを適用する
      側と脆弱性を不正利用する側の間の「軍拡競争」を抑えるため，私達はセキュ
      リティ問題を即座にアナウンスしません．

    * 影響を受けるバージョンの Django を使っているユーザのうち，私達が把握
      している人全員に事前に通知します．この通知は個人宛の電子メールで行わ
      れます．メールには脆弱性に関するドキュメントと該当パッチへのリンク，
      そしてこの脆弱性を公式の公開日まで秘密にしておくよう要請する文が入っ
      ています．

    * あらかじめ決めておいた日取りに基づいて，脆弱性と修正版を公開し，アナ
      ウンスします．通常は新たなバージョンの Django リリースを意味しますが，
      場合によっては現在のリリースに対する単なるパッチになります．

.. _Submitting patches:

パッチの提出
==================

Django のコードに対するパッチはつねに大歓迎です．実際，パッチつきのバグ報告
は，パッチのないものよりも *はるかに* 素早く修正されます．

.. _Patch style:

パッチ形式
-----------

    * Django の `コーディングスタイル`_ に従っているか確認してください．

    * ``svn diff`` コマンドの返す書式のパッチを提出してください．ただし，コー
      ドよりも英語で変更点を説明した方がはるかに分かりやすい場合は例外です．
      例えばインデントはよくある例です．というのも，コードの違いがインデン
      トでしかない場合，パッチを読むのはとても大変だからです．

    * `チケットトラッカ`_ で， "attach file" ボタンを使ってチケットにパッチ
      を添付してください．一行のパッチでないかぎり，チケットの説明やコメン
      トの中にパッチを *入れないで* 下さい．

    * パッチファイルの名前には ``.diff`` 拡張子をつけて下さい．そうすること
      で，チケットトラッカは構文のハイライト強調を正しく行うので助かります．

    * チケットの詳細情報欄にある「パッチ付き」("Has patch") ボックスにチェッ
      クを入れてください．チケットがパッチつきであることが分かりやすくなり，
      チケットシステムがそのチケットを `パッチつきのチケットのリスト`_ に追
      加してくれます．

    * 問題を解決したり機能を追加するためのコードはパッチの重要な部分ですが，
      それだけではいけません．よいパッチというものには必ず回帰テストが付属
      していて，問題が解決されたことを検証できる (そして将来同様の問題が再
      発しないようにできる) ものです． 
      
    * パッチ中のコードが新たな機能や既存の機能に対する変更をもたらす場合，
      パッチにはドキュメントも含めてください．

.. _Non-trivial patches:

重要パッチ
----------

「重要 (non-trivial)」パッチとは，単なるバグフィクスに留まらず，Django に
新たな機能をもたらし，何らかの設計上の判断を迫るようなパッチです．

重要パッチを提出する場合には，その問題について `django-developers`_ で議論
済みであるという証明を含めてください．自分のパッチが重要パッチかどうか判断
しかねる場合には問い合わせてください．

.. _Ticket triage:

チケットのトリアージ
====================

残念ながら， `チケットトラッカ`_ に届くバグ報告全てが，上に述べた
`チケットの要件 <#reporting-bugs>`_ を満たしているわけではありません．
パッチの添付されたチケットもたくさんありますが，それら全てが 
`よいパッチ <#patch-style>`_ の要件を満たしているわけでもありません．

こうした状況の打開を手助けする一つの方法に，他のユーザが報告したバグのトリ
アージ (選別) 作業があります．この作業には献身的なボランティア 2 名が常時携
わっていますが，手助けをしてくれる人は常に歓迎です．

トリアージ作業のワークフローの大半は，チケットの「トリアージ段階 (triage
stage)」というフィールドに関わる作業です．このステージとは，あるチケットが
ライフサイクルのどの段階にあるかを示す指標です．ステージフラグやその他のフ
ラグによって，誰のどんなチケットが処理待ちになっているかがわかります．

百聞は一見にしかずですから，例を挙げて説明しましょう:

.. image:: http://media.djangoproject.com/img/doc/djangotickets.png
   :height: 451
   :width: 590
   :alt: Django のチケットワークフロー図

まず，チケット処理に関わる人たちには 2 種類の役割があります:

    * コア開発者: コミット権限を持ち，コードに関する決定や，大部分のコード
      作成を行う人です．

    * トリアージ作業者: 個々チケットを追跡して，チケットが正しく分別された
      状態になるよう作業する人です．

次に，トリアージ作業には以下の 4 つのステージがあります:

    1. チケットは「未レビュー(unreviewed)」の状態からスタートします．この状
       態のチケットはまだトリアージ作業者によって検査されておらず，トリアー
       ジ作業が開始されていません．

    2. 「設計判断待ち(design decision needed)」は，「このコンセプトには設計
       上の判断が必要」であり，チケットのコメント欄か， django-developers
       上で議論すべきであることを示しています．

    3. チケットの内容に従った修正が受け入れられた場合，「承認 (accepted)」
       ステージに移行します．このステージは全ての作業が終わった状態です．

    4. チケットにパッチが関連づけられている場合 (下記参照)，トリアージ作業
       者はパッチをレビューします．パッチの内容が完璧なら，「チェックイン可
       (ready for checkin)」にマークされ，コア開発者にパッチをレビューし
       てチェックすべきであることを知らせます．

ワークフローにはもう 1 つ，一連のフラグがあります．フラグは各チケットを
「チェックイン可」にするために必要な条件のうち，何が満たされていて何が必要
かを示します:

    「パッチあり (has patch)」
        チケットに `パッチ`_ が添付されていることを示します．
        このフラグのついたパッチはレビューされ，条件を満たした「よいパッチ」
        であるかどうか調べられます．

    「ドキュメント不足 (needs documentation)」
        パッチつきのチケットに対して，ドキュメントが必要であることを示しま
        す．コードベースに修正をチェックインする条件として，完全なドキュメ
        ントが必要です．

    「テスト不足 (needs tests)」
        パッチに単位テストが必要であることを示します．上ど同様，条件として
        有効なパッチが必要です．

    「パッチに改良の余地あり (patch needs improvement)」
        チケットにパッチが *付属している* が，チェックインするには修正の余
        地があることを示します．パッチが古くてきれいに当てられなくなってし
        まっている場合や，コードがコーディング基準に従っていないことを示し
        ます．

チケットは色々な形で解決されます:

    「修正済み (fixed)」
        パッチが Django に取り込まれ，問題が解決されると，コア開発者はチケッ
        トを fixed にマークします．

    「無効 (invalid)」
        チケットの内容が不正確だったり，何らかの手違いで作成されたチケット
        には invalid マークをつけます．

    「修正の予定なし (wontfix)」
        修正要求を Django に取り込むのは不適切であると判断した場合，コア開
        発者はチケットを wondfix にマークします． wontfix へのマークは，
        通常は ``django-developer`` メーリングリストでの議論の末に選択され
        ることなので，気になる議論があったらぜひ参加してください．

    「他のチケットと重複 (duplicate)」
        他のチケットで同じ問題がカバーされている場合にはチケットを
        duplicate にマークします．重複したチケットをクローズして問題解決の
        ための議論を 1 箇所にまとめ，話を進めやすくするためです． 

    「再現不能 (worksforme)」
        トリアージ作業チームがチケットに記載されているバグを再現できなかっ
        た場合，チケットを worksforme にマークします．

あるチケットが明らかに誤ってクローズされた -- クローズされたチケットで提起
されている問題が依然として生じている場合や，別の問題が生じた場合，あるいは
トリアージ作業でミスが起きている -- 場合には，そのチケットを再度開いて
(reopen)，その理由を記載してください．また，コア開発者が "wontfix" にマーク
したチケットを reopen しないでください．


.. _required details: `Reporting bugs`_
.. _good patch: `Patch style`_
.. _patch: `Submitting patches`_
.. _パッチ: `Patch style`_

.. _Submitting and maintaining translations:

翻訳の提出と維持
================

admin サイトやバリデータのエラーメッセージなど，Django は様々な部分で国際化
されており，ユーザの言語設定に従って様々なテキストを表示します．

翻訳カタログは世界中の Django ユーザによる貢献でできています．間違った翻訳
や，まだ翻訳存在しない言語に新たな翻訳を追加したい場合は以下のようにします:

    * `Django i18n メーリングリスト`_ に参加して自己紹介してください．
    * `i18n のドキュメント` に従って翻訳を作成し，提出してください．

.. _`Django i18n メーリングリスト`: http://groups.google.com/group/django-i18n/
.. _`i18n のドキュメント`: ../i18n/

.. _Coding style:

コーディングスタイル
====================

コードを書いて Django に取り込みたいなら，以下のコーディング標準に従って下
さい:

    * 特に指定のない限り `PEP 8`_ に従って下さい．

    * インデントにはスペース 4 つを使います．

    * 変数名，関数名，メソッド名には camelCase ではなくアンダースコアを使っ
      て下さい (たとえば ``poll.getUniqueVoters`` ではなく
      ``poll.get_unique_voters()``)．

    * クラス名 (やクラスを返すファクトリ関数) には ``InitialCaps`` を使って
      ください．

    * 国際化の必要な全ての文字列をマークしておいてください．詳しくは 
      `i18n ドキュメント`_ を参照してください．

    * コード中に自分の名前を埋め込まないでください．Django プロジェクトでは，
      コードの開発者や貢献者の名前がコード中に散逸しないようにするため，
      ``AUTHORS`` ファイルにまとめて記載するというポリシを採用しています．
      ほんのちょっとした変更でないかぎり，ご自分のパッチに ``AUTHORS`` への
      変更を加えて頂いてもかまいません．

.. _Template style:

テンプレートのスタイル
----------------------

    * Django テンプレートコード内では，波括弧とタグコンテンツの間に 1 個 (1
      個だけ) スペースをいれて下さい．

      [正]::

          {{ foo }}

      [誤]::

          {{foo}}


.. _View style:

ビューのスタイル
----------------


    * Django のビューを書くときには，最初のパラメタは必ず ``request`` とい
      う名前にしてください．

      [正]::

          def my_view(request, foo):
              # ...

      [誤]::

          def my_view(req, foo):
              # ...

.. _Model style:

モデルのスタイル
----------------

    * フィールド名は全て小文字で，キャメルケース (camelCase のような書き方)
      はせず，アンダースコアを使います．

      以下のような書き方をします::

          class Person(models.Model):
              first_name = models.CharField(maxlength=20)
              last_name = models.CharField(maxlength=40)

      以下のような書き方をしてはなりません::

          class Person(models.Model):
              FirstName = models.CharField(maxlength=20)
              Last_Name = models.CharField(maxlength=40)

    * ``class Meta`` はフィールドの定義を書いた *後* に書きます．また，フィー
      ルド定義とクラス定義の間には一行空行を入れます．

      以下のように書きます::

          class Person(models.Model):
              first_name = models.CharField(maxlength=20)
              last_name = models.CharField(maxlength=40)

              class Meta:
                  verbose_name_plural = 'people'

      以下のような書き方をしてはなりません::

          class Person(models.Model):
              first_name = models.CharField(maxlength=20)
              last_name = models.CharField(maxlength=40)
              class Meta:
                  verbose_name_plural = 'people'

      以下のような書き方もよくありません::

          class Person(models.Model):
              class Meta:
                  verbose_name_plural = 'people'

              first_name = models.CharField(maxlength=20)
              last_name = models.CharField(maxlength=40)

    * モデルの内部クラスや標準メソッドの順番は以下のようにします (ただし，
      どれも必須ではないので省略してもかまいません):

        * 全てのデータベースフィールド
        * ``class Meta``
        * ``class Admin``
        * ``def __unicode__()``
        * ``def __str__()``
        * ``def save()``
        * ``def get_absolute_url()``
        * カスタムのメソッド定義

    * ``choices`` をモデルフィールドに定義する場合，選択肢は，各選択項目の
      タプルからなるタプルで定義します．定義はモデルモジュールの冒頭か，各
      モデルクラスのすぐ上に置き，全て大文字の変数名を付けます．例えば以下
      のようにします::

          GENDER_CHOICES = (
              ('M', 'Male'),
              ('F', 'Female'),
          )

.. _Documentation style:

ドキュメントの形式
===================

私達は，ドキュメントの一貫性と読みやすさをとても重視しています (なんといっ
ても， Django はジャーナリズムの中で生まれましたからね！)

.. _Guidelines for ReST files:

ReST ファイル作成のガイドライン
-------------------------------

私達は、 ReST ドキュメントを作成するときに、以下のガイドラインに従っていま
す:

  * 章や節の題名では、最初の文字と適切な名前のみ大文字で書きます．

  * ドキュメントは幅 80 文字以内で折り返します．ただし，コード例を示す際に
    複数行に分けると著しく読みにくくなる場合や，その他妥当な理由がある場合
    は例外です．

.. _Commonly used terms:

よく使う用語
------------

ドキュメント中でよく使われる用語の書き方を以下に示します:

  * **Django** -- フレームワークそのものを指す場合には，頭文字を大文字にし
    ます． Python コード中や djangoproject.com のロゴでは小文字です．

  * **e-mail** -- ハイフンを入れます．(和訳では「メール」と書いています)

  * **MySQL**

  * **PostgreSQL**

  * **Python** -- 言語そのものを指す場合には頭文字を大文字にします．

  * **realize**, **customize**, **initialize**, etc. -- "-ise" ではなく，ア
    メリカ語表記です．

  * **SQLite**

  * **subclass** -- 動詞，名詞を問わず，ハイフンを入れず一つの単語で表しま
    す．

  * **Web**, **World Wide Web**, **the Web** -- ワールドワイドウェブを指す
    場合には，常に Web の W は大文字です．

    * **Web site** -- Web を大文字にして，二つの単語を繋げません．

.. _Django-specific terminology:

Django 固有の用語
-----------------

  * **model** -- 頭文字は小文字です．

  * **template** -- 頭文字は小文字です．

  * **URLconf** -- "URL" は大文字， "conf" は小文字です．

  * **view** -- 頭文字は小文字です．


.. _Committing code:

コードの commit
===============

Django の Subversion リポジトリにコードをコミットする場合には以下のガイドラ
インに従って下さい:

    * 中規模から大規模な変更 (「中規模から大規模」の判断は各自に任せます)
      の際には，変更前に `django-developers`_ メーリングリストに相談を持ち
      込んで下さい．

      `django-developers`_ に持ち込んだ話題に対して返事がなかった場合，自分
      のアイデアが素晴らしく，すぐにでも実装すべきだと皆が思ったため誰も何
      も言わないのだと勘違いしないでください． Django の開発指揮者はメーリ
      ングリストの議論にすぐに割ける時間を持ち合わせていないので，返事には
      数日待たねばならない場合もあるのです．

    * 詳しいコミットメッセージを過去形で書いて下さい．現在形を使ってはなり
      ません．

          * 良い例: "Fixed Unicode bug in RSS API."
          * 悪い例: "Fixes Unicode bug in RSS API."
          * 悪い例: "Fixing Unicode bug in RSS API."

    * ブランチにコミットする場合，コミットメッセージの先頭にブランチ名を付
      けて下さい．例えば "magic-removal: Added support for mind reading."
      のようにします．

    * 意味のある変更のまとまりであるかぎり，できるだけ細かい変更に分けてコ
      ミットしてください．つまり，たまに大きなコミットをするのではなく，小
      さなコミットを頻繁に行うようにしてください．例えば，機能 X を実装して
      いて，その機能の実現にライブラリ Y の修正が必要なら，まず Y の修正を
      コミットして，次に X を別にコミットしてください．これだけで， Django
      のコア開発者全員が変更を追うための *大きな* 助けになります．

    * コミットによって Django `チケットトラッカ`_ の何らかのチケットをクロー
      ズする場合，コミットメッセージの先頭に "Fixed #abc" というメッセージ
      を入れて下さい． "abc" はコミットによって修正されるチケットの番号です．
      例えば "Fixed # 123 -- Added support for foo" のようにします．私達は
      Subversion と Trac を結びつけているので，この形式のメッセージを使って
      commit した場合，関連するチケットを自動的にクローズし，完全なコミット
      メッセージをコメントとしてチケットに追加します．

      コミットによってブランチのチケットをクローズする場合，ブランチ名を先
      にもってきます．例えば
      "magic-removal: Fixed #123 -- Added whizbang feature." のようにします．

      ちなみに，この機能は `Trac の post-commit フック`_ で実現しています．
      .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
      .. _`Trac の post-commit フック`: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook


    * コミットメッセージで Django `チケットトラッカ`_ の何らかのチケットを
      参照し，かつチケットを *閉じない* 場合， "Refs #abc" というフレーズを
      入れて下さい． "abc" はコミットで参照しているチケットの番号です．私達
      は Subversion と Trac を結びつけているので，この形式のメッセージを使っ
      て commit した場合，関連するチケットに完全なコミットメッセージをコメ
      ントとして追加します． 

.. _Unit tests:

単体テストの作成
====================

Django には独自のテストスイートが付属しています．テストは tarball 内の
``test`` ディレクトリ下にあります．ポリシとして，常に全てのテストがパスする
ようにしています．

テストでは以下の項目をカバーしています:

    * モデル API とデータベース API (``tests/modeltests/``)．
    * キャッシュシステム (``tests/regressiontests/cache.py``)．
    * ``django.utils.dateformat`` モジュール
      (``tests/regressiontests/dateformat/``)．
    * データベースの型キャスト (``tests/regressiontests/db_typecasts/``)．
    * テンプレートシステム (``tests/regressiontests/templates/`` および
      ``tests/regressiontests/defaultfilters/``)．
    * ``QueryDict`` オブジェクト (``tests/regressiontests/httpwrappers/``)．
    * markup テンプレートタグ (``tests/regressiontests/markup/``)．
    * ``django.utils.timesince`` モジュール
      (``tests/regressiontests/timesince.py``)．

テストスイートに対する協力は何でも歓迎します!

Django のテストは全て， Django に付属のアプリケーションテストインフラを使っ
ています．テストの書き方の詳細は `Django アプリケーションのテスト`_ を参照
してください．

.. _`Django アプリケーションのテスト`: ../testing/

.. _Running the unit tests:

単体テストの実行
----------------------

テストを実行するには， ``tests/`` ディレクトリ下に移って以下のように入力し
ます:: 

    ./runtests.py --settings=path.to.django.settings

そうです．テストには設定モジュールが必要なだけでなく，データベース設定の情
報，つまり ``DATABASE_NAME`` (指定はせねばなりませんが，内容は無視されます)，
``DATABASE_ENGINE``, ``DATABASE_USER`` および ``DATABASE_PASSWORD`` も必要
です．また，全てのテストをパスするには， ``ROOT_URLCONF`` 設定 (この値は単
にあればよいだけで，内容は無視されます)と， ``SITE_ID`` 設定 (整数ならどん
な値でもかまいません) も指定しておかねばなりません．

単体テストは既に作成済みのデータベースに影響を及ぼすことはありません．単体
テストは ``django_test_db`` というデータベースを作成しますが，これはテスト
終了時に削除されます．また，この理由から，テストを行うユーザアカウントには
``CREATE DATABASE`` を実行する権限が必要です．

.. _Requesting features:

機能に関する要望
===================

私達は常に Django を改良しようと努めています．その中で，皆さんから寄せられ
る要望は一つの鍵になっています．効果的に要望を出すコツをいくつか紹介してお
きます:

    * チケットトラッカではなく， `django-developers`_ に要望を出して下さい．
      メーリングリストの方が多くの人の目に触れやすいからです．

    * 不足している機能と，それをどのように実装すればよいと思っているかを，
      すっきりと，かつ詳細に説明してください．可能ならサンプルコード (実際
      に動かなくても構いません) をつけてください．

    * *なぜ* その機能を取り入れたいのかを説明してください．自明な場合もあり
      ますが， Django は実際の開発者が実際の仕事に使うために設計されている
      ので，ある機能がどのようにユーザの役に立つのかを説明する必要がありま
      す．

ほとんどのオープンソースプロジェクトと同じく，コードは大きな説明力を持って
います．追加したい機能のコードを書く意志があるか，(さらに望ましいのは) すで
に書き上げているのなら，ずっと受け入れられやすくなるでしょう．大がかりな機
能で，複数の開発者が必要になりそうなら，いつでも喜んで実験用ブランチをリポ
ジトリに作成します．詳しくは次節を参照してください．

.. _Branch policy:

ブランチの管理ポリシ
====================

一般に，ほとんどの開発は trunk で行われており， trunk は安定に保たれていま
す． trunk のコードは，いついかなるときでも実運用サイトを動作させられなけれ
ばなりません．

このため，大規模なアーキテクチャ上の変更，一つのパッチに収まらないくらい大
きな変更を伴う場合や，多くの人が関わる必要のある変更の場合には，専用のブラ
ンチを作成します．例えば `i18n ブランチ`_ を見てください．この手の変更を行
いたいと考えていて，作業をしたい場合には， `django-developers`_ でブランチ
を作成してもらうよう問い合わせて下さい．変更を試すのに必要な文だけのブラン
チを作成します．

ツリーの一部にしか作業しない場合でも，常に Django ツリー全体のブランチを作
成します．これはブランチへのスイッチ作業を苦痛なく行えるようにするためです．

ブランチで作業している開発者は， trunk の変更を定期的にブランチにマージせね
ばなりません．少なくとも週に一度はマージしてください． trunk からマージを行
う度に，マージとリビジョン番号を commit メッセージに記載してください．

ブランチが安定していて， trunk へのマージ準備が完了したら，
`django-developers`_ にアラートを投稿します．

あるブランチがマージされると，そのブランチは「死んだ」ものとみなされます．
死んだブランチには書き込めなくなり，古いブランチは定期的に「刈り取られ」
ます． SVN への世話焼きを最小限にするため，ブランチから trunk へのマージは
一度しか行いません．

.. _Using branches:

ブランチを使う
--------------

ブランチをテストするには，二つの作業が必要です:

    * 該当するブランチのコードを Subversion から取得します．

    * Python の site-package ディレクトリが，該当ブランチの ``django``
      を含むように設定します．


.. _Getting the code from Subversion:

Subversion からコードを取り出す
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ブランチコードの最新版を入手するには Subversion を使います::

    svn co http://code.djangoproject.com/svn/django/branches/<branch>/

``<branch>`` はブランチの名前です．ブランチの名前については
`ブランチ名一覧 <http://code.djangoproject.com/browser/django/branches>`_ 
を参照してください．

既存の Django を Subversion からソースコードをチェックアウトして使っている
場合には，ディレクトリ全体を特定のバージョンに自動的に変換できます．
``django`` ディレクトリの下で以下のコマンドを実行してください::

    svn switch http://code.djangoproject.com/svn/django/branches/<branch>/

``svn co`` ではなく ``svn switch`` を使う利点は， ``switch`` コマンドを使っ
た場合，ローカルコピー上で既に変更済みの内容についてはファイルを変更しない
点にあります． ``switch`` はローカルコピー上の変更を "スイッチ先の" コード
にマージします． ``svn switch`` には欠点もあります．それは，ローカルコピー
上でコードに変更を加えた場合，スイッチ先のコードにも同じ部分に変更があると
衝突するという問題です．

(``svn switch`` を使う場合には，次の節で述べるような，Pythonのモジュール検
索パスを変更する操作は必要ありません．)

.. _list of branch names: http://code.djangoproject.com/browser/django/branches

.. _Pointing Python at the new Django version:

Python に別のバージョンの Django を使わせる
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ブランチのコードを取り出したら，ブランチの ``site-packages`` ディレクトリ
の構成を変更して，ブランチ版の ``django`` ディレクトリを使えるようにする必
要があります．
(``site-packages`` ディレクトリは ``/usr/lib/python2.4/site-packages`` や
``/usr/local/lib/python2.4/site-packages``, ``C:\Python\site-packages``
などにあります．)

もっとも簡単な方法は，元の ``django`` ディレクトリを ``django.OLD`` のよう
な別の名前に変えて， trunk などから取り出したバージョンのコードをコピーし，
名前を ``django`` に変更します．

別の方法として， ``django`` と言う名前のシンボリックリンクを作成して，特定
のブランチの ``django`` パッケージの場所を指すという方法もあります．元に戻
したい場合には，シンボリックリンクが元のコードを指すように変更しなおすだけ
です．

第三の方法は， 
`パスファイル <http://python.jp/doc/release/lib/module-site.html>`_
(``<something>.pth``) を使うというものです．この方法は， (シンボリックリン
クを使えない Windows を含む) 全てのシステムで利用できます．まず， 
``site-packages`` ディレクトリに， ``django`` という名前のファイルやディレ
クトリ，シンボリックリンクがない状態にしてください．次に， ``django.pth``
という名前のテキストファイルを作成して， ``site-packages`` ディレクトリの直
下に保存します．このファイルには，使いたい Django の置かれているパスを一行
で記述します．コメントを追加しても構いません．複数のブランチを指定できるよ
うにしたパスファイルの例を以下似示します．特定のブランチ (例えば 'trunk')
を使いたい場合，その行のコメントを解除して，他の行を全てコメント化します::

    # トランク (trunk): svn リポジトリの
    #   http://code.djangoproject.com/svn/django/trunk/
    # からチェックアウトしたもの
    #
    /path/to/trunk
    
    # ブランチ (branch): ブランチ名 <branch> を svn リポジトリの
    #   http://code.djangoproject.com/svn/django/branches/<branch>/
    # からチェックアウトしたもの
    #
    #/path/to/<branch>
    
    # Windows の場合は以下のような形式にします:
    # C:/path/to/<branch>

Django 0.95 やそれ以前のバージョンをインストールしていて，インストールに
``python setup.py install`` を使った場合， ``django`` ではなく
``Django-0.95-py2.4.egg`` といった名前のディレクトリになっているでしょう．
この場合， ``setuptools.pth`` を編集して，該当する Django の ``.egg``
の書かれた行を削除してから， ``django`` のブランチを ``site-packages`` にコ
ピーします．

.. _path file: http://docs.python.org/lib/module-site.html

.. _Official releases:

公式リリース
============

Django のリリース番号は以下のようにして付けられます:

    * バージョンは ``A.B`` または ``A.B.C`` という形式でつけられます．

    * ``A`` はメジャーバージョン番号で，増えるのは Django に重大な変更が加
      えられ，変更が必ずしも以前のバージョンと互換でない場合だけです．従っ
      て， Django 6.0 で動いたコードは Django 7.0 では動かなくなるかもしれ
      ません．

    * ``B`` はマイナーバージョン番号で，比較的大きいながらも後方互換性を保っ
      た変更の際に増えます． Django 6.4 向けに書かれたコードは Django 6.5
      でも動作するでしょう．

      マイナーリリースでは，以前のリリースの特定の機能を撤廃することがあり
      ます．バージョン ``A.B`` の機能が撤廃された場合，撤廃された機能は
      ``A.B+1`` では動作します． ``A.B+2`` では
      ``PendingDeprecationWarning`` 警告を送出しますが動作します．
      ``A.B+3`` では完全に機能を削除します．メジャーポイントリリースでは撤
      廃済みの仕様を全て削除します．

    * ``C`` はマイクロバージョンで，バグやセキュリティ修正の度に増えます．
      マイクロバージョンは以前のマイクロバージョンと 100% 後方互換性を保ち
      ます．

    * 場合によってはリリース候補 (release candidate) を作成します．リリース
      候補のバージョン番号は  ``A.BrcN`` の形式で， ``A.B`` の ``N`` 番目の
      リリース候補であることを表します．

以上のバージョン番号スキームの例外として，1.0 以前の Django のコード
があります． 1.0 リリース以前のコードでは，後方互換性を全く保証していません．

Subversion 上では， Django の各リリースは `tags/releases_` でタグづけされて
います．trunk 由来ではないバグフィクスリリースやセキュリティ修正リリースを
出す必要画ある場合，該当リリースは  ``branches/releases`` にコピーされ，
バグフィクスリリースになります．

.. _Deciding on features:

仕様に関する決定
================

ある仕様の要望が出て議論が始まると，そのうち仕様を取り入れるべきか棄却すべ
きかという決定をせねばなりません．

私達は，可能な場合はいつでもまずおおまかな合意を形成しようと試みます．その
後，たいていは `django-developers`_ において，その機能について正式でない投
票を行います．投票では， Apache や Python で使われている形式を採用しており，
投票は +1, +0, -0, or -1 のいずれかを用いて行います．これらの票の大雑把な解
釈は以下の通りです:

    * +1: "これはいい．強く同意します (I love the idea and I'm strongly
      committed to it.)"

    * +0: "いいんじゃないかな (Sounds OK to me.)"

    * -0: "あまりわくわくしないが，反対もしない (I'm not thrilled, but I
       won't stand in the way.)"

    * -1: "強く反対．このアイデアが実現したらとても嫌 (I strongly disagree
       and would be very unhappy to see the idea turn into reality.)"

django-developers での投票は正式なものではありませんが，その結果は真摯に受
け止められます．適切な投票期間を経て，明らかな合意を形成できた場合には，投
票の決定に従うでしょう．

とはいえ，つねに合意を形成できるわけではありません．その場合，完全コミッタ
全員の中で十分に議論を重ねた後，最終判断を慈悲深き終身独裁者 (Benevolent
Dictators for Life) である Adrian と Jacob に委ねることとします．

.. _Commit access:

commit 権限
=============

Django プロジェクトには二種類のコミッタがいます:

完全コミッタ (full committers)
    長期間にわたって Django のコードベースに貢献してきており，メーリングリ
    ストにおいても礼儀正しく親切で， Django の開発に十分な時間を割けること
    が分かっている人達です．

    完全な commit 権限者の敷居は極めて高いものです．全ての完全コミッタによ
    る全会一致でのみ受け入れることとし，その決定は覆りません．

部分コミッタ (partial committers)
    「個別領域のエキスパート」です．管轄下にあるサブシステムのコードに直接
    チェックインする権限を持ち，サブシステムの懸案事項に対する正式な投票権
    を持ちます．このタイプの権限は， Django の大きなサブフレームワーク
    に貢献し，継続してメンテナンスを続けたい人に与えられるものです．

    完全コミッタと同様，部分コミッタの受け入れも全ての完全コミッタ (と同じ
    領域の部分コミッタ) による全会一致でのみ受け入れることとします．とはい
    え，敷居はやや低く，個別領域で十分な専門性を示しているということで十分
    です．

コミット権限を得たければ，現在コミッタを勤めているだれかに個人的にコンタク
トしてください．コミット権限を公の場でリクエストするのはフレームの元であり，
一切無視します．

.. _`コミュニティのページ`: http://www.djangoproject.com/community/
.. _`チケットトラッカ`: http://code.djangoproject.com/newticket
.. _`トラッカを検索`: http://code.djangoproject.com/search
.. _`パッチつきのチケットのリスト`: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=1&order=priority
.. _`i18n ドキュメント`: ../i18n/
.. _`i18n ブランチ`: http://code.djangoproject.com/browser/django/branches/i18n

.. _community page: http://www.djangoproject.com/community/
.. _ticket tracker: http://code.djangoproject.com/newticket
.. _django-developers: http://groups.google.com/group/django-developers
.. _FAQ: ../faq/
.. _search the tracker: http://code.djangoproject.com/search
.. _django-users: http://groups.google.com/group/django-users
.. _`#django`: irc://irc.freenode.net/django
.. _list of tickets with patches: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=1&order=priority
.. _PEP 8: http://www.python.org/peps/pep-0008.html
.. _i18n documentation: ../i18n/
.. _i18n branch: http://code.djangoproject.com/browser/django/branches/i18n
.. _`tags/releases`: http://code.djangoproject.com/browser/django/tags/releases