google summer of code
1.0.0
Ressourcen für das Google Summer of Code -Programm.
Hallo! Und willkommen im Google Summer of Code (GSOC) -Ressource -Repository von STDLIB.
GSOC ist ein globales Programm, das neue Mitwirkende (die 18 Jahre oder älter sind) die Möglichkeit bietet, über einen Zeitraum von drei Monaten einen Beitrag zu einem Open -Source -Projekt zu erhalten. Mitwirkenden werden von Google bezahlt, um unter der Anleitung von Mentoren einer Open -Source -Community zu arbeiten. GSOC ist eine großartige Gelegenheit, neue Fähigkeiten zu entwickeln, Verbindungen aufzubauen, Erfahrungen mit einem größeren und oft verteilten Team zu sammeln und für Ihre Bemühungen finanziell kompensiert zu werden.
In diesem Repository finden Sie Informationen, wie Sie sich für GSOC bewerben können, und eine Liste potenzieller Ideen, die als Grundlage für ein GSOC -Projekt dienen könnten.
Es wird erwartet, dass GSOC-Mitarbeiter im Laufe des Programms entweder 350 Stunden (Vollzeitäquivalent), 175 Stunden (Teilzeitäquivalent) oder 90 Stunden (kurzzeitäquivalent) funktionieren. Der Standardplan läuft über 3 Monate (12 Wochen) und kann möglicherweise über einen längeren Zeitraum verteilt werden.
Das Programmstartdatum ist nicht verhandelbar . Alle GSOC -Mitwirkenden müssen das Programm gleichzeitig beginnen.
Um sich bei STDLIB bei GSOC zu bewerben, müssen Sie:
Bitte denken Sie daran, dass alle Anwendungen das Anwendungssystem von Google durchlaufen müssen und Sie Ihre Bewerbung auf der Google -Website einreichen müssen . Wenn Sie Ihre Bewerbung nicht auf der GSOC -Website einreichen, können wir Ihre Bewerbung nicht annehmen.
Die Absicht von GSOC ist es, neuen Mitwirkenden die Möglichkeit zu geben, sich an der Welt der Open Source zu beteiligen und sie teilzunehmen. Die Mitwirkenden, die am wahrscheinlichsten ausgewählt werden und letztendlich erfolgreich sind, sind diejenigen, die in der Gemeinde beschäftigt sind und hoffen, ihre Beteiligung über die Dauer des GSOC -Programms hinaus fortzusetzen. Im Allgemeinen ist es für die meisten Projekte wichtiger, ein gutes Community -Mitglied zu sein, als ein guter Coder zu sein .
Kommunizieren. Kommunikation ist wahrscheinlich der wichtigste Teil des Bewerbungsprozesses. Sprechen Sie mit Mentoren und anderen STDLIB -Entwicklern, hören Sie zu, wenn sie Ratschläge anbieten, und zeigen Sie, dass Sie ihre Vorschläge verstanden haben, indem Sie ihr Feedback in das einbeziehen, was Sie vorschlagen. Das Versäumnis, Feedback zu integrieren, senkt Ihre Erfolgschance erheblich .
Lesen Sie die Anweisungen. Lesen Sie immer alle Anweisungen, wenn Sie Vorschläge einreichen. Senden Sie nicht einfach einen Lebenslauf, ein wissenschaftliches Papier, eine Präsentation oder eine andere Datei, die keine Informationen zu dem Projekt enthält, das Sie verfolgen möchten. Wenn Anweisungen nicht befolgt werden, wird dies zu einer Ablehnung des Vorschlags führen.
Professionell sein. Zeigen Sie Respekt und zeigen Sie, dass Sie die Mentoring -Beziehung ernst nehmen werden. Das bedeutet aktiv zuzuhören, wenn Sie Feedback erhalten und die Zeit jedes Mitglieds in der STDLIB -Community immer bewerten. Schlechte Kommunikation und das Versäumnis, Anweisungen zu lesen und zu befolgen Ihr persönliches Wachstum als Stdlib -Community -Mitglied.
Wenn Sie Fragen haben, überprüfen Sie zunächst, ob die Fragen bereits in den GSOC -FAQ beantwortet wurden. Wenn Sie nach der Konsultation der GSOC -FAQ noch eine Frage haben, können Sie sich auf dem STDLIB -Elementkanal wenden.
Sie können Element verwenden, um Feedback zu ersten Projektideen einzuholen und Hilfe zu erhalten, wenn Sie mit der STDLIB -Codebasis arbeiten. Denken Sie daran, dass je mehr und klarer und klarer Ihre Fragen in STDLIB -Foren sind, desto wahrscheinlicher ist es, dass Sie eine gute Antwort erhalten. Es ist unwahrscheinlich, dass eine offene oder vage Frage eine nützliche Antwort erhält.
Zum Beispiel könnte eine gute Frage etwas im Sinne von sein
Ich interessiere mich für Projekt X und habe ein bisschen recherchiert und festgestellt, dass Themen y und z verbunden sind. Basierend auf meinen Erkenntnissen sind A, B und C bereits implementiert. Ich möchte also wissen, ob es vernünftig wäre, ein Projekt vorzuschlagen, das D, E und F erreichen würde.
Im Gegensatz dazu ist die folgende Frage zu offen und zu vage, um eine sinnvolle Antwort zu bitten
Ich interessiere mich für Projekt X. Bitte helfen Sie mir, daran zu arbeiten.
Wenn Sie sich über das Element wenden, stellen Sie sich unbedingt vor, damit wir Sie kennenlernen können. Einige nützliche Informationen, die enthalten sind
Bevor Sie an Ihrer GSOC -Bewerbung arbeiten, überprüfen Sie bitte unsere Ideenliste, um festzustellen, ob Sie ein Projekt finden, das Sie begeistert. Die Liste der vorhandenen Ideen soll als Inspiration dienen und angeben, welche Richtungen für STDLIB gut sein können.
Wenn Sie eine vorhandene Idee finden, die Sie verfolgen möchten, kontaktieren Sie uns bitte in unserem Element -Kanal, um sie zuerst zu besprechen! Fragen Sie immer unbedingt nach diesen Ideen, bevor Sie an der Anwendung arbeiten, um die neuesten Informationen darüber zu erhalten, was bereits implementiert ist und was genau getan werden muss.
Die Liste der Ideen wird nach den folgenden Konventionen nach Etiketten organisiert:
Priorität
high : Ideen, die in unserer Roadmap als wichtig angesehen werden.normal : Ideen, die nicht dringend sind, aber es wären eher früher als später zu haben.low : Ideen, die neu oder interessant sind, aber auf unserer Prioritätsliste niedrig sind.Schwierigkeit
1 : Eine Idee, die für jemanden mit wenig bis gar keiner JavaScript -Erfahrung geeignet ist.2 : Eine Idee, die für jemanden geeignet ist, der über JavaScript kennt.3 : Eine Idee, die wahrscheinlich herausfordernd, aber überschaubar ist.4 : Eine Idee, die wahrscheinlich herausfordernd ist und ehrgeizige Ziele hat.5 : Eine Idee, die mit mehreren Unbekannten schwierig zu implementieren ist.Technologie
javascript : Eine Idee, die das Programmieren in JavaScript beinhaltet. Zumindest für alle Ideen ist wahrscheinlich ein JavaScript erforderlich.nodejs : Eine Idee, die sich mit node.js.js entwickeln muss. Die Arbeit mit node.js ist wahrscheinlich für die meisten, wenn nicht alle Ideen, wie Node.js die Standardumgebung für Tests, Benchmarking und lokale Entwicklung ist.c : Eine Idee, die die Programmierung in C beinhaltet. Dies ist für native Node.js-Add-Ons erforderlich.fortran : Eine Idee, die das Programmieren in Forran beinhaltet. Dies ist für die Arbeit an BLAS/LAPACK -Bindungen erforderlich.html/css : Eine Idee, bei der HTML und CSS verwendet werden (z. B. beim Erstellen einer Frontend -Anwendung).jsx/react : Eine Idee, die mit der Programmierung mit React JSX (z. B. bei der Arbeit auf der STDLIB -Website) beinhaltet.native addons : Eine Idee, die die Entwicklung von Node.js native Add-Ons beinhaltet.typescript : Eine Idee, die die Programmierung in Typenkript beinhaltet.Priorität, Schwierigkeit, Technologie und Themenbereich haben keinen Einfluss auf die Wahrscheinlichkeit, dass eine Idee akzeptiert wird. Alle Ideen sind gleich gut, und Ihre Chancen, akzeptiert zu werden, hängen ausschließlich von der Qualität Ihrer Anwendung ab.
Projektlänge
GSOC ermöglicht drei verschiedene Projektlängen: 90 Stunden, 175 Stunden und 350 Stunden. Jede Idee muss angeben, ob die Idee für 90, 175 oder 350 Stunden besser passt.
In einigen Fällen können wir möglicherweise ein 175 -Stunden -Projekt auf ein 350 -stündiges Projekt verlängern, indem wir die Ideen dessen erweitern, was getan werden kann. In einigen Fällen kann in einigen Fällen ein 350 -stündiges Projekt auf ein 175 -Stunden -Projekt verkürzt werden, indem nur einen Teil einer Idee umgesetzt und der Rest für ein zukünftiges Projekt verlässt. Wenn Sie die Projektlänge anpassen möchten, kontaktieren Sie uns bitte in unserem Elementkanal, um sie zuerst zu besprechen!
Wenn Sie Ihre eigene Idee einreichen möchten, ist das auch willkommen. Schlagen Sie zuerst die STDLIB -Mentoren vor! Nachdem wir uns nachgegriffen haben, informieren wir Sie, ob die Idee bereits implementiert wurde, wenn die Idee genügend Arbeit beinhaltet, um die Dauer des GSOC -Programms zu halten, wenn die Idee zu viel Arbeit erfordert, um während des GSOC sinnvoll verfolgt zu werden, und ob die Die Idee liegt im Rahmen von STDLIB. Unaufgeforderte, undisßen Ideen werden weniger wahrscheinlich akzeptiert.
Das beste Projekt für Sie ist das, an dem Sie am meisten interessiert sind und sich kennenlernen. Aufregung und Eignung sind zwei wichtige Inhaltsstoffe eines erfolgreichen Projekts und tragen dazu bei, dass Sie Ihr Engagement und die Fähigkeit sicherstellen, ein Projekt bis zum Abschluss zu sehen. Wenn es also etwas gibt, an dem Sie besonders leidenschaftlich sind und das Sie glauben, dass Sie sich mit dem Umfang und den Zielen von STDLIB anpassen, würden wir uns freuen, Ihr Pitch zu hören!
Nachdem Sie mit uns in unserem Elementkanal besprochen und die Genehmigung erhalten haben, Ihre Idee einzureichen, öffnen Sie bitte ein Problem, das Ihre Idee mit der Ideenproblemvorlage beschreibt.
Zusätzlich zu dem schriftlichen Vorschlag verlangen jeder GSOC -Bewerber, dass er einen Patch schreiben und in das Haupt -STDLIB -Repository zusammengeführt wird.
Wir nehmen Ihre Patches nach STDLIB in eine starke Überprüfung bei der Überprüfung Ihres Vorschlags. Das Einreichen eines oder mehrere Patches ist die beste Gelegenheit zu demonstrieren, dass Sie in der Lage sind, das zu tun, was in Ihrem Vorschlag enthalten ist.
Einen Patch einreichen,
Geben Sie das STDLIB -Repository auf.
Richten Sie Ihre Plattform ein, um STDLIB zu entwickeln (z. B. Git installieren, Ihr Forked -Repository klonen, das Remote -Upstream -STDLIB -Repository verfolgen, Abhängigkeiten installieren und Ihre lokale Entwicklungsumgebung initialisieren). Unser beitragender Leitfaden führt Sie durch die Einrichtung und Einzelheiten unserer bevorzugten Entwicklungsweise.
Bitte senden Sie keine Patches über den GitHub Web Editor. Sie müssen lernen, wie Sie Git verwenden und STDLIB lokal entwickeln, wenn Ihr Projekt akzeptiert wird. Nehmen Sie sich jetzt die Zeit, Git zu verwenden und STDLIB lokal zu entwickeln, und Sie helfen Ihnen, zu entscheiden, ob STDLIB gut zu Ihnen passt.
Finden Sie etwas in STDLIB, das nicht funktioniert, verbessert werden muss oder wäre eine nützliche Ergänzung. Wenn Sie Inspiration benötigen, können Sie alle Probleme in der Liste der Probleme beheben, die zum ersten Mal gut Mitwirkenden sind.
Suchen Sie zusätzlich zu den Problemen nach FIXME oder TODO in der Codebasis. Sie können grep aus der Befehlszeile mit git grep "TODO" verwenden.
Sie können auch in der STDLIB -Replikation herumspielen und etwas finden, das repariert werden muss oder implementiert werden kann.
Sobald Sie etwas gefunden haben, öffnen Sie, wenn ein Problem noch nicht vorhanden ist, ein Problem im STDLIB -Issue -Tracker, der das Problem und Ihre vorgeschlagene Lösung beschreibt.
Wenn Ihr Projekt eine andere Sprache als JavaScript (z. B. C oder FORTRAN) verwendet, sollten Sie auch Patches einreichen, die diese Sprache verwenden, um zu demonstrieren, dass Sie diese Sprache beherrschen.
Beachten Sie, dass Ihr Patch mit Code bezogen werden muss , nicht die Dokumentation. Während Dokumentationsfixes immer willkommen sind, erfüllen sie die Patch -Anforderung nicht .
Und weiter beachten Sie, dass Ihr Patch nicht mit Ihrem vorgeschlagenen Projekt in Verbindung gebracht werden muss, um die Patch -Anforderung zu erfüllen. Um sich mit dem Code vertraut zu machen, für den Sie arbeiten würden, möchten Sie möglicherweise versuchen, einen relevanten Fehler im selben oder ähnlichen Code zu beheben. Dies ist jedoch nicht Teil der Patch -Anforderung.
Veröffentlichen Sie Ihren Patch für Peer Review, indem Sie eine Pull -Anfrage auf GitHub erstellen. Sie müssen Ihre Pull -Anfrage über Github einreichen (im Gegensatz zu beispielsweise das Einfügen einer gepatchteten Datei zu einem Problem), da dies der einfachste Weg ist, Ihren Code zu überprüfen und Feedback zu geben, und wir erwarten von einem Mitwirkenden, der an einem arbeitet, an einem zu arbeiten GSOC -Projekt.
Sie müssen einen Patch einreichen, der erfolgreich überprüft und zusammengeführt wird, um die Patch -Anforderung zu erfüllen. Wir berücksichtigen keine Anwendungen ohne erfolgreich zusammengefügte Patches.
Ein erfolgreicher Patch zeigt Ihre technischen Kenntnisse und Ihre Fähigkeit, mit der STDLIB -Community zu interagieren.
Sobald Sie eine Pull -Anfrage für GitHub erstellt haben, überprüfen die STDLIB -Gutachter Ihren Code und fordern möglicherweise Änderungen an. Sie sollten diese Änderungen angehen.
Während des gesamten Entwicklungs- und Feedback -Prozesses sollten Sie immer lokale Unit -Tests durchführen, um das erwartete Verhalten zu überprüfen.
Bitte machen Sie während der Überprüfung geduldig mit Rezensenten. Aufgrund von GSOC gibt es möglicherweise eine Reihe von Pull -Anfragen zur Überprüfung, und wir können nur langsam alle Pull -Anfragen überprüfen, insbesondere wenn sie in der Nähe der Bewerbungsfrist eingereicht werden. Sie werden nachdrücklich aufgefordert, Ihre Pull -Anfragen frühzeitig im Bewerbungsprozess einzureichen, um sich die beste Chance zu geben, vor der Bewerbungsfrist einen zusammengeführten Patch zu haben.
Wenn ein Patch vor der Bewerbungsfrist verschmolzen wird, ist dies in Ordnung, wenn Ihr Patch noch überprüft wird. Wichtig ist, dass Ihr Patch vor Abnahme der Akzeptanzabschluss verschmolzen wird.
Es liegt an Ihnen, auf unser Feedback rechtzeitig genug zu reagieren, damit Ihr Patch vor Ablauf der Akzeptanz fusioniert wird.
Bitte geben Sie in Ihrer Bewerbung eine kurze Zusammenfassung Ihrer bisherigen Beiträge zu STDLIB an, einschließlich der noch nicht verschmolzenen Arbeiten. Dies sollte eine Liste von Pull -Anfragen und ein Hinweis darauf sein, ob jede Zuganfrage zusammengeführt, geschlossen oder noch geöffnet wird. Wenn Sie erhebliche Beiträge außerhalb Ihrer Pull -Anfragen geleistet haben (z. B. die Überprüfung der Pull -Anfrage eines anderen), können Sie dies auch auflisten.
Bitte beachten Sie, dass wir Plagiate in keiner Form tolerieren werden. Wenn Sie Ihre Bewerbung entwickeln, schreiben Sie dies, indem Sie in Ihren eigenen Worten schreiben .
Während andere Bewerber öffentlich öffentlich diskutieren und Vorschläge für dieselbe Idee einreichen können, sollten Sie Inhalte nicht von ihren Vorschlägen heben. Sie sollten schreiben und vorschlagen, was Sie für die beste Vorgehensweise für ein erfolgreiches Projekt nach einer Zeitleiste für angemessen halten.
Wenn wir feststellen, dass Ihre Anwendung plagiierte Inhalte enthält, lehnen wir Ihre Bewerbung ohne Überprüfung ab.
Obwohl wir erkennen, dass für viele Mitwirkende Englisch möglicherweise nicht Ihre Muttersprache ist, vermeiden Sie bitte die Verwendung von LLMs (z. B. Chatgpt usw.). Wir können normalerweise erkennen, wann sich Einzelpersonen auf LLMs verlassen, um Anwendungsinhalte automatisch generieren (und Codebeiträge!), Und was diese Signale für uns signalisiert, dass Sie sich nicht die Mühe machen können, sich die Zeit zu nehmen, eine nachdenkliche Bewerbung zu schreiben, und dass Sie wahrscheinlich nicht sein werden in der Lage, unser Vertrauen zu verdienen.
Die besten Kandidaten sind diejenigen, die nachdenklich sind, die genau auf Details achten und bereit und bereit sind zu lernen.
Dieses Dokument leiht sich stark von
Dieses Dokument kann im Rahmen einer Creative Commons Attribution-Sharealike 4.0 International (CC BY-SA 4.0) -Lizenz wiederverwendet werden.
