google summer of code
1.0.0
Ressources pour le programme Google Summer of Code.
Bonjour! Et bienvenue dans le référentiel de ressources Google Summer of Code (GSOC) de STDLIB.
Le GSOC est un programme mondial qui offre aux nouveaux contributeurs (qui ont 18 ans ou plus) l'occasion d'être payé pour contribuer à un projet open source sur une période de trois mois. Les contributeurs sont payés par Google pour travailler sous la direction de mentors d'une communauté open source. Le GSOC est une excellente occasion d'apprendre, de développer de nouvelles compétences, de créer des connexions, d'acquérir une expérience de travail avec une équipe plus grande et souvent distribuée et d'être compensé financièrement pour vos efforts.
Dans ce référentiel, vous trouverez des informations sur la façon de postuler au GSOC et une liste d'idées potentielles qui pourraient servir de base à un projet GSOC.
Les contributeurs du GSOC devraient fonctionner soit 350 heures (équivalent à temps plein), 175 heures (équivalent à temps partiel) ou 90 heures (équivalent à court terme) au cours du programme. Le calendrier par défaut dure sur 3 mois (12 semaines) et peut potentiellement être étalé sur une période plus longue.
La date de début du programme n'est pas négociable . Tous les contributeurs GSOC doivent commencer le programme en même temps.
Afin de s'appliquer à GSOC avec STDLIB, vous devez:
N'oubliez pas que toutes les applications doivent passer par le système d'applications de Google et vous devez soumettre votre application sur le site Web de Google . Si vous ne soumettez pas votre demande sur le site Web du GSOC, nous ne pouvons pas accepter votre demande.
L'intention du GSOC est de fournir un moyen aux nouveaux contributeurs de rejoindre et de participer au monde de l'open source. Les contributeurs les plus susceptibles d'être sélectionnés et finalement réussir sont ceux qui sont engagés dans la communauté et espérant continuer leur implication au-delà de la durée du programme GSOC. En général, pour la plupart des projets, être un bon membre de la communauté est plus important que d'être un bon codeur .
Communiquer. La communication est probablement la partie la plus importante du processus de demande. Parlez aux mentors et aux autres développeurs STDLIB, écoutez quand ils offrent des conseils et démontrez que vous avez compris leurs suggestions en incorporant leurs commentaires dans ce que vous proposez. Le non-respect des commentaires réduit considérablement vos chances de succès.
Lisez les instructions. Lisez toujours (et relisez) toutes les instructions lors de la soumission des propositions. Ne soumettez pas simplement un CV, un document scientifique, une présentation ou un autre fichier qui ne contient aucune information sur le projet que vous souhaitez poursuivre. Le non-respect des instructions est garanti pour entraîner un rejet de la proposition.
Être professionnel. Montrez le respect et démontrez que vous prendrez la relation de mentorat au sérieux. Cela signifie écouter activement lorsque vous recevez des commentaires et évaluez toujours le temps de chaque membre de la communauté STDLIB. Une mauvaise communication et un échec à lire et à suivre les instructions transmettent un manque de respect et un manque de considération pour le temps du mentor, et aucun mentor ne veut travailler avec un contributeur qui ne montre pas le professionnalisme nécessaire pour assurer à la fois le succès de leur projet et leur croissance personnelle en tant que membre de la communauté STDLIB.
Si vous avez des questions, vérifiez d'abord si les questions ont déjà été répondues dans la FAQ du GSOC. Si vous avez toujours une question après la consultation de la FAQ GSOC, vous pouvez contacter le canal de l'élément STDLIB.
Vous pouvez utiliser un élément pour solliciter des commentaires sur les idées initiales de projet et obtenir de l'aide lorsque vous commencez à travailler avec la base de code STDLIB. Gardez à l'esprit que plus vos questions sont spécifiques et effacées sur les forums STDLIB, plus vous avez de chances d'obtenir une bonne réponse. Il est peu probable qu'une question ouverte ou vague obtienne une réponse utile.
Par exemple, une bonne question pourrait être quelque chose dans le sens de
Je suis intéressé par le projet X, et j'ai fait un peu de recherche et j'ai constaté que les problèmes Y et Z semblent liés. Sur la base de mes résultats, A, B et C sont déjà mis en œuvre, donc j'aimerais savoir s'il serait raisonnable de proposer un projet qui réaliserait D, E et F.
En revanche, la question suivante est trop ouverte et trop vague pour solliciter une réponse significative
Je suis intéressé par le projet X. Aidez-moi à travailler là-dessus.
Lorsque vous tendez la main sur l'élément, assurez-vous de vous présenter afin que nous puissions vous connaître. Quelques informations utiles à inclure
Avant de travailler sur votre application GSOC, veuillez consulter notre liste d'idées pour voir si vous trouvez un projet qui vous excite. La liste des idées existantes est fournie pour servir d'inspiration et indiquer quelles directions peuvent être bonnes pour STDLIB.
Si vous trouvez une idée existante que vous souhaitez poursuivre, assurez-vous de nous contacter dans notre canal d'élément pour en discuter d'abord! Assurez-vous toujours de poser des questions sur ces idées avant de travailler sur l'application afin d'obtenir les dernières informations sur ce qui est déjà mis en œuvre et ce qui doit être fait.
La liste des idées est organisée par les étiquettes selon les conventions suivantes:
Priorité
high : idées considérées comme importantes dans notre feuille de route.normal : des idées qui ne sont pas urgentes mais qui seraient bien d'avoir plus tôt que tard.low : des idées nouvelles ou intéressantes, mais qui sont faibles sur notre liste de priorités.Difficulté
1 : Une idée adaptée à une personne ayant peu ou pas d'expérience JavaScript.2 : Une idée adaptée à une personne ayant une connaissance pratique de JavaScript.3 : Une idée susceptible d'être difficile mais gérable.4 : Une idée qui est susceptible d'être difficile et a des objectifs ambitieux.5 : Une idée qui est susceptible d'être difficile à mettre en œuvre avec plusieurs inconnues.Technologie
javascript : une idée qui implique la programmation dans JavaScript. Au moins un JavaScript est probablement nécessaire pour toutes les idées.nodejs : une idée qui nécessite de développer avec Node.js. Travailler avec Node.js est probablement nécessaire pour la plupart, sinon la totalité, les idées, car Node.js est l'environnement par défaut pour les tests, l'analyse comparative et le développement local.c : Une idée qui implique la programmation dans C. Ceci est requis pour les modules complémentaires natifs de Node.js.fortran : Une idée qui implique la programmation à Fortran. Ceci est requis pour travailler sur les liaisons BLAS / LAPACK.html/css : une idée qui implique d'utiliser HTML et CSS (par exemple, si la création d'une application frontale).jsx/react : Une idée qui implique la programmation avec React JSX (par exemple, si vous travaillez sur le site Web de STDLIB).native addons : une idée qui implique de développer des modules complémentaires natifs de Node.js.typescript : une idée qui implique la programmation dans TypeScript.La priorité, la difficulté, la technologie et le domaine n'ont aucune incidence sur les chances d'une idée acceptée. Toutes les idées sont tout aussi bonnes et vos chances d'être acceptées dépendent uniquement de la qualité de votre application .
Longueur du projet
Le GSOC permet trois longueurs de projet différentes: 90 heures, 175 heures et 350 heures. Chaque idée doit indiquer si l'idée est mieux adaptée à 90, 175 ou 350 heures.
Dans certains cas, nous pouvons être en mesure d'étendre un projet de 175 heures à un projet de 350 heures en étendant les idées de ce qui peut être fait. De même, dans certains cas, un projet de 350 heures peut être raccourci à un projet de 175 heures en mettant en œuvre une partie d'une idée et en laissant le reste pour un futur projet. Dans les deux cas, si vous souhaitez ajuster la durée du projet, assurez-vous de nous contacter dans notre canal d'élément pour en discuter d'abord!
Si vous souhaitez soumettre votre propre idée, c'est également la bienvenue; Assurez-vous simplement de proposer votre idée aux mentors de STDLIB en premier! Après avoir tendu la main, nous vous informerons si l'idée a déjà été mise en œuvre, si l'idée impliquera suffisamment de travail pour durer la durée du programme GSOC, si l'idée nécessite trop de travail pour être poursuivi de manière significative pendant le GSOC, et si le L'idée est dans le cadre de STDLIB. Les idées non sollicitées et non discutées sont moins susceptibles d'être acceptées.
Le meilleur projet pour vous est celui qui vous intéresse le plus et que vous connaissez le plus. L'excitation et les aptitudes sont deux ingrédients clés d'un projet réussi et aident à assurer votre engagement et votre capacité à voir un projet jusqu'à la fin. Donc, s'il y a quelque chose qui vous passionne particulièrement et que vous croyez que vous vous alignez sur la portée et les objectifs de STDLIB, nous serons heureux d'entendre votre argumentaire!
Après avoir discuté avec nous dans notre canal d'élément et reçu l'approbation pour soumettre votre idée, veuillez ouvrir un problème qui décrit votre idée à l'aide du modèle de problème d'idée .
En plus de la proposition écrite, nous exigeons que chaque candidat GSOC rédige un correctif et le fasse fusionner dans le référentiel STDLIB principal.
Nous prenons vos correctifs à STDLIB en considération lors de l'examen de votre proposition. Soumettre un ou plusieurs patchs est votre meilleure occasion de démontrer que vous êtes capable de faire ce qui est inclus dans votre proposition.
Pour soumettre un patch,
Fourk le référentiel stdlib.
Configurez votre plate-forme pour développer STDLIB (par exemple, installer GIT, cloner votre référentiel fourchu, le configurer pour suivre le référentiel stdlib en amont à distance, installer des dépendances et initialiser votre environnement de développement local). Notre guide de contribution vous guide dans la mise en place de GIT et détaille notre mode de développement préféré.
Veuillez ne pas soumettre de correctifs via l'éditeur Web GitHub. Vous devrez apprendre à utiliser GIT et à développer STDLIB localement si votre projet est accepté. Prendre le temps maintenant d'utiliser GIT et de développer STDLIB augmente localement vos chances de succès et vous aide à décider si STDLIB vous convient.
Trouvez quelque chose dans STDLIB qui ne fonctionne pas, a besoin d'amélioration ou serait un ajout utile. Si vous avez besoin d'inspiration, n'hésitez pas à résoudre tout problème dans la liste des problèmes qui sont bons pour les premiers contributeurs.
En plus des problèmes, recherchez FIXME ou TODO dans la base de code. Vous pouvez utiliser grep à partir de la ligne de commande avec git grep "TODO" .
Vous pouvez également jouer dans le REPT STDLIB et trouver quelque chose qui doit être mis en œuvre ou peut être implémenté.
Une fois que vous avez trouvé quelque chose, si un problème n'existe pas déjà, ouvrez un problème sur le tracker de problème STDLIB décrivant le problème et votre solution proposée.
Si votre projet utilisera une langue autre que JavaScript (par exemple, C ou FORTRAN), vous devez également soumettre des correctifs qui utilisent cette langue afin de démontrer que vous maîtrisez cette langue.
Notez que votre correctif doit être lié au code et non à la documentation. Bien que les correctifs de documentation soient toujours les bienvenus, ils ne répondent pas aux exigences du correctif.
Et notez en outre que votre correctif n'a pas besoin d'être lié à votre projet proposé afin de satisfaire aux exigences du correctif. Afin de vous familiariser avec le code sur lequel vous travailleriez, vous souhaiterez peut-être essayer de corriger un bogue pertinent dans le même code ou similaire, mais cela ne fait pas partie de l'exigence du correctif.
Publiez votre correctif pour l'examen par les pairs en créant une demande de traction sur GitHub. Vous devez soumettre votre demande de traction via GitHub (par exemple, coller un fichier corrigé sur un problème), car c'est le moyen le plus simple pour nous de revoir votre code et de fournir des commentaires et ce que nous attendons d'un contributeur travaillant sur un Projet GSOC.
Vous devez soumettre un correctif qui est examiné avec succès et fusionné pour satisfaire l'exigence du correctif. Nous ne considérons pas les applications sans des correctifs fusionnés avec succès.
Un correctif réussi démontre votre maîtrise technique et votre capacité à interagir avec la communauté STDLIB.
Une fois que vous avez créé une demande de traction sur GitHub, les examinateurs de STDLIB examineront votre code et demanderont des modifications potentiellement. Vous devez répondre à ces modifications.
Tout au long du processus de développement et de rétroaction, vous devez toujours exécuter des tests unitaires localement pour vérifier le comportement attendu.
Pendant l'examen, veuillez être patient avec des critiques. En raison du GSOC, il peut y avoir un certain nombre de demandes de traction à réviser, et nous pouvons être lents à revoir toutes les demandes de traction, surtout si elles sont soumises à proximité de la date limite de demande. Vous êtes fortement encouragé à soumettre vos demandes de traction au début du processus de demande pour vous donner les meilleures chances d'avoir un correctif fusionné avant la date limite de demande .
Bien que le fait qu'un correctif fusionne avant la date limite de l'application est préféré, si votre correctif est toujours en cours d'examen, c'est bien. Ce qui est essentiel, c'est que votre patch soit fusionné avant la date limite d' acceptation .
C'est à vous de répondre à nos commentaires en temps opportun pour que votre correctif soit fusionné avant la date limite d'acceptation .
Dans votre demande, veuillez fournir un bref résumé de vos contributions à STDLIB jusqu'à présent, y compris les travaux qui n'ont pas encore été fusionnés. Cela devrait être une liste des demandes de traction et une indication de savoir si chaque demande de traction est fusionnée, fermée ou toujours ouverte. Si vous avez apporté des contributions importantes en dehors de vos demandes de traction (par exemple, en examinant la demande de traction de quelqu'un d'autre), vous pouvez également l'énumérer.
Veuillez noter que nous ne tolérerons pas le plagiat sous aucune forme. Lorsque vous développez votre application, faites-le en écrivant dans vos propres mots .
Bien que d'autres candidats puissent discuter publiquement et soumettre des propositions pour la même idée, vous ne devez pas soulever du contenu de leurs propositions. Vous devriez écrire et proposer ce que vous pensez être la meilleure ligne de conduite pour assurer un projet réussi en fonction d'un calendrier qui, selon vous , est approprié.
Si nous détectons que votre application contient du contenu plagié, nous rejetterons votre application sans révision.
De plus, bien que nous reconnaissons que, pour de nombreux contributeurs, l'anglais n'est peut-être pas votre première langue, veuillez éviter d'utiliser les LLM (par exemple, Chatgpt, etc.). Nous pouvons généralement dire quand les individus comptent sur les LLM pour générer automatiquement le contenu de l'application (et les contributions du code!), Et ce que cela nous signale, c'est que vous ne pouvez pas être dérangé de prendre le temps d'écrire une application réfléchie et que vous ne serez probablement pas capable de gagner notre confiance.
Les meilleurs candidats sont ceux qui sont réfléchis, qui accordent une attention particulière aux détails et qui sont impatients et prêts à apprendre.
Ce document emprunte fortement
Ce document peut être réutilisé sous une licence Creative Commons Attribution-Sharealike 4.0 (CC BY-SA 4.0).
