作業やサービスの送信に関するガイドライン

すべての参加コントリビューターは、最終評価でプログラムに対する取り組みへのリンクを提示する必要があります。これが正しく行われないと、プログラムが失敗する可能性があります。これを行うには複数の方法があるため、このドキュメントを注意深くお読みください。

これらのリンクは、GSoC プロジェクトの公開アーカイブで公開されます。プログラムの実施中に行われた作業のデモンストレーションを助けます。また、将来の雇用主のために自分の仕事を振り返ることができる素晴らしい方法です。ユーザーがプロジェクトの目標、達成したこと、コードの位置、次のステップをすぐに理解できるようにしてください。

過去数年間に見られた優れた例は、以下を含む「最終レポート」のようなものです。

  • プロジェクトの目標に関する簡単な説明。
  • やったことね。
  • 現在の状況:
  • 残りのステップをご確認ください。
  • アップストリームでどのコードがマージされた（またはマージされなかった）か。
  • プロジェクト中に課題や学んだ重要なこと。

例を確認するには、2022 年のプロジェクト リストから開始し、プロジェクトをランダムに選択して、[コードを表示] をクリックします。これらのプロジェクトの多くが Google の提案に沿っていないため、自作の成果を披露することができず、被害に遭うだけです。

コントリビューターへの注意事項: 最終提出の課題は、最終提出の締切日まで編集できます。

評価を送信する前に、メンターにリンクを共有して、メンターの期待に応えるものであることを確認することをおすすめします。

要件

  • 自分の作業を簡単に特定できる必要があります。（行った変更や新しいコードなど）。
    • 指定された URL にアクセスしたユーザーが、その URL を掘り下げて調べなくても、どのような操作をしたかを明確にする必要があります。
  • 安定した場所に保存する必要があります。送信後に URL を変更することはできません。
  • 作業を拡張するために、リンクのターゲット（またはリンク先から参照）のコンテンツは、他のユーザーが使用できるようにする必要があります。
    • 課題が 100% 完了していれば、生徒はその課題を使用できる必要があります。
    • 作業が 100% 完了していない場合は、残りの作業を明確にする必要があります。

良い例

これらをすべて（またはいずれか）行う必要はありませんが、要件を満たすには、以下を行う必要があります。

  • ブログ投稿、ウェブページ、公開 GitHub gist を作成し、これまでの作業についての説明と、commit の内容とリポジトリへのリンクを記載します。プロジェクトでまだ行う作業がある場合は、それも含めます。ハイライトや難しい課題を共有することもできます。
    • ❗ 多くの情報を簡単に追加できるため、これが最適なオプションです。これによってコードの実行が明確になり、他のユーザーがコードを使用しやすく理解しやすくなります。
  • GitHub を使用していて、すべての作業が 1 つの pull リクエストで対象となる場合は、このリンクを使用できます。
    • pull リクエストの説明が詳細に記述されていることを確認します。（上記のブログ投稿の内容に関する提案をご覧ください）。
    • 説明に、これが Google Summer of Code 向けであることを明記してください。
    • GSoC の終了後に pull リクエストでさらに処理が行われる場合は、最後の GSoC コミットをメモしておきます。
    • ❗ この例には、変更ログ、commit のリスト、レビュー コメントがすべて 1 か所にまとめられるというメリットがあります。
  • GitHub リポジトリが GSoC の単一目的の場合は、README.md を追加して詳細を追加してください。
  • アーカイブされたデベロッパー メーリング リストに上記のメールとリンクのメールを送信してください。
  • Google ドライブに一般公開フォルダを作成し、作成したすべてのパッチを含めます。
  • Google スプレッドシートで一般公開のスプレッドシートを作成し、すべての commit を一覧表示する。
  • 作業内容やその他の適切な情報への参照が明確に含まれる 1 つのバグにリンクします。すべての作業が記録されるはずです。commit は、リスト内にすべて一覧表示しないと簡単に見つかるようにします。
  • 変更の統合またはコンテキスト差分にリンクします。他の開発者に役立つよう、対象のプロジェクトや所属先を記したヘッダーを必ず含めます。

悪い例

絶対にしないでください。

  • プロジェクト全体または作業ディレクトリを含む tarball/zipfile にリンクします。（これをやった人が多すぎるため、これは過去のことであり、あなたがしたことについて詳しく知りたいユーザーにとっては役に立ちません）。
  • プロジェクトのプライマリ ソース リポジトリの先頭へのリンク。
  • プロジェクトのソース リポジトリのクローンにリンクします。
    • この場合、作業内容が他の作業と混在しているため、変更の内容を把握するのが難しくなります。
  • GSoC プロジェクト ページへのリンク。
    • それが何であるかはすでに知っています（例: https://summerofcode.withgoogle.com/projects/#1234567890）。

メンター

コントリビューターの適切なコードの送信にご協力ください。これは、最終的な作業提出期間の前に行うことが重要です。

次の点を確認します。

  • 提出物は上記の要件を満たしています。
  • コードがコンパイルされます。
  • 詳細とその理由を記載したドキュメントが用意されています。

GSoC の考え方は、コントリビューターがコードを奪うのではなく、ホストするオープンソース プロジェクトにとって潜在的にコードが有用であることが重要です。