google summer of code
1.0.0
Google Summer of Codeプログラムのリソース。
こんにちは！ STDLIBのGoogle Summer of Code（GSOC）リソースリポジトリへようこそ。
GSOCは、3か月間にわたってオープンソースプロジェクトに貢献するために支払われる機会を提供する新しい貢献者（ 18歳以上）を提供するグローバルプログラムです。貢献者は、オープンソースコミュニティからのメンターの指導の下で、Googleから支払われます。 GSOCは、学習し、新しいスキルを開発し、つながりを構築し、より大きくて頻繁に流通しているチームでの経験を獲得し、あなたの努力を財政的に補償する絶好の機会です。
このリポジトリには、GSOCの申請方法に関する情報と、GSOCプロジェクトの基礎として機能する可能性のある潜在的なアイデアのリストが見つかります。
GSOCの貢献者は、プログラムの過程で350時間（フルタイム相当）、 175時間（パートタイム相当）、または90時間（短時間同等）作業を行うことが期待されています。デフォルトのスケジュールは3か月（12週間）にわたって実行され、長期間にわたって広がる可能性があります。
プログラムの開始日は交渉できません。すべてのGSOC貢献者は、同時にプログラムを開始する必要があります。
STDLIBを使用してGSOCに申請するには、次のことが必要です。
すべてのアプリケーションはGoogleのアプリケーションシステムを通過する必要があり、 GoogleのWebサイトにアプリケーションを送信する必要があることを忘れないでください。 GSOC Webサイトで申請書を送信しない場合、アプリケーションを受け入れることはできません。
GSOCの意図は、新しい貢献者がオープンソースの世界に参加して参加する方法を提供することです。選択され、最終的に成功する可能性が最も高い貢献者は、コミュニティに従事し、GSOCプログラムの期間を超えて関与を継続することを望んでいる人々です。一般に、ほとんどのプロジェクトでは、優れたコミュニティメンバーであることは、優れたコーダーであるよりも重要です。
通信する。コミュニケーションは、おそらく申請プロセスの最も重要な部分です。メンターや他のSTDLIB開発者に相談し、アドバイスを提供するときに聞いて、あなたが提案しているものに彼らのフィードバックを組み込むことで彼らの提案を理解したことを実証します。フィードバックを組み込まないと、成功の可能性が大幅に低下します。
指示を読んでください。提案を送信するときは、常にすべての指示を読んで（そして再読み取り）してください。追求したいプロジェクトに関する情報を含まない履歴書、科学論文、プレゼンテーション、またはその他のファイルを単に提出しないでください。指示に従わないことは、提案の拒否につながることが保証されています。
プロフェッショナルになりなさい。敬意を示し、あなたがメンタリング関係を真剣に受け止めることを実証します。つまり、フィードバックを受け取り、常にSTDLIBコミュニティの各メンバーの時間を評価するときに積極的に聴くことを意味します。コミュニケーションが不十分で、指示に従わないことは、メンターの時間に対する尊敬の欠如と考慮不足を伝えます。また、メンターはプロジェクトの成功とプロジェクトの成功を確保するために必要なプロフェッショナリズムを示さない貢献者と仕事をしたいとは思いません。 STDLIBコミュニティメンバーとしての彼らの個人的な成長。
質問がある場合は、最初に質問がGSOC FAQですでに回答されているかどうかを確認してください。 GSOC FAQに相談した後も質問がある場合は、STDLIB要素チャネルにアクセスできます。
Elementを使用して、最初のプロジェクトのアイデアに関するフィードバックを求めたり、STDLIBコードベースの作業を開始したりするとヘルプを得ることができます。 STDLIBフォーラムで質問がより具体的かつ明確になればなるほど、良い答えを得る可能性が高くなることに注意してください。オープンエンドまたは曖昧な質問は、有用な反応を得ることはほとんどありません。
たとえば、良い質問は、
私はプロジェクトXに興味があり、私は少しの調査をしてきましたが、YとZの問題が関連しているように見えることがわかりました。私の調査結果に基づいて、A、B、およびCはすでに実装されているので、D、E、およびfを達成するプロジェクトを提案することが合理的かどうかを知りたいです。
対照的に、次の質問はオープンエンドであり、曖昧すぎて意味のある反応を求めることができません
プロジェクトXに興味があります。これに取り組むのを手伝ってください。
要素を越えて手を差し伸べるときは、あなたを知ることができるように、自己紹介してください。含めるべきいくつかの有用な情報
GSOCアプリケーションに取り組む前に、アイデアのリストを確認して、興奮するプロジェクトを見つけたかどうかを確認してください。既存のアイデアのリストは、インスピレーションとして機能し、どの方向がstdlibに適しているかを示すために提供されます。
追求したい既存のアイデアを見つけた場合は、最初にそれについて話し合うために、要素チャンネルに連絡してください！既に実装されているものと正確に何をしなければならないかについての最新の情報を取得するために、アプリケーションに取り組む前に、これらのアイデアについて必ず尋ねてください。
アイデアのリストは、次の規則に従ってラベルによって整理されています。
優先度
high ：ロードマップで重要と見なされるアイデア。normal ：緊急ではないが、後でよりも早く持っているといいアイデア。low ：斬新または興味深いアイデアですが、優先リストでは低いアイデアです。困難
1 ：JavaScriptの経験がほとんどない人に適したアイデア。2 ：JavaScriptの実用的な知識を持っている人に適したアイデア。3 ：挑戦的でありながら管理しやすいアイデア。4 ：挑戦的であり、野心的な目標を持っているアイデア。5 ：いくつかの未知のものを実装するのが難しいと思われるアイデア。テクノロジー
javascript ：JavaScriptでのプログラミングを含むアイデア。少なくともいくつかのJavaScriptがすべてのアイデアに必要である可能性があります。nodejs ：node.jsで開発する必要があるアイデアnode.jsはテスト、ベンチマーク、およびローカル開発のデフォルト環境であるため、Node.jsを使用することは、すべてではないにしても、ほとんどのアイデアに必要である可能性があります。c ：Cでのプログラミングを含むアイデアは、Node.jsネイティブアドオンに必要です。fortran ：Fortranでのプログラミングを含むアイデア。これは、Blas/Lapack Bindingsの作業に必要です。html/css ：HTMLとCSSの使用を含むアイデア（例：フロントエンドアプリケーションの構築の場合）。jsx/react ：React JSXを使用したプログラミングを含むアイデア（たとえば、STDLIB Webサイトで作業している場合）。native addons ：node.jsネイティブアドオンの開発を含むアイデア。typescript ：TypeScriptでのプログラミングを含むアイデア。優先順位、難易度、テクノロジー、トピックの領域は、アイデアが受け入れられる可能性には関係ありません。すべてのアイデアも同様に優れており、受け入れられる可能性は、アプリケーションの品質のみに依存しています。
プロジェクトの長さ
GSOCでは、 90時間175時間350時間の3つの異なるプロジェクトの長さが許可されています。それぞれのアイデアは、アイデアが90、175、または350時間に適しているかどうかを示す必要があります。
場合によっては、何ができるかのアイデアを拡張することにより、175時間のプロジェクトを350時間のプロジェクトに拡張できる場合があります。同様に、場合によっては、350時間のプロジェクトを175時間のプロジェクトに短縮することができます。アイデアの一部のみを実装し、残りを将来のプロジェクトに残すことができます。どちらの場合でも、プロジェクトの長さを調整する場合は、要素チャネルに連絡して最初に話し合ってください。
独自のアイデアを提出したい場合は、それも大歓迎です。最初にSTDLIBメンターにあなたのアイデアを提案してください！手を差し伸べた後、アイデアが既に実装されているかどうか、アイデアがGSOCプログラムの持続時間を続けるのに十分な作業を伴う場合、GSOC中に有意義に追求するためにアイデアがあまりにも多くの作業を必要とする場合、そしてアイデアはstdlibの範囲内です。未承諾の、発見されていないアイデアは、受け入れられる可能性が低くなります。
あなたにとって最高のプロジェクトは、あなたが最も興味があり、知識のあるプロジェクトです。興奮と適性は、成功したプロジェクトの2つの重要な要素であり、プロジェクトを完了するまでのコミットメントと能力を確保するのに役立ちます。ですから、あなたが特に情熱を持っていることがあり、Stdlibの範囲と目標と一致すると信じているなら、私たちはあなたのピッチを聞いてうれしいです！
私たちの要素チャネルで私たちと話し合い、あなたのアイデアを提出するための承認を受け取った後、 Idea Issueテンプレートを使用してあなたのアイデアを説明する問題を開いてください。
書面による提案に加えて、すべてのGSOC申請者にパッチを書いて、メインSTDLIBリポジトリにマージすることが要求されます。
提案をレビューする際に、パッチをSTDLIBに強く検討します。 1つ以上のパッチを提出することは、提案に含まれていることを実行できることを実証するための最良の機会です。
パッチを提出するには、
STDLIBリポジトリをフォークします。
プラットフォームをセットアップしてSTDLIBを開発します（例：GITをインストールし、フォークリポジトリをクローンし、セットアップしてリモートアップストリームSTDLIBリポジトリを追跡し、依存関係をインストールし、ローカル開発環境を初期化します）。私たちの貢献ガイドでは、Gitのセットアップをお勧めします。
GitHub Webエディターを介してパッチを送信しないでください。プロジェクトを受け入れた場合は、GITの使用方法を学び、STDLIBをローカルに開発する方法を学ぶ必要があります。今すぐGITを使用してSTDLIBを開発するために時間をかけて、成功の可能性を高め、STDLIBがあなたにぴったりかどうかを判断するのに役立ちます。
STDLIBで、機能しない、改善が必要である、または有用な追加になるものを見つけます。インスピレーションが必要な場合は、初めての貢献者に適した問題のリストに問題を自由に修正してください。
問題に加えて、コードベースでFIXMEまたはTODOを検索します。 git grep "TODO"でコマンドラインのgrep使用できます。
また、Stdlib Replで遊んで、修正が必要な、または実装できるものを見つけることもできます。
何かを見つけたら、問題がまだ存在しない場合は、問題と提案されたソリューションを説明するSTDLIB Issueトラッカーに問題を開きます。
プロジェクトがJavaScript（例えば、CまたはFortran）以外の言語を使用する場合、その言語に熟練していることを示すために、その言語を使用するパッチも提出する必要があります。
パッチはドキュメントではなく、コード関連である必要があることに注意してください。ドキュメントの修正はいつでも歓迎されますが、パッチの要件を満たしていません。
さらに、パッチの要件を満たすために、パッチが提案されたプロジェクトに関連する必要はないことに注意してください。動作するコードに精通するために、同じまたは類似のコードで関連するバグを修正しようとするかもしれませんが、これはパッチ要件の一部ではありません。
GitHubでプルリクエストを作成して、ピアレビュー用のパッチを公開します。これは、これがあなたのコードを確認してフィードバックを提供する最も簡単な方法であり、私たちが取り組んでいる貢献者に期待するものであるため、githubを介してプルリクエストを送信する必要があります（問題にパッチされたファイルを貼り付けます） GSOCプロジェクト。
パッチ要件を満たすために、正常にレビューおよびマージされたパッチを提出する必要があります。パッチを正常に統合せずにアプリケーションを考慮しません。
成功したパッチは、あなたの技術的能力とSTDLIBコミュニティと対話する能力を示しています。
Githubでプルリクエストを作成すると、Stdlibレビュアーはコードを確認し、変更を要求する可能性があります。これらの変更に対処する必要があります。
開発およびフィードバックプロセスを通して、予想される動作を検証するために、常に単体テストをローカルで実行する必要があります。
レビュー中は、レビュアーに我慢してください。 GSOCのため、レビューする多くのプルリクエストがある可能性があり、特にアプリケーションの締め切りの近くで提出されている場合、すべてのプルリクエストをレビューするのが遅い場合があります。申請プロセスの早い段階でプルリクエストを提出することを強くお勧めします。
アプリケーションの締め切りが優先される前にパッチをマージしている間、パッチがまだレビュー中である場合、それは問題ありません。重要なのは、受け入れ締め切りの前にパッチがマージされることです。
受け入れの締め切り前にパッチを統合するために、私たちのフィードバックに十分なタイムリーな方法で応答するのはあなた次第です。
アプリケーションでは、これまでに統合されていない作業を含め、STDLIBへの貢献の簡単な要約を提供してください。これは、プルリクエストのリストと、各プルリクエストがマージされている、閉じられている、または開いているかどうかの兆候である必要があります。プルリクエストの外で多大な貢献をした場合（例えば、他の誰かのプルリクエストを確認する）、それもリストすることができます。
いかなる形でも盗作を容認しないことに注意してください。アプリケーションを開発するときは、自分の言葉で書くことでそうしてください。
他の応募者は、同じアイデアの提案について公に議論し、提出することができますが、彼らの提案からコンテンツを持ち上げるべきではありません。あなたは、あなたが適切だと思われるタイムラインに従って、プロジェクトを成功させるための最良の行動方針であると思うものを書いて提案する必要があります。
アプリケーションに盗用されたコンテンツが含まれていることを検出した場合、レビューなしでアプリケーションを拒否します。
さらに、多くの貢献者にとって、英語はあなたの第一言語ではないかもしれないことを認識していますが、LLMS（たとえば、ChatGPTなど）の使用を避けてください。通常、個人がアプリケーションのコンテンツを自動生成するためにLLMSに頼っていること（およびコードの貢献！）を伝えることができます。これが私たちに合図しているのは、思慮深いアプリケーションを書くのに時間をかけることができず、おそらくあなたがそうすることはないということです。私たちの信頼を獲得することができます。
最高の候補者は、思慮深い人、細部に細心の注意を払う人、そして熱心で学びたい人です。
このドキュメントは、大量に借用しています
このドキュメントは、Creative Commons Attribution-Sharealike 4.0 International（CC BY-SA 4.0）ライセンスの下で再利用できます。
