Contribuir a Express

Express es un proyecto de la OpenJS Foundation distribuido en tres organizaciones de GitHub: expressjs, pillarjs, y jshttp. Todas las contribuciones son bienvenidas, ya sea reportando bugs, mejorando la documentación o enviando código. Las pautas a continuación describen cómo opera el proyecto y cómo puedes involucrarte.

Comité técnico

El comité técnico de Express está formado por miembros activos del proyecto, y guía el desarrollo y mantenimiento del proyecto Express. Para más información, consulta Comunidad de Express - Comité técnico.

Guía de contribución de la comunidad

El objetivo de este documento es crear un proceso de contribución que:

• Fomente nuevas contribuciones.
• Fomente que los colaboradores permanezcan involucrados.
• Evite procesos y burocracia innecesarios siempre que sea posible.
• Crea un proceso transparente de toma de decisiones que deje claro cómo los colaboradores pueden involucrarse en la toma de decisiones.

Vocabulario

• Un Contributor es cualquier persona que crea o comenta en un issue o pull request.
• Un Committer es un subconjunto de contributors que han recibido acceso de escritura al repositorio.
• Un Project Captain es el mantenedor principal de un repositorio.
• Un TC (Technical Committee) es un grupo de committers que representa la experiencia técnica necesaria para resolver disputas poco frecuentes.
• Un Triager es un subconjunto de contributors que han recibido acceso de triage al repositorio.

Reportar issues

Reporta un issue para cualquier duda o problema que tengas. En caso de duda, reporta un issue, y cualquier política adicional sobre qué incluir se proporcionará en las respuestas. La única excepción son las divulgaciones de seguridad que deben enviarse de forma privada.

Los committers pueden dirigirte a otro repositorio, pedir aclaraciones adicionales, y añadir los metadatos apropiados antes de que el issue sea abordado.

Por favor sé cortés y respetuoso. Se espera que cada participante siga el Código de Conducta del proyecto.

Contribuciones

Cualquier cambio a los recursos en este repositorio debe hacerse a través de pull requests. Esto aplica a todos los cambios en documentación, código, archivos binarios, etc. Incluso los committers de larga duración y los miembros del TC deben usar pull requests.

Ningún pull request puede ser mergeado sin ser revisado.

Para contribuciones no triviales, los pull requests deben esperar al menos 36 horas para asegurar que los colaboradores en otras zonas horarias tengan tiempo para revisar. También se debe considerar los fines de semana y otros períodos festivos para asegurar que todos los committers activos tengan tiempo razonable para involucrarse en el proceso de discusión y revisión si lo desean.

El valor predeterminado para cada contribución es que se acepta una vez que ningún committer tiene una objeción. Durante una revisión, los committers también pueden solicitar que un contributor específico que es más versado en un área particular dé un "LGTM" antes de que el PR pueda ser mergeado. No hay ningún proceso adicional de "sign off" para que las contribuciones sean aceptadas. Una vez que todos los issues planteados por los committers son abordados, puede ser aceptado por cualquier committer.

En caso de que se plantee una objeción en un pull request por otro committer, todos los committers involucrados deben buscar llegar a un consenso abordando las preocupaciones expresadas mediante discusión, compromiso en el cambio propuesto, o retirada del cambio propuesto.

Si una contribución es controversial y los committers no pueden ponerse de acuerdo sobre cómo hacerla llegar o si debería llegar, entonces debería escalarse al TC. Los miembros del TC deben discutir regularmente las contribuciones pendientes para encontrar una resolución. Se espera que solo una pequeña minoría de issues sean llevados al TC para su resolución y que la discusión y el compromiso entre committers sea el mecanismo de resolución por defecto.

Convertirse en Triager

¡Cualquiera puede convertirse en triager! Lee más sobre el proceso de ser triager en el documento de proceso de triage.

Actualmente, cualquier miembro de la organización existente puede nominar a un nuevo triager. Si estás interesado en convertirte en triager, nuestro mejor consejo es participar activamente en la comunidad ayudando a hacer triage de issues y pull requests. También recomendamos participar en otras actividades de la comunidad como asistir a las reuniones del TC y participar en las discusiones de Slack. Si te sientes listo y has estado ayudando con el triage de algunos issues, contacta a un miembro activo de la organización para preguntar si estaría dispuesto a apoyarte. Si están de acuerdo, pueden crear un pull request para formalizar tu nominación. En caso de una objeción a la nominación, el equipo de triage es responsable de trabajar con los individuos involucrados y encontrar una resolución.

También puedes contactar a cualquiera de los miembros de la organización si tienes preguntas o necesitas orientación.

Convertirse en Committer

Todos los contributors que han logrado contribuciones significativas y valiosas deberían ser incorporados de manera oportuna, y añadidos como committers, y recibir acceso de escritura al repositorio.

Se espera que los committers sigan esta política y continúen enviando pull requests, pasen por una revisión adecuada, y que otros committers mergueen sus pull requests.

Proceso del TC

El TC usa un proceso de "búsqueda de consenso" para los issues que se escalan al TC. El grupo intenta encontrar una resolución que no tenga objeciones abiertas entre los miembros del TC. Si no se puede alcanzar un consenso sin objeciones, se convoca una votación donde gana la mayoría. También se espera que la mayoría de las decisiones tomadas por el TC sean mediante un proceso de búsqueda de consenso y que la votación se use solo como último recurso.

La resolución puede involucrar devolver el issue a los capitanes del proyecto con sugerencias sobre cómo avanzar hacia un consenso. No se espera que una reunión del TC resuelva todos los issues en su agenda durante esa reunión y puede preferir continuar la discusión que ocurre entre los capitanes del proyecto.

Se pueden añadir miembros al TC en cualquier momento. Cualquier miembro del TC puede nominar a otro committer al TC y el TC usa su proceso estándar de búsqueda de consenso para evaluar si añadir o no a este nuevo miembro. El TC consistirá en un mínimo de 3 miembros activos y un máximo de 10. Si el TC cae por debajo de 5 miembros, los miembros activos del TC deben nominar a alguien nuevo. Si un miembro del TC se retira, se le anima (pero no se le requiere) a nominar a alguien para tomar su lugar.

Los miembros del TC serán añadidos como administradores en las organizaciones de GitHub, npm y otros recursos según sea necesario para ser efectivos en el rol.

Para permanecer "activo", un miembro del TC debe tener participación dentro de los últimos 12 meses y no faltar a más de seis reuniones consecutivas del TC. Nuestro objetivo es aumentar la participación, no castigar a las personas por cualquier falta de participación; esta guía debe usarse solo como tal (reemplazar un miembro inactivo por uno nuevo activo, por ejemplo). Se espera que los miembros que no cumplan esto den un paso al lado. Si un miembro del TC no da un paso al lado, se puede abrir un issue en el repositorio de discusiones para pasarlos a estatus inactivo. Los miembros del TC que se retiran o son removidos debido a inactividad serán movidos al estatus inactivo.

Los miembros con estatus inactivo pueden convertirse en miembros activos por autodesignación si el TC no está ya más grande que el máximo de 10. También se les dará preferencia si, estando en el tamaño máximo, un miembro activo se retira.

Capitanes de proyecto

El TC de Express puede designar capitanes para proyectos/repos individuales en las organizaciones. Estos capitanes son responsables de ser los mantenedores principales día a día del repo en el frente técnico y comunitario. Los capitanes de repo tienen facultades de propiedad del repo y derechos de publicación de paquetes. Cuando hay conflictos, especialmente en temas que afectan al proyecto Express en general, los capitanes son responsables de elevarlo al TC y llevar esos conflictos a resolución. Los capitanes también son responsables de asegurar que los miembros de la comunidad sigan las pautas de la comunidad, mantener el repo y el paquete publicado, así como proporcionar soporte a los usuarios.

Al igual que los miembros del TC, los capitanes de repos son un subconjunto de committers.

Para convertirse en capitán de un proyecto, se espera que el candidato participe en ese proyecto durante al menos 6 meses como committer antes de la solicitud. Debe haber ayudado con contribuciones de código y con el triage de issues. También se requiere que tenga 2FA habilitado en sus cuentas de GitHub y npm.

Cualquier miembro del TC o un capitán existente del mismo repo puede nominar a otro committer al rol de capitán. Para hacerlo, deben enviar un PR a este documento, actualizando la sección de Capitanes de Proyecto Activos (manteniendo el orden de clasificación) con el nombre del proyecto, el handle de GitHub del nominado y su nombre de usuario de npm (si es diferente).

• Los repos pueden tener tantos capitanes como tenga sentido para el alcance del trabajo.
• Un miembro del TC o un capitán existente del repo en el mismo proyecto puede nominar a un nuevo capitán. Los capitanes de otros proyectos no deben nominar capitanes para un proyecto diferente.

El PR requerirá al menos 2 aprobaciones de miembros del TC y 2 semanas de espera para permitir comentarios y/o objeciones. Cuando el PR se mergeuee, un miembro del TC los añadirá a los grupos apropiados de GitHub/npm.

Proyectos y capitanes activos

La lista se puede encontrar en https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#active-projects-and-members

Capitanes de iniciativas actuales

La lista se puede encontrar en https://github.com/expressjs/discussions/blob/HEAD/docs/contributing/captains_and_committers.md#current-initiative-captains

Política de inactividad y estatus emérito para cualquier rol

Para respaldar la salud y continuidad del proyecto, se fomenta a todas las personas que desempeñan un rol dentro de la comunidad (como Triager, Committer, miembro de WG, Project Captain o miembro del TC) a mantener una participación activa.

La inactividad se define como la ausencia de involucramiento significativo en el proyecto —como contribuciones, revisiones de código, triage, asistencia a reuniones o participación en discusiones— durante un período continuo de 6 meses.

Excepciones

Cualquier persona puede solicitar una licencia temporal de la participación activa debido a razones personales o profesionales. En tales casos, la persona debe informar al equipo correspondiente o al Comité Técnico (TC). Durante este período, la política de inactividad se pausa y la persona no será marcada como inactiva.

Proceso de inactividad

• Si alguien es considerado inactivo, la persona puede ser transicionada a un rol emérito que refleje sus contribuciones pasadas. Se hará el mejor esfuerzo para informarle que esto ha ocurrido. Pueden solicitar ser restituidos cuando estén listos para estar activos nuevamente.
• El estatus emérito ayuda a preservar un registro claro de los colaboradores que han dado forma significativamente al proyecto a lo largo del tiempo.

Rendición de cuentas

• El Comité Técnico (TC) y los respectivos capitanes de cada paquete/equipo son responsables de evaluar los niveles de actividad y aplicar esta política de manera justa y transparente, en coordinación con otros equipos relevantes.
• En caso de desacuerdo, la situación puede discutirse y resolverse por consenso dentro del TC o el equipo apropiado.

Certificado de Origen del Desarrollador 1.1

By making a contribution to this project, I certify that:

 (a) The contribution was created in whole or in part by me and I
     have the right to submit it under the open source license
     indicated in the file; or

 (b) The contribution is based upon previous work that, to the best
     of my knowledge, is covered under an appropriate open source
     license and I have the right under that license to submit that
     work with modifications, whether created in whole or in part
     by me, under the same open source license (unless I am
     permitted to submit under a different license), as indicated
     in the file; or

 (c) The contribution was provided directly to me by some other
     person who certified (a), (b) or (c) and I have not modified
     it.

 (d) I understand and agree that this project and the contribution
     are public and that a record of the contribution (including all
     personal information I submit with it, including my sign-off) is
     maintained indefinitely and may be redistributed consistent with
     this project or the open source license(s) involved.

Guía del colaborador

Issues del sitio web

Abre issues para el sitio web expressjs.com en https://github.com/expressjs/expressjs.com.

Para issues en otros repos gestionados por Express (todo en expressjs, pillarjs o jshttp aparte de expressjs/express), asegúrate de revisar su guía de contribución y abrir issues y PRs en el repositorio apropiado.

PRs y contribuciones de código

• Las pruebas deben pasar.
• Sigue el JavaScript Standard Style y npm run lint.
• Si arreglas un bug, añade una prueba.

Branches

Usa la branch master para arreglos de bugs o trabajo menor destinado al stream de la versión actual.

Usa la branch con el nombre correspondiente, por ejemplo 6.x, para cualquier cosa destinada a una versión futura de Express.

Pasos para contribuir

1. Crea un issue para el bug que quieres arreglar o la funcionalidad que quieres añadir.
2. Crea tu propio fork en GitHub, luego haz checkout de tu fork.
3. Escribe tu código en tu copia local. Es una buena práctica crear una branch para cada nuevo issue en el que trabajas, aunque no es obligatorio.
4. Para ejecutar el conjunto de pruebas, primero instala las dependencias ejecutando npm install, luego ejecuta npm test.
5. Asegúrate de que tu código pase el lint ejecutando npm run lint — arregla cualquier issue que veas listado.
6. Si las pruebas pasan, puedes hacer commit de tus cambios a tu fork y luego crear un pull request desde ahí. Asegúrate de referenciar tu issue en los comentarios del pull request incluyendo el número del issue, por ejemplo #123.

Issues que son preguntas

Típicamente cerraremos cualquier issue vago o preguntas que sean específicas de alguna app que estés escribiendo. Por favor revisa cuidadosamente la documentación y otras referencias antes de ser demasiado rápido al publicar un issue de pregunta.

Cosas que ayudarán a que tu issue de pregunta sea revisada:

• Código JS completo y ejecutable.
• Descripción clara del problema o comportamiento inesperado.
• Descripción clara del resultado esperado.
• Pasos que has tomado para depurarlo tú mismo.

Si publicas una pregunta y no describes los items anteriores o no haces fácil para nosotros entender y reproducir tu issue, será cerrado.

Si tu pregunta cumple con todos los requisitos anteriores pero no crees que necesita ser revisada por los mantenedores (por ejemplo, si solo buscas opinión de la comunidad) por favor ábrela como tema de discusión en lugar de un issue. Si no estás seguro y abres un issue, podemos moverlo a discusiones si hacemos triage y decidimos que no necesita alta visibilidad o intervención de los mantenedores.

Políticas y procedimientos de seguridad

Este documento describe los procedimientos de seguridad y las políticas generales para el proyecto Express.

• Reportar un bug o vulnerabilidad de seguridad
• Política de divulgación
• Comentarios sobre esta política
• El modelo de amenazas de Express

Reportar un bug o vulnerabilidad de seguridad

El equipo de Express y la comunidad toman muy en serio todas las vulnerabilidades de seguridad. Gracias por mejorar la seguridad de Express y proyectos relacionados. Apreciamos tus esfuerzos en la divulgación responsable y haremos todo lo posible para reconocer tus contribuciones.

Un miembro del equipo de triage de seguridad o el capitán del repo acusará recibo de tu reporte lo antes posible. Estos plazos pueden extenderse cuando nuestros voluntarios de triage están de vacaciones, particularmente al final del año.

Después de la respuesta inicial a tu reporte, el equipo de seguridad se esforzará por mantenerte informado sobre el progreso hacia una corrección y el anuncio completo, y puede solicitar información o guía adicional.

Reportar bugs de seguridad vía GitHub Security Advisory (Preferido)

La forma preferida de reportar vulnerabilidades de seguridad es a través de GitHub Security Advisories. Esto nos permite colaborar en un arreglo manteniendo la confidencialidad del reporte.

Para reportar una vulnerabilidad (docs):

1. Visita la pestaña Security del repositorio afectado en GitHub.
2. Haz clic en Report a vulnerability y sigue los pasos proporcionados.

Este proceso aplica a cualquier repositorio dentro del ecosistema de Express. Si no estás seguro de si un repositorio cae bajo esta política, siéntete libre de contactarnos vía correo electrónico.

Reportar vía correo electrónico

Si lo prefieres, también puedes reportar problemas de seguridad enviando un correo a express-security@lists.openjsf.org.

Para asegurar una respuesta oportuna, por favor incluye todos los detalles relevantes directamente en el cuerpo del correo en lugar de enlazar a fuentes externas o adjuntar archivos.

El mantenedor principal acusará recibo de tu correo dentro de las 48 horas y proporcionará una respuesta inicial describiendo los próximos pasos. El equipo de seguridad te mantendrá informado sobre el progreso y puede solicitar detalles adicionales.

Módulos de terceros

Si el problema de seguridad pertenece a un módulo de terceros que no es mantenido directamente dentro del ecosistema de Express, por favor repórtalo a los mantenedores de ese módulo.

Política de divulgación

Cuando el equipo de seguridad recibe un reporte de bug de seguridad, lo asignará a un manejador principal. Esta persona coordinará el proceso de arreglo y publicación, involucrando los siguientes pasos:

• Confirmar el problema y determinar las versiones afectadas.
• Auditar el código para encontrar cualquier problema similar potencial.
• Preparar arreglos para todas las versiones que aún están bajo mantenimiento. Estos arreglos serán publicados lo más rápido posible en npm.

Comentarios sobre esta política

Si tienes sugerencias sobre cómo mejorar este proceso, por favor envía un pull request.

El modelo de amenazas de Express

El modelo de amenazas de Express define los límites de lo que el framework considera su responsabilidad de seguridad. Establece qué elementos son confiables (como el desarrollador, el entorno de ejecución y el código de la aplicación) frente a los no confiables (como los datos de conexiones de red). Los problemas que surgen de elementos confiables se consideran fuera del alcance, mientras que Express es responsable de manejar de forma segura los datos no confiables.

Muchas preocupaciones reportadas comúnmente caen fuera del alcance de seguridad de Express y son responsabilidad del desarrollador de la aplicación. Tales como la contaminación de prototipos por entrada de usuario no sanitizada, configuración errónea de servicio de archivos estáticos, o problemas en dependencias de terceros.

Para detalles completos, consulta el Modelo de amenazas de Express.