Subversion

TurboGears?のsubversionリポジトリは以下にあります:

http://www.turbogears.org/svn/turbogears

開発は２つのブランチで行われています。1.0ブランチは1.0リリースのためにバグフィクスが行われるためのもので、もう一つは1.1の開発が行われるためのものです。ただしこの1.1用のtrankは壊れているかもしれませんので、何をしているか把握していない限り、実際に使わないでください。

1.0ブランチをチェックアウトするためには、ふつうは以下のコマンドを使ってください:

svn co http://www.turbogears.org/svn/turbogears/branches/1.0/ turbogears

もしくはtrunkをチェックするためには以下のようにします:

svn co http://www.turbogears.org/svn/turbogears/trunk turbogears

これによって1.0ブランチやtrunkが入っている "turbogears" というディレクトリが生成されるでしょう。

基本的なSubversionクライアントは 公式Subversionサイト で得ることができますし、また各プラットフォーム用のGUIクライアントも得られます。 Version Control with Subversion という本もオンラインで読むことができます。

eggを使った開発

TurboGears?（そしてquickstartによってTurboGearsが作成したプロジェクト）は、パッケージングや配布をより簡単にするために setuptools を使っています。

TurboGears?そのものの開発を始めるために、チェックアウトしたディレクトリに入って以下のようにします:

python setup.py develop

このコマンドはsetuptoolsに、インストールされた他のTurboGears eggではなく、そのTurboGearsのためにsetuptoolsを使おうとしているということを伝えます。

依存関係を扱う

TurboGears?のリリースによって各コンポーネントプロジェクトがアップグレードされることは珍しくありません。TurboGearsに使われているコアなコンポーネントプロジェクトのために、適切なバージョンを照合するものとして svn:externals がサードパーティディレクトリの中にあります。コンポーネントプロジェクトがアップグレードされると、新しいバージョンを反映するためにsetup.pyファイルも変更されます。

もし開発中のTurboGearsを動かしていて依存関係のエラーが出た場合は、サードパーティのディレクトリにいき、以下のようにすることでおよそ解決できるでしょう:

python -c "import setuptools; execfile('externals.py')" develop

代わりに以下のようにすることも可能です:

easy_install .

これらはsvnのアップデートで追えていないスナップショットをインストールしてくれるでしょう。

TurboGears?が使用しているプロジェクトの一つに変更を加えようとしているなら、そのプロジェクトの適切なバージョン（通常はtrunk）が手元にあることを確認してください。正しいバージョンのプロジェクトを適切な場所にあれば、 "python setup.py develop" を実行することでそのツールの開発バージョンを使い始めることができます。

コードスタイル

すでにコードスタイルが確立されたドキュメントを書いてきた人と議論するのは難しいですので、TurboGearsでは PEP 8 の慣習にならいたいと思います。

テストする

自動化ユニットテストをするのが良いです。これはプロジェクトの将来的な成長を可能にします。

TurboGears?はテストを簡単にしてくれる Nose を使います。 Nose を使うには以下のようにします:

easy_install nose

（他で easy_install コマンドを使うとき同様、 --script-dir オプションを使ってコマンドラインツールをどこにインストールするかをeasy_installに教えてやる必要があるかもしれません。またUnixライクなシステムではそのディレクトリにアクセスするために "sudo" を使う必要があるかもしれません。）

インストールすれば以下のようにしてTurboGearsテストを実行することができます:

 nosetests

``turbogears.testutil`` パッケージは、テストをすることと同様、開発を楽にしてくれるいくつかのユーティリティや関数を含んでいます。

ドキュメンテーション

TurboGears?の哲学 で述べたように、機能はドキュメント化されるまでは本当に存在してはいないのです。テストをすることは良いドキュメントにつながります。何故なら少なくともその機能が正確であることがわかるからです。しかし何らかの情報を英語で提供することもステキなことです。

ドキュメントには２種類あって、それぞれに有用な場所があります。（ソースへのリンクを含んだ） epydoc はウェブサイトでAPIドキュメントを生成するのに使われます。コードにepydocのdocstringを追加するのはそれほど骨の折れる仕事ではありません。

さらにTurboGearsプロジェクトでは docs.turbogears.org Wikiにおいてドキュメントを管理しています。

あなたが何か力を貸してくれるなら、どうかサイトの適切なRoughDocsセクション（例えばバージョン1.1に対しては1.1/RoughDocs?）に記事を書いてください。いずれドキュメントのエディタがそのドキュメントを公式ドキュメントへと移行するでしょう。もしかしたら公式ドキュメントの他の部分に雰囲気が合うように少し編集を加えるかもしれませんが。

どうかあなたの仕事をドキュメント化してください。シェークスピアである必要はありません。エディタはドキュメントを書くことをあなた以上には楽しめませんし（むしろコーディングをしたいのです）、あなたのコードを説明したりスクラッチから何かを書き上げるよりも既存のドキュメントを編集する方が簡単なのです。

変更点をドキュメント化する

Trac は追加された変更点や新しいバージョンのリリース前に必要なタスクを追跡するのに使われています。 changelog では人間が読むことができる形で変更点を提供しています。

リリース直前にchangelogをアップデートすることはそのリリースを遅くするだけです。どうか 変更を行ったときにchangelogをアップデートしてください。 そしてこのことは 特に後方非互換性にとって 重大なことです。

パッチの提出

1. メーリングリストにその事柄を報告する（バグならturbogearsに、機能ならturbogears-trunkに）
2. それが本当にバグか、あるいは有用かを議論し決定する
3. Trac にチケットを発行する
4. パッチを添付し、タイトルに [PATCH]? を入れる。どのブランチに当てるパッチなのかに注意する
5. そのチケットに対する追加事項をメーリングリストで議論する
6. （オプションとして）それが受け入れられるか確かめるための議論をする