プロジェクトに貢献する

プロジェクトに貢献するには

以下のようなコントリビューションをお待ちしています!

  • バグリポートや機能要望などを投稿してください。Jubatus では GitHub Issues を課題追跡システムとして使用しています (詳細は以下を参照)。
  • GitHub issue として登録されているバグを修正したり、フレームワークに新しい機能を実装してください。
  • ドキュメントの改善: website リポジトリ に pull-request を送ってください。typo や表現の誤りの訂正など、小さな修正も歓迎します。
  • あなたのニーズを メーリングリスト に投稿してください。
  • お使いの環境で Jubatus がビルド/実行できたかどうか、 メーリングリスト で教えてください (CPU の種類、OS/コンパイラのバージョンなど)。
  • フィードバック (コメント、発生した問題、機能の要望など) や、あなたが Jubatus をどのように活用しているか/しようと思っているかを メーリングリスト で教えてください。

コミュニティへの参加

次のような、他のユーザや開発者と直接やり取りをすることのできるコミュニティが用意されています。

Issue の書き方

Issue を効率的に処理するため、以下のガイドラインを参考に記入してください。

  • バグリポートについては、開発者がバグの内容を理解して再現できるレベルで記述してください。
  • それ以外の内容 (機能要望など) については、「なぜその機能が必要なのか」「どういったユーザが利用するのか」などを記述してください。
    • これらは Jubatus コミッタが優先度を判断する基準になります。

Pull-Request ポリシー

コード/ドキュメントに対する Pull-Request も歓迎しています。

  • Pull-Request はすべて、一人以上の Jubatus コミッタがレビューします。レビュアーは担当領域ごとに決められています。
  • レビューが終わると、Pull-Request は次のいずれかの状態になります:
    • ACCEPTED: Pull-Request されたコードがマージされます。コミッタが、マージ後に微調整 (コーディングスタイルの修正など) を行うことがあります。
    • NEED FIX: バグや機能上の問題があるか、単体テストが書かれていないため、そのままではマージできません。レビュアーがどのように改善すべきかを提示します。
    • REJECTED: 例えば、Jubatus のロードマップに一致しない、または第三者の権利を侵害している可能性があるなどの場合は、Pull-Request をリジェクトすることがあります。このような事態を避けるために、特に大きな変更を加えようとしている場合は、実際に作業を始める前に Jubatus コミッタと取り組もうとする内容についてディスカッションすることをおすすめします。
  • Jubatus のロードマップによって、場合によっては Pull-Request のマージに時間がかかる場合もあります。

Pull-Request を送信する場合は、事前に Jubatus 貢献者ライセンス同意書 (CLA) への同意をお願い致します。 CLA への同意は CLA 送信フォーム から行うことができます。

コントリビュータのための Tips

コードをコントリビュートする場合は、Pull-Request を送る前に以下のポイントを確認してください:

  • 単体テストをパスしていること (./waf --checkall を実行)
    • 単体テストを実行するには Jubatus のビルド環境が必要です。必要なツールやライブラリについては Jubatus をソースからビルドする を参照してください。
  • コーディングスタイルのテストをパスしていること (./waf cpplint を実行)
  • 該当する場合は、単体テストが追加されていること。Jubatus では単体テストフレームワークとして Google Test を使用しています。
  • 既存の Issue を修正した場合は、コミットログに "#XXX" の形で Issue No を含めてください。
  • 新しいアルゴリズムを実装した場合は、Pull-Request の説明文に参照した論文の情報を含めてください。
  • 作業を develop ブランチから開始していることを確認してください。pull-request は、 master ではなく develop ブランチに送る必要があります。