Table Of Contents
Contributing(翻訳済み)¶
Kivyに貢献できる方法はたくさんあります。コードパッチは、プロジェクトを支援するために提出できるものの中でただ一つのものです。また、フィードバック、バグレポート、機能のリクエスト、ドキュメントの改善、広告と主張、テスト、グラフィックスの寄稿、その他多くのアイデアを歓迎します。手助けをしたいのであればであれば私たちに話してください。相互に助け合いましょう。
Feedback(フィードバック)¶
これは貢献する最も簡単な方法です。独自のプロジェクトにKivyを使用している場合は、共有をためらわないでください。それは明らかにハイクラスなエンタープライズアプリである必要はありません。人々があなたが開発したものを使うことと、それができるのを可能にすることを知ることは信じられないほどの動機付けになります。私たちに言いたいことがあれば、ためらわないでください。スクリーンショットやビデオも大歓迎です！私たちはまた、あなたが始めた時の問題にも興味があります。不足しているドキュメントや誤解を招くような指示など、遭遇した障害を報告するよう奨励します。私たちは完璧主義者なので、それが単なるタイプミスであっても、私たちにお知らせください。
Reporting an Issue(問題を報告する)¶
何か間違ったことや、クラッシュ、セグメンテーション、文書ミス、スペルミス、または例おかしいなど見つかった場合は、問題を2分程度で報告してください。
`<user_directory>/.kivy/config.ini`を編集してログレベルを変更してください:
[kivy] log_level = debug
コードをもう一度実行し、完全な出力をhttp://gist.github.com/にコピーアンドペーストしてください。これには、Kivyとpythonのバックトレースからのログも含まれます。
問題のタイトルを設定します。
http://gist.github.com/ に投稿された出力の問題を再現するには、どういった手順が必要か正確に説明してください。
問題を検証できれば完了です！
もし検証できている場合は、バグを解決し、私たちにパッチを送って貢献できます。これを行う方法については、次のセクションをお読みください。
Code Contributions(コードの寄与)¶
コードの寄稿（パッチ、新機能）は、プロジェクトの開発を支援する最も明白な方法です。これは非常に一般的なので、私たちのワークフローに従って最も効率よく作業するようにお願いします。私たちのワークフローを遵守すれば、あなたの貢献を忘れたり紛失することはありません。また、あなたの名前は作った変更に常に関連しています。これは基本的にコード履歴での不朽の名声を意味します（あなたがそれを望まないなら、あなたはオプトアウトできます）。
Coding style(コーディングスタイル)¶
まだ実行していないなら、Pythonのコーディングスタイルについて`PEP8 <http://www.python.org/dev/peps/pep-0008/>` を読んでください。
次のようにgitコミットでpep8チェックを有効にします:
make hook
コミットするときにgitのステージングゾーンに追加されたコード（コミットしようとする場合）をpep8チェッカープログラムで渡し、pep8エラーが発生していないことを確認します。エラーがある場合、コミットは拒否されます。エラーを修正してから、再度やり直してください。
Performance(パフォーマンス)¶
パフォーマンスの問題を処理する：`Python performance tips<http://wiki.python.org/moin/PythonSpeed/PerformanceTips>`_ を読む。
Kivyのcpu集約部分はcythonで書かれています。計算をたくさんする場合は、使用することを検討してください。
Git & GitHub(Git と GitHub)¶
gitをコードベースのバージョン管理システムとして使用します。これまでにgitやそれと同様のDVCS（またはさらにはVCS）を使用したことがない人は、git onlineで入手可能な素晴らしいドキュメントをご覧ください。 Git Community Book または`Git Videos <https://git-scm.com/videos>`_ は、gitを学ぶ素晴らしい方法です。gitが素晴らしいツールだと言う私たちの言葉を信じてください。最初は気にいらないかもしれませんが、しばらくしてから、私たちのgitへの愛情を（うまくいけば）覚えています。しかし、gitを教えることは、この文書の範囲をはるかに超えています。
また、 GitHub を使用してコードをホストします。以下では、（無料の）GitHubアカウントがあると仮定します。この部分はオプションですが、パッチとアップストリームコードベースとの緊密な統合が可能です。もしあなたがGitHubを使いたくないなら、あなたが何とかしていることを知っていると思われます。
Code Workflow(コードワークフロー)¶
ここでは、ワークフローを開始するための初期設定を紹介します（Kivyをインスト”ールするには、これを一度だけ実行する必要があります）。基本的には、 Installing Kivy for Development(Kivyの開発版をインストール) にインストールする（Kivyの開発版をインストール）のインストール手順に従いますが、リポジトリをクローンしないでフォークします。ここに手順があります：
Log in to GitHub(GitHubにログインする)
「fork」ボタンをクリックして、`Kivy repository <https://github.com/kivy/kivy>`のフォークを作成します。
私たちのリポジトリのフォークをあなたのコンピュータにクローンします。あなたのフォークはgitのリモート名 「origin」を持ち、あなたはブランチ 「master]にいます：
git clone https://github.com/username/kivy.gitPYTHONPATHをコンパイルして設定するか、インストールしてください（:ref:`dev-install`を参照してください）
クローンのルートディレクトリから「make hook」を実行することで、あなたのコードが私たちのスタイルガイドに違反しないことを保証するpre-commitフックをインストールしてください。”コミットするたびにスタイルガイドのチェックを行い、変更したパーツに違反があると、コミットは中止されます。修正して再試行してください。
Kivy Repoをリモートソースとして追加します：
git remote add kivy https://github.com/kivy/kivy.git
パッチを作成する場合は、次の手順に従います：
バグトラッカーに修正または機能追加のチケットがあるかどうかを確認し、担当する人がまだいない場合は作業することを発表します。
その特定の機能やバグ修正のために、適切な名前の新しいブランチをローカルリポジトリに作成します。 （機能ごとに新しいブランチを保持すると、プルする予定のない他のものを引っ張らずに、変更を簡単に取り込むことができます。）：
git checkout -b new_featureコードを修正して、必要な作業（たとえば修正）を行います。
コードをテストします。小さな修正であって試してください。テストせずに奇妙なバグが導入されたかどうかは決して分かりません。
修正または機能ごとに1つ以上の最小限のコミットを実行します。 Minimal / Atomicは、*コミットをきれいに保つ*ことを意味しています。このフィックスに論理的に属していない他のものをコミットしないでください。これは変更された行ごとにコミットを作成することではありません。必要に応じて「git add -p」を使用します。
それぞれのコミットに適切なコミットメッセージを与えることで、精通していない他の人が変更内容を知ることができます
変更に満足したら、上流のリポジトリを引っ張ってローカルリポジトリとマージします。私たちはあなたのものを引き出すことができますが、変更内容を正確に知っているので、マージを行う必要があります:
git pull kivy masterローカルブランチをGitHubのリモートリポジトリにプッシュします：
git push origin new_featureあなたのリポジトリのGitHubインターフェイスのボタンを使って変更した内容の説明とともに*プルリクエスト*を送信します。（これは私たちが最初にフォークした理由です。あなたのリポジトリは私たちとリンクしています。）
警告
コンパイルが必要なコードベースの部分を変更する場合は、変更を有効にするために再コンパイルする必要があります。 「make」コマンドはあなたのためにそれを行います”（それが何であるかを知りたい場合はMakefileを見てください）。現在のディレクトリをコンパイルしたファイルから消去する必要がある場合は、「make clean」を実行します。バージョン管理下にないファイルをすべて削除するには、make distcleanを実行します（注意：変更がバージョン管理下にない場合、このコマンドはそれらを削除します）。
あなたのプルリクエストを受け取った場合。私たちはあなたの変更が明快であるかどうかをチェックします（もしあなたがこれをする前に私たちと話をしたら、それが意味をなさないかどうか話したでしょう）。もしそうなら、我々はそれらを引っ張り、インスタントカルマを得るでしょう。おめでとう、あなたはヒーローです！
Documentation Contributions(ドキュメントの寄与)¶
ドキュメンテーションへの寄稿は、通常のコードの寄稿と同じワークフローに従いますが、ちょっとだけ厳しいです。
下記の手順に従ってください
リポジトリをフォークします。
フォークをコンピュータにクローンします。
kivy repoをリモートソースとしてセットアップします。
python-sphinxをインストールします。 （
docs/READMEを参照してください。）ReStructuredText_Markupを使用して、ドキュメント/ソースのHTMLドキュメントに変更を加えます。
ドキュメントの更新をサブミットするには、次の手順を実行します。
ローカルのリポジトリに適切な名前の新しいブランチを作成します:
git checkout -b my_docs_update訂正または改善を行って文書を修正してください。
HTMLページを再生成し、更新を確認してください:
make htmlそれぞれのコミットに適切なコミットメッセージを与えることで、精通していない他の人が変更内容を知ることができます
1つの関連するテーマに焦点を当てたままにしてください。論理的にこのアップデートに属していない他のものをコミットしないでください。
GitHubのリモートリポジトリにプッシュします:：
git pushリポジトリのGitHubインターフェイスのボタンを使用し、変更した内容の説明とともにプルリクエストを送信します。
ただ1つのタイプミスを修正するためにすべての工程で確認する必要はありませんが、より複雑な投稿については、提案されたワークフローに従ってください。
Docstrings¶
すべてのmodule、class、methodの関数にはdocstringが必要なので、関連する場合は次のキーワードを使用してください：
.. versionadded::は、機能が追加されたバージョンをマークします。.. versionchanged::to mark the version in which the behaviour of the feature was changed... note::to add additional info about how to use the feature or related feature.. warning ::は、ユーザーがこの機能を使用する際に発生する可能性のある問題を示します。
例:
def my_new_feature(self, arg):
"""
New feature is awesome
.. versionadded:: 1.1.4
.. note:: This new feature will likely blow your mind
.. warning:: Please take a seat before trying this feature
"""
結果は以下になります:
- def my_new_feature(self, arg):
New feature is awesome
バージョン 1.1.4 で追加.
注釈
This new feature will likely blow your mind
警告
Please take a seat before trying this feature
APIの他の部分を参照する場合：
:class:`~kivy.module.Class`はクラスを参照します:meth:`~kivy.module.Class.method`メソッドを参照します:doc:`api-kivy.module`はモジュールのドキュメントを参照します（クラスとメソッドと同じです）
明らかに、モジュールのクラスとメソッドを実際の名前に置き換え、組み込みモジュールを参照するモジュールを分離するために ‘.’を使用しています。例えば:
:mod:`~kivy.uix.floatlayout`
:class:`~kivy.uix.floatlayout.FloatLayout`
:meth:`~kivy.core.window.WindowBase.toggle_fullscreen`
:doc:`/api-kivy.core.window`
結果は以下になります:
とはurlのアンカーを除いては基本的には同じです。:doc:` はクリーナーURLを優先します。
ドキュメントをビルドするには、次のコマンドを実行します:
make html
Kivyのインストールを更新してドキュメントをコンパイルする際に問題がある場合は、次のコマンドを実行してください：
make clean force html
docsはdocs / build / htmlで生成されます。 docstringフォーマットの詳細については、公式の`Sphinx Documentation <http://sphinx-doc.org/>`を参照してください。
Unit tests contributions(ユニットテストでの貢献)¶
テストチームのために、Kivyのユニットテストの仕組みと独自のテストを作成する方法を説明した Unit tests(翻訳済み) のドキュメントがあります。 Code Workflowと同じアプローチを使用して、新しいテストを提出してください。