google summer of code下載 - google summer of code源代碼下載

google summer of code

其他源碼

1.0.0

下載

Google Summer代碼

Google Summer代碼計劃的資源。

你好！歡迎來到Stdlib的Google Summer Code（GSOC）資源存儲庫。

GSOC是一項全球計劃，為在三個月內為開源項目貢獻的新貢獻者（年齡在18歲以上）提供了一個機會。 Google向貢獻者支付了在開源社區的導師的指導下工作。 GSOC是學習，發展新技能，建立聯繫，獲得與大型且經常分配的團隊合作的經驗，並在財務上為您的努力所付出的努力的絕佳機會。

在此存儲庫中，您將找到有關如何申請GSOC的信息以及可以作為GSOC項目的基礎的潛在想法列表。

時間承諾

在計劃過程中，GSOC貢獻者預計將工作350小時（全職等效）， 175小時（兼職等效）或90小時（短期等效）。默認時間表在3個月（12週）中運行，並有可能在更長的時間內分佈。

程序開始日期不可談判。所有GSOC貢獻者都必須同時開始該計劃。

申請過程

為了使用STDLIB申請GSOC，您必須：

閱讀GSOC撰稿人指南。
完整閱讀此存儲庫中的資源。
訪問主要的STDLIB項目存儲庫，並熟悉源代碼，項目組織和一般約定。
閱讀並理解行為準則。
請諮詢項目問題跟踪器，以查找正在進行的Stdlib討論。
閱讀詳細信息指南，以了解如何開始開發stdlib。
如果您還沒有一個帳戶，請創建一個GitHub帳戶。
至少將一個補丁提交給stdlib。所有不伴隨至少一個att stlib補丁的應用程序將被拒絕。下面描述了有關如何滿足補丁要求的說明。
查看我們的想法列表，以查看您是否找到使您興奮的項目。如果您想提交自己的想法，那很好；只需確保首先向Stdlib指導您的想法即可！未經請求的，無見的想法不太可能被接受。
開發您的應用程序，確保遵循應用模板。我們強烈建議開開一個使用應用程序問題模板來描述您項目的問題。這樣做可以使不在GSOC網站上的個人查看您的應用程序並提供反饋。
申請截止日期為4月2日，UTC。強烈建議您在截止日期之前很好地提交申請。 Google出於任何原因不會接受延遲申請。您將能夠編輯您的應用程序，直到截止日期為止，因此，如果您有草稿，請提早提交並繼續按時間允許進行更新。

請記住，所有應用程序都必須遍歷Google的應用程序系統，並且您必須在Google的網站上提交應用程序。如果您不在GSOC網站上提交申請，我們將無法接受您的申請。

尖端

GSOC的目的是為新貢獻者加入和參與開源世界提供一種方式。最有可能被選中的貢獻者是那些從事社區並希望在GSOC計劃期間繼續參與的人。總的來說，對於大多數項目而言，成為一個好的社區成員比成為一個好的編碼員更重要。

交流。溝通可能是申請過程中最重要的部分。與導師和其他STDLIB開發人員交談，在提供建議時聆聽，並證明您通過將反饋納入您的建議來理解他們的建議。未能合併反饋會大大降低您的成功機會。

閱讀說明。提交建議時，請務必閱讀（並重新閱讀）所有說明。不要簡單地提交簡歷，科學論文，演示文稿或其他不包含有關您要進行的項目的信息的文件。未能遵循指示可以保證導致提案拒絕。

保持專業。表達尊重並證明您將認真對待指導關係。這意味著當您收到反饋並始終評估Stdlib社區中每個成員的時間時，積極傾聽。溝通不良和未能閱讀和遵守指示表達缺乏尊重和缺乏對導師時間的考慮，沒有任何導師希望與一位貢獻者合作，他們沒有表現出必要的專業精神來確保其項目的成功和他們作為Stdlib社區成員的個人成長。

問題

如果您有疑問，請首先檢查GSOC常見問題中是否已經回答了問題。如果您在諮詢GSOC常見問題解答後仍然有疑問，則可以在Stdlib元素頻道上聯繫。

您可以使用元素來徵求初始項目創意的反饋，並在開始使用STDLIB代碼庫時獲得幫助。請記住，在STDLIB論壇上越具體並清除您的問題，您就越有可能獲得一個好的答案。開放式或模糊的問題不太可能得到有用的回應。

例如，一個好問題可能是

我對X項目感興趣，並且我已經進行了一些研究，發現Y和Z似乎相關的問題。根據我的發現，已經實施了A，B和C，因此我想知道提出一個可以實現D，E和F的項目是否合理。

相反，以下問題太開放了，太模糊了，無法徵求有意義的回應

我對X項目感興趣。請幫助我對此進行努力。

接觸元素時，請務必介紹自己，以便我們了解您。一些有用的信息要包括

對JavaScript的熟悉程度（包括多年的編程和以前的項目）。
教育水平（高中 /大學 /博士）。
任何特定的專業知識（例如統計，數值算法）。
任何特定的興趣（例如，機器學習，自然語言處理，異步JavaScript，用戶界面設計等）。
熟悉stdlib（例如，您使用過stdlib嗎？）。
其他可能的相關信息（例如，地理位置，母語等）。

項目想法

在處理GSOC應用程序之前，請查看我們的想法列表，以查看您是否找到使您興奮的項目。提供了現有想法的清單，以作為靈感，並指出哪些方向可能對stdlib有好處。

如果您確實找到了您想追求的現有想法，請務必在我們的元素頻道中與我們聯繫以首先討論！在申請申請之前，請務必詢問這些想法，以獲取有關已經實施的內容以及確切必須做什麼的最新信息。

根據以下慣例，標籤組織了思想列表：

優先事項

high ：在我們的路線圖中被認為很重要的想法。
normal ：不緊急的想法很早就可以很快。
low ：新穎或有趣的想法，但在我們的優先列表上很低。

困難

1 ：適合幾乎沒有JavaScript經驗的人。
2 ：一個適合具有JavaScript工作知識的人的想法。
3 ：一個可能具有挑戰性但易於管理的想法。
4 ：一個可能具有挑戰性並具有雄心勃勃的目標的想法。
5 ：一個可能很難用幾個未知數實施的想法。

技術

javascript ：涉及JavaScript編程的想法。至少所有想法都可能需要一些JavaScript。
nodejs ：需要使用node.js開發的想法。大多數（如果不是全部）想法可能需要使用node.js，因為node.js是測試，基準測試和本地開發的默認環境。
c ：一個涉及編程的想法。
fortran ：涉及在Fortran中編程的想法。這是從事Blas/Lapack綁定所必需的。
html/css ：涉及使用HTML和CSS的想法（例如，如果構建前端應用程序）。
jsx/react ：涉及與React JSX編程的想法（例如，如果在Stdlib網站上工作）。
native addons ：涉及開發node.js本機附加組件的想法。
typescript ：涉及在打字稿中編程的想法。

優先，難度，技術和主題領域與接受想法的機會無關。所有想法都同樣好，並且您被接受的機會僅取決於應用程序的質量。

項目長度

GSOC允許三個不同的項目長度： 90小時， 175小時350小時。每個想法都必須表明這個想法是否更適合90、175或350小時。

在某些情況下，我們可以通過擴展可以做什麼的想法來將175小時的項目擴展到一個350小時的項目。同樣，在某些情況下，只有一部分想法並將其餘的用於將來的項目，就可以將350小時的項目縮短為175小時的項目。無論哪種情況，如果您想調整項目長度，請確保在我們的元素頻道中與我們聯繫以首先討論！

你自己的想法

如果您想提交自己的想法，這也是歡迎的；只需確保首先向Stdlib指導您的想法即可！聯繫後，我們將通知您是否已經實施了這個想法，該想法是否需要足夠的工作來持續GSOC計劃的持續時間，如果這個想法需要太多工作以在GSOC期間有意義地追求想法在stdlib的範圍內。未經請求的，無見的想法不太可能被接受。

最好的項目是您最感興趣和知識淵博的項目。興奮和能力是成功項目的兩個關鍵要素，並有助於確保您的承諾和能力看到項目完成。因此，如果您對某些東西特別熱衷，並且您相信與Stdlib的範圍和目標保持一致，那麼我們很高興聽到您的音調！

在與我們的元素渠道討論並獲得批准以提交您的想法之後，請打開一個問題，該問題使用Ideas問題模板來描述您的想法。

補丁要求

除書面建議外，我們還要求每個GSOC申請人編寫一個補丁，並將其合併到主STDLIB存儲庫中。

在審查您的提案時，我們將您的補丁進行了大量考慮。提交一個或多個補丁是您最好的機會證明您有能力做建議中包含的事情。

提交補丁，

分叉stdlib存儲庫。
設置您的平台開發stdlib（例如，安裝git，克隆您的叉子存儲庫，將其設置為跟踪遠程上游stdlib存儲庫，安裝依賴關係並初始化本地開發環境）。我們的貢獻指南使您通過設置GIT和詳細說明我們首選的開發方式。
請不要通過GitHub Web編輯器提交補丁。如果您的項目被接受，您將需要學習如何使用Git並在本地開發STDLIB。現在花點時間使用git並在本地開發stdlib可以增加成功的機會，並幫助您確定stdlib是否適合您。
在stdlib中找到不起作用，需要改進或將是有用的補充的東西。如果您需要靈感，請隨時解決問題列表中的任何問題，這些問題對第一次貢獻者有益。
除了問題外，在代碼庫中搜索FIXME或TODO 。您可以使用git grep "TODO"中的命令行中的grep 。
您也可以在stdlib repl中玩耍，並找到需要修復或可以實現的東西。
一旦找到某些問題，如果不存在問題，請在stdlib問題跟踪器上打開一個問題，描述了該問題和您提出的解決方案。
如果您的項目將使用JavaScript以外的其他語言（例如，C或Fortran），則應提交使用該語言的補丁，以證明您精通該語言。
請注意，您的補丁必須與代碼相關，而不是文檔。儘管始終歡迎文檔修復程序，但它們無法滿足補丁要求。
進一步指出，您的補丁不需要與您建議的項目相關，以滿足補丁要求。為了熟悉您要處理的代碼，您可能希望嘗試在相同或相似的代碼中修復相關的錯誤，但這不是補丁要求的一部分。
通過在GitHub上創建拉動請求來發布您的補丁以進行同行評審。您必須通過github提交拉動請求（例如，在問題上粘貼修補文件），因為這是我們查看您的代碼並提供反饋的最簡單方法，這是我們期望的是從事工作的貢獻者GSOC項目。
您必須提交成功審核和合併以滿足補丁要求的補丁程序。如果沒有成功合併的補丁，我們不會考慮應用程序。
成功的補丁展示了您的技術水平和與Stdlib社區互動的能力。
在GitHub上創建了拉動請求後，STDLIB審閱者將查看您的代碼並可能更改。您應該解決這些更改。
在整個開發和反饋過程中，您應始終在本地運行單元測試以驗證預期的行為。
在審核期間，請耐心等待審稿人。由於GSOC，可能會有許多拉的請求進行審查，並且我們可能會慢慢審查所有拉的請求，尤其是如果它們靠近申請截止日期。強烈建議您在申請過程中儘早提交拉動請求，以便在申請截止日期之前為您提供合併補丁的最佳機會。
在首選應用程序截止日期之前合併補丁的同時，如果您的補丁仍在審核中，那很好。至關重要的是，您的補丁在接受截止日期之前合併。
您必須及時回复我們的反饋，以便在接受截止日期之前將補丁合併。
在您的申請中，請簡要摘要迄今為止您對STDLIB的貢獻，包括尚未合併的工作。這應該是拉的請求列表，並指出是否合併，關閉或仍在打開每個拉請請求。如果您在拉動請求之外做出了重大貢獻（例如，審查別人的拉請求），則可以列出。