Directrices para Stewards (Guías de Área)

Ya sea que seas nuevo contribuyendo para p5.js, que seas activo en los repositorios de GitHub de p5.js, o que te encuentres en algún punto intermedio, encontrarás lo que necesitas en estas directrices sobre el rol de steward (guía de área) en p5.js. Si no estás seguro de qué esperar de los stewards, o si estás considerando ofrecerte como voluntario o comenzar como steward, ¡sigue leyendo!

Tabla de Contenidos

• Stewardship (Guía de Área)
  • Cuidado de la Comunidad
  • Áreas
  • Convertirse en Steward
  • Comenzando como Steward
• Issues
  • Informe de Errores
  • Solicitud de Funcionalidades
  • Mejora de Funcionalidades
  • Discusión
• Pull Requests
  • Corrección Sencilla
  • Corrección de Error
  • Nuevas Funcionalidades/Mejora de Funcionalidades
  • Dependabot
• Proceso de Construcción
  • Tarea Principal de Construcción
  • Tarea Variada
• Proceso de Lanzamiento
• Consejos y Trucos
  • Plantillas de Respuesta
  • GitHub CLI
  • Gestión de Notificaciones

Stewardship (Rol de Guía de Área)

Cuidado de la Comunidad

Un ethos de código abierto incluye accesibilidad, educación, colaboración, transparencia y agencia. Vivir y practicar estos valores mientras escribimos código juntos requiere un atento cuidado de la comunidad. Estas son las prácticas de cuidado comunitario que forman parte de nuestra definición de stewardship:

1. Dar la bienvenida a nuevos contribuidores en GitHub mediante comentarios amigables y revisiones útiles de código.
2. Ayudar a facilitar discusiones sobre funcionalidades y resolver desacuerdos técnicos. Por ejemplo, hacer conexiones con otras discusiones u ofrecer aportes desde experiencia previa relevante. Sugerir funcionalidades o trabajar en ellas es contribución, no stewardship.
3. Participar en los lanzamientos (releases) del software p5.js apoyando la corrección de bugs y la finalización de funcionalidades. Por ejemplo, esto significa guiar a otros contribuidores y revisar sus PRs. Corregir bugs es contribución, no stewardship.

El resto de estas directrices proporcionan algunos consejos y trucos que te ayudarán a contribuir efectivamente a p5.js y a guiar las contribuciones de otros. La mayoría de lo escrito aquí existe como pauta a menos que se indique lo contrario. Puedes adaptar estas prácticas para que se ajusten a tu proceso de trabajo.

¡Todos están invitados a ayudar a cuidar la comunidad cuando puedan! Nos alegra ver contribuidores que dan la bienvenida a nuevos contribuidores, revisan el código de otros y proporcionan retroalimentación sobre el diseño de la API. También existen algunos roles concretos:

• Los contribuidores (contributors) pueden crear issues, PRs, comentarios y revisiones de código.
• Los mantenedores (maintainers) también pueden mergear PRs y administrar otras partes del código del proyecto (codebase).

Los stewards también pueden ser contribuidores: pueden crear issues y PRs como contribuidores, mientras también asumen la responsabilidad, cuando están cuidando un área en particular, de comentar en issues y hacer revisiones de código, especialmente cuando otros contribuidores los etiquetan para ayudar con la discusión y revisión.

Como contribuidor, puedes consultar los stewards actuales en el archivo README del repositorio de p5.js y etiquetar a los stewards relevantes, pero ten en cuenta nuestras directrices para contribuidores, que enfatizan la paciencia y la consideración de que la mayor parte del trabajo técnico en un proyecto de código abierto es voluntario.

Como steward, esperamos que participes regularmente en revisiones de código en issues o PRs que tú no creaste, si están en tu área y si puedes proporcionar orientación útil.

Áreas

Existen diferentes áreas de trabajo de las cuales los stewards pueden ser responsables. Estas áreas coinciden con las etiquetas (labels) de GitHub en la mayoría de los casos, con un par de excepciones. A continuación se presenta la lista de áreas:

• Accesibilidad: Esta área se refiere específicamente a la accesibilidad digital y web, incluyendo, por ejemplo, el soporte para lectores de pantalla mediante API como describe(..), así como el soporte de accesibilidad en el sitio web de referencia
• Núcleo (Core): Se refiere a la API central de p5.js, incluyendo renderizado y entorno
• DevOps: Se refiere al proceso de compilación (build process), pruebas unitarias (unit testing) y otros aspectos de la experiencia de desarrollo
• Documentación: Incluye tanto la referencia en el código base central que se expone en el sitio web, los documentos para contribuidores y otro contenido del sitio web
• i18n (Internacionalización / Traducción): Incluye la revisión de traducciones, particularmente para es, hi, ko, zh
• Gráficos: Contiene subáreas de WebGL y p5.strands
• Color: Incluye Color, ColorMode, mejoras de accesibilidad relacionadas con el uso del color
• Tipografía: Se refiere a todos los temas sobre el manejo de texto y fuentes
• Matemáticas: Incluye tanto la Math API externa como mejoras internas de rendimiento
• Formas (Shapes): Incluye el trabajo con formas personalizadas en las versiones 1.11.x y 2.x de p5.js
• Mantenedores: Este grupo puede mergear PRs
• p5.sound.js: La nueva biblioteca p5.sound.js
• p5.js-website: Aspectos no relacionados con el contenido del sitio web de referencia, por ejemplo, su estructura, automatizaciones, mejoras técnicas, etc.

Estas áreas de enfoque pueden cambiar con el tiempo dependiendo de las necesidades del proyecto, así que si estás pasando por el proceso de solicitar ser steward, ¡eres bienvenido a proponer nuevas áreas!

Convertirse en Steward

Hay dos formas de convertirse en steward:

1. Nominación por parte de mantenedores u otros stewards, como en conversaciones en Discord, Discourse o GitHub.
2. Solicitud creando un PR para actualizar stewards.yml con tu usuario de GitHub @ y las áreas propuestas. Ten en cuenta que cada área debe tener de 1 a 3 stewards. ¡Siempre estamos buscando stewards de traducción! Una vez que hagas tu PR de solicitud, otros mantenedores o stewards pueden pedir material de apoyo adicional, como hacer un PR relacionado con las áreas en las que estás interesado o participar en alguna discusión relacionada.

Para permanecer como steward, debes contribuir como steward en al menos 1 de los 2 lanzamientos menores más recientes (por ejemplo, 2.1.0 o 1.11.0, cuando cambia el número del medio). Estos no son tan frecuentes como los parches (patches) (por ejemplo, 2.0.3 a 2.0.4, cuando cambia el número más a la derecha), y en la práctica esto significa que se espera que los stewards estén activos cada 4-6 meses aproximadamente, apoyando a otros contribuidores mediante discusión o revisión de código, no necesariamente escribiendo código. Para renunciar al rol de steward, puedes hacer un PR para eliminarte de stewards.yml. ¡Siempre eres bienvenido a tomar una pausa y volver a solicitar en el futuro!

Comenzando como Steward

1. Mantén estas directrices a mano como referencia: cómo ayudar con nuevos issues, bugs y funcionalidades. Por ejemplo, la sección “Solicitud de Funcionalidades” incluye consejos sobre cómo usar la declaración de acceso de p5.js como steward.
2. Al ayudar a responder preguntas técnicas o revisar, intenta aplicar la directriz de la Processing Foundation sobre cómo responder preguntas. Estas pueden ser especialmente útiles para dar retroalimentación técnica constructiva.
3. Únete al Discord de p5.js. ¡En el canal #contribute-to-p5 cualquier pregunta o propuesta de mejora sobre este proceso es bienvenida!

Issues

Alentamos a la mayoría de las contribuciones de código fuente a comenzar con un issue, y como tal, los issues son el lugar donde la mayoría de las discusiones tendrán lugar. Los pasos a seguir al revisar un issue dependerán del tipo de issue que sea. El repositorio utiliza Plantillas de issues de GitHub, para organizar mejor los diferentes tipos de issues y alentar a los autores de issues a proporcionar toda la información relevante sobre sus issues. El primer paso al revisar el issue a menudo será revisar la plantilla completada y determinar si necesita información adicional por ejemplo, porque algunos campos no se completaron o se utilizó la plantilla incorrecta.

Informe de Errores

Los issues de informes de errores deberían utilizar la plantilla de Issue “Found a bug”. El siguiente flujo de trabajo es típico para abordar los informes de errores:

1. Replicar el error
   • El objetivo de la plantilla es proporcionar suficiente información para que un revisor intente replicar el error en cuestión.
   • Si el error reportado no es relevante para el repositorio en el que se abrió (p5.js, p5.js-website, u otro):
     • Transfiera el issue al repositorio relevante si tiene acceso a él.
     • De lo contrario, deje un comentario sobre dónde debería presentarse el informe de error (con un enlace directo proporcionado) y cierre el issue.
   • El primer paso para revisar un informe de error es verificar si se proporciona suficiente información para replicar el error, y si es así, se debe intentar replicar el error según lo descrito.
2. Si el error se puede replicar:
   • Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. Puede ser necesario realizar alguna discusión para determinar la mejor manera de solucionar un error particular. A veces, puede ser directo;otras veces, puede ser complicado. Por favor, consulte los principios de diseño de p5.js al tomar esta decisión caso por caso.
   • Si el autor del issue indicó en el issue que está dispuesto a contribuir con una solución:
     • Apruebe el issue para su solución por parte del autor del issue dejando un comentario y asignándoles el issue. Utilice el botón de engranaje en el lado derecho junto a “Assignee”.
   • Si el autor del issue no desea contribuir con una solución:
     • Deje un comentario reconociendo que el error se puede replicar.
     • Intente solucionarlo usted mismo o agregue la etiqueta help wanted para señalar que es un issue que necesita solución.
3. Si el error no se puede replicar:
   • Solicite información adicional si aún no se ha proporcionado en la plantilla (versión de p5.js, versión del navegador, versión del sistema operativo, etc).
   • Si su entorno de prueba difiere de lo que se informa en el issue (por ejemplo,un navegador o sistema operativo diferente):
     • Deje un comentario diciendo que no puede replicar en su entorno específico.
     • Agregue una etiqueta help wanted al issue incidente y pida a alguien más con la configuración especificada en el issue que intente replicar el error.
   • A veces, los bugs (errores) solo ocurren al usar el editor web y no al probar localmente. En este caso, el issue debería ser redirigido al repositorio del editor web.
   • Si la replicación es posible más tarde, regrese al paso 2.
4. Si el error se origina en el código que el usuario proporcionó en el informe de error y no en el comportamiento de p5.js:
   • Determine si la documentación de p5.js, la implementación de código o el sistema de errores amigable pueden mejorarse para evitar que se cometa el mismo error.
   • Redirija amablemente cualquier pregunta adicional al foro o al Discord y cierre el issue si no se van a realizar más cambios en p5.js.

Solicitud de Funcionalidades

Los issues para solicitar funcionalidades deberían utilizar la plantilla “New Feature Request”. El siguiente flujo de trabajo es típico para abordar las solicitudes de función:

1. Como parte del compromiso de p5.js de aumentar el acceso, una solicitud de función debe justificar cómo aumenta el acceso de p5.js a comunidades que históricamente han sido marginadas en el campo. Más detalles están disponibles aquí.
   • Si una solicitud de funcionalidad no tiene suficientemente completado el campo “Increasing Access” (“Aumento de Acceso”), puedes preguntar al autor del issue cómo la funcionalidad aumenta el acceso.
   • La declaración de acceso de una funcionalidad puede ser proporcionada por un miembro diferente de la comunidad, incluidos los revisores de issue.
2. Una nueva solicitud de funcionalidad puede ser evaluada para su inclusión en base a los siguientes criterios:
   • ¿La función encaja en el alcance del proyecto y los principios de diseño principios de diseño de p5.js?
     • Por ejemplo, una solicitud para agregar una nueva forma primitiva de dibujo puede ser considerada, pero una solicitud para adoptar un protocolo de Internet de las cosas basado en el navegador probablemente estará fuera de alcance.
     • En general, el alcance de p5.js debería ser relativamente estrecho para evitar un exceso de características poco utilizadas.
     • Si una función no encaja en el alcance de p5.js, sugiere al autor del issue que implemente la función como una biblioteca complementaria.
     • Si no está claro si encaja o no, puede ser una buena idea sugerir hacer una biblioteca complementaria como una prueba de concepto. Esto ayuda a dar a los usuarios una forma de usar la funcionalidad, proporciona un ejemplo mucho más concreto de su uso e importancia, y no necesariamente necesita ser una solución tan completa como una función completamente integrada. Puede integrarse en el núcleo de p5.js más adelante si corresponde.
   • ¿Es probable que la funcionalidad propuesta cause un cambio incompatible?
     • ¿Entrará en conflicto con las funcionalidades y variables existentes de p5.js?
     • ¿Entrará en conflicto con los sketches (bocetos) típicos ya escritos para p5.js?
     • Las funcionalidades que probablemente causen conflictos, como las mencionadas anteriormente, se consideran cambios incompatibles. Sin un Lanzamiento de versión mayor,no deberíamos realizar cambios incompatibles en p5.js.
   • ¿Se puede lograr la nueva función propuesta utilizando las funcionalidades existentes ya en p5.js,código JavaScript nativo relativamente simple, o bibliotecas existentes fáciles de usar?
     • Por ejemplo, en lugar de proporcionar una función de p5.js para unir una matriz de cadenas como join(["Hello","world!"]), debería preferirse el JavaScript nativo ["Hello","world!"].join().
3. Si el requisito de acceso y otras consideraciones han sido cumplidas, al menos dos supervisores o responsables de mantenimiento deben aprobar la nueva solicitud de función antes de que comience el trabajo hacia una PR. El proceso de revisión de pull request para nuevas funcionalidades está documentado a continuación.

Mejora de funcionalidades

Las solicitudes de issues de mejora de función deberían utilizar la plantilla de incidentes de “Existing Feature Enhancement” (Mejora de Funcionalidades Existentes). El proceso es muy similar a las solicitudes de nuevas funcionalidades. La diferencia entre una new feature request (solicitud de nueva funcionalidad) y una feature request (Mejora de Funcionalidad) puede ser confusa a veces. La mejora de función principalmente trata sobre las funcionalidades existentes de p5.js, mientras que una solicitud de nueva función podría estar solicitando la adición de funcionalidades completamente nuevas.

1. Similar a las solicitudes de nuevas funcionalidades, las mejoras de función solo deben ser aceptadas si aumentan el acceso a p5.js. Por favor, consulta el punto 1 de la sección anterior.
2. Los criterios de inclusión para las mejoras de función son similares a los de las solicitudes de nuevas funcionalidades, pero se debe prestar especial atención a los posibles cambios incompatibles.
   • Si se están modificando funcionalidades existentes, todas las firmas de funcionalidades válidas y documentadas previamente deben comportarse de la misma manera.
3. Las mejoras de funcionalidades deben ser aprobadas por al menos un supervisor o responsable de mantenimiento antes de que comience el trabajo hacia una pull request. El proceso de revisión de pull request para mejoras de funcionalidades está documentado a continuación.

Discusión

Este tipo de issue tiene una plantilla mínima de discusión y debería ser utilizada para recopilar comentarios y retroalimentaciones sobre un tema en general antes de consolidarlo en algo más específico, como una solicitud de función. Estos issues de discusión pueden cerrarse cuando finaliza la conversación y se han creado los issues más específicos resultantes:

• Si se abre un issue como una discusión pero debería ser, por ejemplo, un bug report (informe de error), se debe aplicar la etiqueta correcta y quitar la etiqueta de “discussión”. Además, se debe solicitar información adicional sobre el error al autor si aún no se ha incluido.
• Si se abre un issue como una discusión pero no es relevante para la contribución de código fuente o de otra manera relevante para los repositorios de GitHub, el proceso de contribución o la comunidad de contribución, deberían ser redirigidos al foro o a Discord y el issue cerrado.
• Si es relevante, se deben agregar etiquetas adicionales a los issues de discusión para señalar aún más qué tipo de discusión es con solo mirarla.

Pull Requests

Casi todas las contribuciones de código a los repositorios de p5.js se realizan a través de Pull Request. Los supervisores y los responsables de mantenimiento pueden tener push access (acceso de escritura) a los repositorios, pero aún se les anima a seguir el mismo proceso de issue > pull request > proceso de revisión al contribuir con código. Aquí están los pasos para revisar una pull request:

• La plantilla de pull request se puede encontrar Aquî.
• Casi todas las solicitudes de pull requests deben tener issues asociados abiertos y discutidos primero, lo que significa que los”flujos de trabajo de los issues mås relevantes deben haber sido seguidos primero antes de que una pull request sea revisada por cualquier supervisor o responsable de mantenimiento.
  • Las únicas instancias donde esto no se aplica son correcciones muy menores de errores tipográficos, las cuales no requieren un issue abierto y pueden ser fusionadas por cualquier persona con acceso para aplicar merge (fusionar) al repositorio, incluso si no son supervisores de una área en particular.
  • Si bien esta excepción existe, la aplicaremos en la práctica solo mientras se siga alentando a los contribuyentes a abrir nuevos issues primero. En otras palabras, si tienes dudas sobre si esta excepción se aplica, simplemente abre un issue de todos modos.
• Si una “pull request”no resuelve completamente el issue referenciado, puedes editar la publicación original y cambiar “Resolves #OOOO” a “Addresses #OOOO” para que no cierre automáticamente el issue original cuando la pull request aplique merge (se fusione).

Correción Sencilla

Correcciones simples, como la corrección de un pequeño error tipográfico, pueden fusionarse directamente por cualquier persona con acceso para fusionar. Después, revisa la pestaña “Files Changed” de pull request para asegurarte de que la prueba automatizada de integración continua (CI) haya pasado.

Corrección de Error

1. Bug fixes (Corrección de errores) deberían ser revisado por el supervisor del área relevante, idealmente el mismo que aprobó el issue referenciado para su corrección.
2. La pestaña “Files Changed” de la pull request se puede utilizar para revisar inicialmente si el fix (la ccorrección) se implementa según lo descrito en la discusión del issue.
3. La pull request Debería ser probada localmente siempre que sea posible y relevante. El GitHub CLI puede ayudar a agilizar parte del proceso. Ver más abajo en Consejos y trucos.
   • La Corrección debe abordar suficientemente el issue original.
   • La Corrección no debe cambiar ningún comportamiento existente a menos que se acuerde en el issue original.
   • La Corrección no debe tener un impacto significativo en el rendimiento de p5.js.
   • La Corrección no debe tener ningún impacto en la accesibilidad de p5.js.
   • La Corrección debe utilizar el estándar moderno de codificación en JavaScript.
   • La Corrección debe pasar todas las pruebas automatizadas e incluir nuevas pruebas (tests) si son relevantes.
4. Si se requieren cambios adicionales, se deben agregar comentarios en línea a las líneas relevantes según se describió anteriormente aquí.
   • Un bloque de sugerencias también puede ser usado para sugerir cambios específicos:
     
     
     
   • Si se requieren múltiples cambios, no agregues comentarios de una sola línea muchas veces. En su lugar, sigue el procedimiento documentado aquí para hacer comentarios de varias líneas y una sola solicitud de cambios (change request).
   • Si los comentarios en línea son solo para aclaraciones o discusión, elige “Comment” en lugar de “Request changes”:
     
5. Una vez que la pull request haya sido revisada y no se requieran cambios adicionales, un supervisor puede marcar la pull request como “Aprobada” eligiendo la opción “Approve” en el paso anterior, con o sin comentarios adicionales. El supervisor puede luego solicitar una revisión adicional por otro supervisor o responsable de mantenimiento si lo desea, fusionar la pull request si tiene acceso para fusionar (merge access), o solicitar merge (fusión) de un responsable de mantenimiento.
6. El bot @all-contributors debería ser llamado para agregar cualquier nuevo colaborador a la lista de colaboradores en el archivo README.md. Cada tipo de contribución puede ser indicado en lugar de [contribution type] a continuación, se puede encontrar la lista completa de tipos de contribuciones disponibles en el enlace anterior.

@all-contributors please add @[GitHub handle] for [contribution type]

Nuevas funcionalidades/Mejora de Funcionalidades

El proceso para una pull request de new feature (nuevas funcionalidades),o feature_enhacement (mejora de funcionalidades) es similar a las correcciones de errores,pero solo con una diferencia notable:

• Una pull request de nueva funcionalidad o mejora de funcionalidad debe ser revisada y aprobada por al menos dos supervisores o responsables de mantenimiento antes de que pueda ser fusionada.

Dependabot

Las pull requests de Dependabot generalmente solo son visibles para los administradores del repositorio, así que si esto no aplica a ti, por favor omite esta sección.

• Las pull request de Dependabot pueden fusionarse directamente si la actualización de la versión es una semver versión de parche y la prueba automatizada de CI ha pasado.
• Las pull requests de Dependabot con cambios de versión semver menor generalmente se pueden fusionar directamente siempre y cuando la prueba automatizada de CI pase. Se recomienda hacer una rápida verificación en el registro de cambios de la dependencia actualizada.
• Las pull requests de Dependabot con cambios de versión principal de semver pueden afectar probablemente el proceso de compilación o las funcionalidades de p5.js. Se anima al revisor, en este caso, a revisar el registro de cambios desde la versión actual hasta la versión objetivo si es posible y probar la pull request localmente para asegurarse de que todos los procesos estén funcionando y realizar cualquier cambio necesario debido a posibles cambios disruptivos en las dependencias.
• Muchas dependencias aumentan los números de versión principales solo porque dejan de admitir oficialmente versiones muy antiguas de Node.js. En muchos casos, los cambios de versión principal no necesariamente implican cambios disruptivos resultantes de cambios en la API de dependencias.

Proceso de Compilación

Esta sección no cubrirá la configuración general de compilación (build) ni los comandos, sino más bien detalles sobre lo que sucede detrás de escena. Consulta las directrices para administradores para obtener información más detallada sobre la construcción.

A partir de la versión 2.0 de p5.js, el proyecto ya no usa Grunt para la automatización de tareas. En su lugar, los procesos de compilación y pruebas (test) se manejan usando herramientas modernas como scripts de npm, ESLint y Vitest.

Tarea Principal de Construcción

Para ejecutar las verificaciones de estilo del código (lint) y las pruebas unitarias (unit tests), simplemente ejecuta:

npm test

Este comando ejecuta ESLint para verificar el estilo del código y luego ejecuta las pruebas unitarias y las pruebas visuales usando Vitest.

Tarea lint

En p5.js 2.0, ESLint se usa directamente mediante scripts de npm para todas las tareas de verificación de estilo (linting).

Para ejecutar las verificaciones de estilo (lint) en el código del proyecto.

npm run lint

Este comando verifica los archivos fuente, los scripts de compilación (build scripts), los archivos de prueba y los ejemplos de documentación usando ESLint.

Si solo quieres ejecutar la verificación de estilo (linting) para archivos o directorios específicos, puedes usar ESLint directamente:

npx eslint src/
npx eslint test/

Ya no existe un linter separado para ejemplos ni un pipeline basado en YUIDoc.

Tarea test

En p5.js 2.0, el sistema de pruebas ya no usa Mocha mediante Grunt. En su lugar, las pruebas se ejecutan usando Vitest a través de scripts de npm.

Para ejecutar el conjunto completo de pruebas (unit y visual tests), usa:

npm test

Este comando realiza:

• Verificación de estilo (linting) mediante ESLint
• Pruebas unitarias (unit tests) usando Vitest
• Pruebas visuales (capturas de renderizado)

Las pruebas se encuentran en la carpeta test/unit, organizadas de manera que reflejen la estructura del directorio src. Por ejemplo, las pruebas para src/color/p5.Color.js están en test/unit/color/p5.Color.js.

Para ejecutar las pruebas interactivamente en un entorno similar al navegador (útil para identificar errores o debuggear), ejecuta:

npx vitest --ui

También se puede generar la cobertura de código usando las herramientas integradas de Vitest. Ejecuta:

npx vitest run --coverage

Nota: El proceso de compilación de Browserify/Grunt (por ejemplo, browserify, uglify, brfs-babel) fue eliminado en la versión 2.

Proceso de Lanzamiento

Consulta release_process.md.

Consejos y Trucos

A veces, la cantidad de issues y PR que requieren revisión puede ser un poco abrumadora. Si bien intentamos implementar procesos que faciliten las cosas, hay algunos consejos y trucos que puedes utilizar para ayudar con la revisión de issues y PRs.

Plantillas de Respuesta

Una característica útil de GitHub que puedes utilizar es la funcionalidad Respuestas Guardadas, que está disponible para usar al redactar una respuesta a issues o pull requests. Algunos de los flujos de trabajo descritos anteriormente pueden requerir responder a issues o PRs con respuestas idénticas o muy similares (redireccionar preguntas al foro, aceptar un problema para su corrección, etc.), y usar Respuestas Guardadas puede hacer que esto sea un poco más eficiente.

A continuación, se muestran algunas de las Respuestas Guardadas que están siendo utilizadas por los mantenedores de p5.js. ¡Puedes usarlas tú mismo o crear las tuyas!

Cerrando: No se puede Reproducir

No podemos reproducir esto, pero no dudes en reabrir si puedes proporcionar un ejemplo de código que demuestre el problema. ¡Gracias!

Cerrando: Necesita Fragmento

Estoy cerrando esto por motivos organizativos. Por favor, reabre si puedes proporcionar un fragmento de código que ilustre el issue. ¡Gracias!

Cerrando: Usa el Foro

Los issues de GitHub aquí son un buen lugar para los issues y problemas con la biblioteca p5.js en sí. Para preguntas sobre cómo escribir tu propio código, pruebas o seguir tutoriales, el foro es el mejor lugar para publicar. ¡Gracias!

Cerrando: GSOC

¡Gracias! El mejor lugar para discutir las propuestas de GSOC es en nuestro foro.

Cerrando: Acceso

No veo mucho interés en esta función, y no tenemos una explicación clara de cómo amplía el acceso, así que cerraré esto por ahora. Si se puede agregar una declaración de acceso a la solicitud del issue, no dudes en volver a abrirlo.

No vemos una explicación más detallada de cómo esta cuestión amplía el acceso, así que cerraré este issue por ahora. Si se puede agregar una declaración de acceso más detallada a la solicitud de función, no dudes en volver a abrirla. ¡Gracias!

Cerrando: Complemento

Creo que esta función está fuera del alcance de la API de p5.js (intentamos mantenerla lo más minimalista posible), pero podría ser un gran punto de partida para una biblioteca complementaria. Consulta la documentación aquí sobre cómo crear un complemento: https://github.com/processing/p5.js/blob/main/contributor_docs/creating_libraries.md

Cerrando PR: Primero Necesita Issue

Gracias. Como recordatorio, primero deben abrirse issues antes de que se abran pull request y etiquetarse con el issue. Esto es necesario para realizar un seguimiento del desarrollo y mantener la discusión clara. ¡Gracias!

Aprobar issue para corrección

Puedes seguir adelante con una solución. Gracias.

PR Fusionado

Se ve bien. ¡Gracias!

GitHub CLI

Revisar un PR complejo puede ser difícil con comandos de git complejos necesarios para obtener la versión del código del PR localmente para que puedas probarla. Afortunadamente, GitHub CLI puede ayudar enormemente con este proceso y más.

Después de instalar GitHub CLI e iniciar sesión, revisar una PR localmente se puede hacer ejecutando el comando gh pr checkout [id_del_pull_request], y el proceso de obtener un fork remoto, crear una rama y cambiar a la rama se realizan automáticamente para ti. Volver a la rama principal será lo mismo que cambiar de rama ejecutando git checkout main. ¡Incluso puedes dejar un comentario en el PR desde la CLI sin necesidad de visitar la página web en absoluto!

También hay muchos otros comandos disponibles en GitHub CLI que puedes encontrar útiles o no, pero es una buena herramienta para tener en cualquier caso.

Gestión de Notificaciones

En lugar de monitorear manualmente las pestañas Issues o Pull Requests del repositorio en busca de nuevos issues o PRs, puedes “ver” el repositorio haciendo clic en el botón Watch con un ícono de ojo en la parte superior de la página del repositorio, frente al nombre del repositorio.

Al observar un repositorio, eventos como nuevos issues, nuevos pull requests, menciones de tu nombre de usuario y otras actividades a las que te hayas suscrito en el repositorio se enviarán como notificaciones a tu página de notificaciones, donde se pueden marcar como leídas o descartadas de la misma manera que un buzón de correo electrónico.

En algunos casos, también puedes recibir correos electrónicos de GitHub sobre eventos en el repositorio que estás observando, y puedes personalizarlos (incluida la desuscripción completa de ellos) desde tu página de configuración de notificaciones.

Configurar estas opciones para que se adapten a la forma en que trabajas puede ser la diferencia entre tener que buscar issues/PRs relevantes para revisar manualmente y sentirse abrumado por notificaciones interminables de GitHub. Se requiere un buen equilibrio aquí. Como sugerencia inicial, los supervisores deberían observar este repositorio para Issues y Pull Requests y configurarlo para recibir correos electrónicos solo sobre “Participando, @menciones y personalizadas”.