google summer of code
1.0.0
Recursos para el programa Google Summer of Code.
¡Hola! Y bienvenido al repositorio de recursos Google Summer of Code (GSOC) de Stdlib.
GSOC es un programa global que ofrece a los nuevos contribuyentes (que tienen 18 años o más) la oportunidad de que se le pague por contribuir a un proyecto de código abierto durante un período de tres meses. Google pagan a los contribuyentes para trabajar bajo la guía de mentores de una comunidad de código abierto. GSOC es una gran oportunidad para aprender, desarrollar nuevas habilidades, desarrollar conexiones, adquirir experiencia trabajando con un equipo más grande y a menudo distribuido, y ser compensado financieramente por sus esfuerzos.
En este repositorio, encontrará información sobre cómo solicitar GSOC y una lista de ideas potenciales que podrían servir como base para un proyecto GSOC.
Se espera que los contribuyentes de GSOC trabajen 350 horas (equivalente a tiempo completo), 175 horas (equivalente a tiempo parcial) o 90 horas (equivalente a corto plazo) en el transcurso del programa. El horario predeterminado se ejecuta durante 3 meses (12 semanas) y potencialmente puede extenderse durante un período más largo.
La fecha de inicio del programa no es negociable . Todos los contribuyentes de GSOC deben comenzar el programa al mismo tiempo.
Para aplicar a GSOC con STDLIB, debe:
Recuerde que todas las aplicaciones deben pasar por el sistema de aplicaciones de Google y debe enviar su aplicación en el sitio web de Google . Si no envía su solicitud en el sitio web de GSOC, no podemos aceptar su solicitud.
La intención de GSOC es proporcionar una forma para que los nuevos contribuyentes se unan y participen en el mundo del código abierto. Los contribuyentes con mayor probabilidad de ser seleccionados y, en última instancia, tienen éxito son aquellos que participan en la comunidad y esperan continuar su participación más allá de la duración del programa GSOC. En general, para la mayoría de los proyectos, ser un buen miembro de la comunidad es más importante que ser un buen codificador .
Comunicar. La comunicación es probablemente la parte más importante del proceso de aplicación. Hable con mentores y otros desarrolladores de Stdlib, escuche cuando ofrecen consejos y demuestre que ha entendido sus sugerencias al incorporar sus comentarios en lo que está proponiendo. No incorporar retroalimentación reduce significativamente sus posibilidades de éxito.
Lea las instrucciones. Siempre lea (y vuelva a leer) todas las instrucciones al enviar propuestas. No envíe simplemente un currículum, papel científico, presentación u otro archivo que no contenga ninguna información sobre el proyecto que desea realizar. No se garantiza que las instrucciones sigan las instrucciones para conducir al rechazo de la propuesta.
Ser profesional. Muestre respeto y demuestre que tomará en serio la relación de mentoría. Eso significa escuchar activamente cuando recibe comentarios y siempre valorando el tiempo de cada miembro en la comunidad de Stdlib. La mala comunicación y la falta de leído y seguir las instrucciones transmiten una falta de respeto y una falta de consideración por el tiempo de mentores, y ningún mentor quiere trabajar con un contribuyente que no exhiba la profesionalidad necesaria para garantizar tanto el éxito de su proyecto como para Su crecimiento personal como miembro de la comunidad de Stdlib.
Si tiene preguntas, primero verifique si las preguntas ya han sido respondidas en las preguntas frecuentes de GSOC. Si aún tiene una pregunta después de consultar las preguntas frecuentes de GSOC, puede comunicarse con el canal de elementos STDLIB.
Puede usar Elemento para solicitar comentarios sobre las ideas iniciales del proyecto y obtener ayuda a medida que comienza a trabajar con la base de código STDLIB. Tenga en cuenta que cuanto más específicas y claras sus preguntas en los foros de STDLIB, más probabilidades tendrá de obtener una buena respuesta. Es poco probable que una pregunta abierta o vaga obtenga una respuesta útil.
Por ejemplo, una buena pregunta podría ser algo en la línea de
Estoy interesado en el Proyecto X, y he investigado un poco y descubrí que los problemas Y y Z parecen relacionados. Según mis hallazgos, A, B y C ya están implementados, por lo que me gustaría saber si sería razonable proponer un proyecto que lograría D, E y F.
En contraste, la siguiente pregunta es demasiado abierta y demasiado vaga para solicitar una respuesta significativa
Estoy interesado en el Proyecto X. Ayúdame a trabajar en esto.
Al llegar al elemento, asegúrese de presentarse para que podamos conocerlo. Algunas piezas de información útiles para incluir
Antes de trabajar en su aplicación GSOC, revise nuestra lista de ideas para ver si encuentra un proyecto que lo emociona. La lista de ideas existentes se proporciona para servir como inspiración e indicar qué direcciones pueden ser buenas para Stdlib.
Si encuentra una idea existente que le gustaría seguir, ¡asegúrese de contactarnos en nuestro canal de elementos para discutirla primero! Siempre asegúrese de preguntar sobre estas ideas antes de trabajar en la aplicación para obtener la información más reciente sobre lo que ya está implementado y qué se debe hacer exactamente.
La lista de ideas está organizada por etiquetas de acuerdo con las siguientes convenciones:
Prioridad
high : ideas que se consideran importantes en nuestra hoja de ruta.normal : ideas que no son urgentes pero que sería bueno tener más temprano que tarde.low : ideas novedosas o interesantes, pero que están bajas en nuestra lista de prioridades.Dificultad
1 : Una idea adecuada para alguien con poca o ninguna experiencia de JavaScript.2 : Una idea adecuada para alguien con un conocimiento práctico de JavaScript.3 : Una idea que probablemente sea desafiante pero manejable.4 : Una idea que probablemente sea desafiante y tiene objetivos ambiciosos.5 : Una idea que probablemente sea difícil de implementar con varias incógnitas.Tecnología
javascript : una idea que implica la programación en JavaScript. Es probable que al menos algunos JavaScript sean necesarios para todas las ideas.nodejs : una idea que requiere desarrollar con Node.js. Es probable que trabajar con Node.js sea necesario para la mayoría, si no todas, las ideas, ya que Node.js es el entorno predeterminado para las pruebas, la evaluación comparativa y el desarrollo local.c : Una idea que implica la programación en C. Esto se requiere para complementos nativos de Node.js.fortran : Una idea que implica la programación en Fortran. Esto es necesario para trabajar en enlaces BLAS/LAPACK.html/css : una idea que implica el uso de HTML y CSS (por ejemplo, si construye una aplicación frontend).jsx/react : una idea que implica la programación con React JSX (por ejemplo, si trabaja en el sitio web de STDLIB).native addons : una idea que implica desarrollar complementos nativos de nodo.js.typescript : una idea que implica la programación en TypeScript.La prioridad, la dificultad, la tecnología y el área del tema no tienen relación con las posibilidades de que se acepte una idea. Todas las ideas son igualmente buenas, y sus posibilidades de ser aceptadas dependen únicamente de la calidad de su aplicación .
Longitud del proyecto
GSOC permite tres longitudes diferentes del proyecto: 90 horas, 175 horas y 350 horas. Cada idea debe indicar si la idea es mejor para 90, 175 o 350 horas.
En algunos casos, podemos extender un proyecto de 175 horas a un proyecto de 350 horas al extender las ideas de lo que se puede hacer. Del mismo modo, en algunos casos, un proyecto de 350 horas puede acortarse a un proyecto de 175 horas al implementar solo parte de una idea y dejar el resto para un proyecto futuro. En cualquier caso, si desea ajustar la longitud del proyecto, ¡asegúrese de contactarnos en nuestro canal de elementos para discutirlo primero!
Si desea enviar su propia idea, eso también es bienvenido; ¡Solo asegúrese de proponer su idea a los mentores de Stdlib primero! Después de contactar, le informaremos si la idea ya se ha implementado, si la idea implicará suficiente trabajo para durar la duración del programa GSOC, si la idea requiere demasiado trabajo para ser realizado de manera significativa durante GSOC, y si el La idea está dentro del alcance de Stdlib. Las ideas no solicitadas y no discutidas tienen menos probabilidades de ser aceptadas.
El mejor proyecto para usted es el que más le interesa y conoce. La emoción y la aptitud son dos ingredientes clave de un proyecto exitoso y ayudan a garantizar su compromiso y capacidad para ver un proyecto hasta la finalización. Entonces, si hay algo que le apasiona especialmente y que cree que se alinea con el alcance y los objetivos de Stdlib, ¡estaremos felices de escuchar su lanzamiento!
Después de discutir con nosotros en nuestro canal de elementos y recibir aprobación para enviar su idea, abra un problema que describe su idea utilizando la plantilla de emisión de ideas .
Además de la propuesta escrita, requerimos que cada solicitante de GSOC escriba un parche y que se fusione en el repositorio principal de STDLIB.
Llevamos sus parches a Stdlib a una fuerte consideración al revisar su propuesta. Enviar uno o más parches es su mejor oportunidad para demostrar que es capaz de hacer lo que está incluido en su propuesta.
Para enviar un parche,
Bifurca el repositorio de Stdlib.
Configure su plataforma para desarrollar stdlib (por ejemplo, instalar git, clonar su repositorio bifurcado, configurarla para rastrear el repositorio remoto de STDLIB, dependencias de instalación e inicializar su entorno de desarrollo local). Nuestra guía contribuyente lo guía a través de la creación de Git y detalla nuestra forma de desarrollo preferida.
No envíe parches a través del editor web de GitHub. Deberá aprender a usar GIT y desarrollar stdlib localmente si su proyecto es aceptado. Tomarse el tiempo ahora para usar GIT y desarrollar STDLIB localmente aumenta sus posibilidades de éxito y lo ayuda a decidir si Stdlib es una buena opción para usted.
Encuentre algo en stdlib que no funcione, necesite mejoras o sería una adición útil. Si necesita inspiración, no dude en solucionar cualquier problema en la lista de problemas que sean buenos para los contribuyentes por primera vez.
Además de los problemas, busque FIXME o TODO en la base de código. Puede usar grep de la línea de comandos con git grep "TODO" .
También puede jugar en el STDLIB REPL y encontrar algo que necesite arreglar o que pueda implementarse.
Una vez que haya encontrado algo, si un problema aún no existe, abra un problema en el rastreador de problemas de STDLIB que describe el problema y su solución propuesta.
Si su proyecto utiliza un idioma que no sea JavaScript (por ejemplo, C o Fortran), también debe enviar parches que usen ese idioma para demostrar que es competente en ese idioma.
Tenga en cuenta que su parche debe estar relacionado con el código, no la documentación. Si bien las correcciones de documentación siempre son bienvenidas, no cumplen con el requisito del parche.
Y tenga en cuenta que su parche no necesita estar relacionado con su proyecto propuesto para satisfacer el requisito del parche. Para familiarizarse con el código en el que está trabajando, es posible que desee intentar solucionar un error relevante en el mismo código o similar, pero esto no es parte del requisito de parche.
Publique su parche para la revisión por pares creando una solicitud de extracción en GitHub. Debe enviar su solicitud de extracción a través de GitHub (en lugar de, por ejemplo, pegar un archivo parcheado en un problema), ya que esta es la forma más fácil de revisar su código y proporcionar comentarios y es lo que esperamos de un contribuyente que trabaje en un Proyecto GSOC.
Debe enviar un parche que se revise y fusione con éxito para satisfacer el requisito del parche. No consideramos aplicaciones sin parches fusionados con éxito.
Un parche exitoso demuestra su competencia técnica y su capacidad para interactuar con la comunidad Stdlib.
Una vez que haya creado una solicitud de extracción en GitHub, los revisores de STDLIB revisarán su código y potencialmente solicitarán cambios. Debe abordar estos cambios.
A lo largo del proceso de desarrollo y retroalimentación, siempre debe ejecutar pruebas unitarias localmente para verificar el comportamiento esperado.
Durante la revisión, sea paciente con los revisores. Debido a GSOC, puede haber una serie de solicitudes de extracción para revisar, y es posible que debamos revisar todas las solicitudes de extracción, especialmente si se envían cerca de la fecha límite de solicitud. Se le recomienda encarecidamente que envíe sus solicitudes de extracción al principio del proceso de solicitud para darse la mejor oportunidad de tener un parche fusionado antes de la fecha límite de solicitud .
Mientras se fusiona un parche antes de preferir la fecha límite de la aplicación, si su parche aún está en revisión, está bien. Lo crítico es que su parche se fusione antes de la fecha límite de aceptación .
Depende de usted responder a nuestros comentarios de manera lo suficientemente oportuna como para que su parche se fusione antes de la fecha límite de aceptación .
En su solicitud, proporcione un breve resumen de sus contribuciones a STDLIB hasta ahora, incluido el trabajo que aún no se ha fusionado. Esta debería ser una lista de solicitudes de extracción y una indicación de si cada solicitud de extracción se fusiona, cierra o aún está abierta. Si realizó contribuciones significativas fuera de sus solicitudes de extracción (por ejemplo, revisar la solicitud de extracción de otra persona), también puede enumerarlo.
Tenga en cuenta que no toleraremos el plagio de ninguna forma. Al desarrollar su aplicación, hágalo escribiendo en sus propias palabras .
Si bien otros solicitantes pueden discutir y presentar públicamente propuestas para la misma idea, no debe levantar el contenido de sus propuestas. Debe escribir y proponer lo que cree que es el mejor curso de acción para garantizar un proyecto exitoso de acuerdo con una línea de tiempo que cree que es apropiado.
Si detectamos que su aplicación contiene contenido plagiado, rechazaremos su aplicación sin revisión.
Además, si bien reconocemos que, para muchos contribuyentes, el inglés puede no ser su primer idioma, evite usar LLM (por ejemplo, chatgpt, etc.). Por lo general, podemos saber cuándo las personas confían en LLMS para generar el contenido de la aplicación (¡y las contribuciones del código!), Y lo que esto nos indica es que no puede molestarse en tomarse el tiempo para escribir una aplicación reflexiva y que probablemente no lo capaz de ganar nuestra confianza.
Los mejores candidatos son aquellos que son reflexivos, que prestan mucha atención a los detalles y que están ansiosos y están dispuestos a aprender.
Este documento toma prestado mucho de
Este documento puede reutilizarse bajo una licencia Creative Commons Attribution-Sharealike 4.0 International (CC BY-SA 4.0).
