Guía de Contribución

• Reportes de Errores
• Preguntas de Soporte
• Discusión sobre el Desarrollo del Core
• ¿Qué Rama Usar?
• Archivos Compilados
• Vulnerabilidades de Seguridad
• Estilo de Código
  • PHPDoc
  • StyleCI
• Código de Conducta

#Reportes de Errores

Para fomentar la colaboración activa, Laravel recomienda encarecidamente los pull requests, no solo los reportes de errores. Los pull requests solo serán revisados cuando estén marcados como "listos para revisión" (no en estado "borrador") y todas las pruebas para nuevas funcionalidades estén pasando. Los pull requests inactivos que permanezcan en estado "borrador" serán cerrados después de unos días.

Sin embargo, si presenta un reporte de error, su incidencia debe contener un título y una descripción clara del problema. También debe incluir tanta información relevante como sea posible y un ejemplo de código que demuestre el problema. El objetivo de un reporte de error es facilitar que usted mismo y otros puedan replicar el error y desarrollar una solución.

Recuerde, los reportes de errores se crean con la esperanza de que otros con el mismo problema puedan colaborar con usted para resolverlo. No espere que el reporte de error reciba actividad automáticamente ni que otros se apresuren a solucionarlo. Crear un reporte de error sirve para ayudarle a usted y a otros a comenzar el camino para arreglar el problema. Si desea colaborar, puede ayudar corrigiendo cualquier error listado en nuestros rastreadores de incidencias. Debe estar autenticado en GitHub para ver todas las incidencias de Laravel.

Si nota advertencias incorrectas de DocBlock, PHPStan o IDE mientras usa Laravel, no cree una incidencia en GitHub. En su lugar, envíe un pull request para corregir el problema.

El código fuente de Laravel se gestiona en GitHub, y hay repositorios para cada uno de los proyectos de Laravel:

#Preguntas de Soporte

Los rastreadores de incidencias de GitHub de Laravel no están destinados a proporcionar ayuda o soporte de Laravel. En su lugar, utilice uno de los siguientes canales:

#Discusión sobre el Desarrollo del Core

Puede proponer nuevas funcionalidades o mejoras del comportamiento existente de Laravel en el repositorio del framework Laravel en el foro de discusión de GitHub. Si propone una nueva funcionalidad, por favor esté dispuesto a implementar al menos parte del código necesario para completarla.

Las discusiones informales sobre errores, nuevas funcionalidades e implementación de características existentes tienen lugar en el canal #internals del servidor Discord de Laravel. Taylor Otwell, el mantenedor de Laravel, suele estar presente en el canal entre semana de 8am a 5pm (UTC-06:00 o America/Chicago), y de forma esporádica en otros horarios.

#¿Qué Rama Usar?

Todas las correcciones de errores deben enviarse a la versión más reciente que soporte correcciones de errores (actualmente 10.x). Las correcciones de errores nunca deben enviarse a la rama master a menos que arreglen funcionalidades que solo existen en la próxima versión.

Las funcionalidades menores que sean totalmente compatibles hacia atrás con la versión actual pueden enviarse a la rama estable más reciente (actualmente 10.x).

Las funcionalidades mayores o con cambios incompatibles siempre deben enviarse a la rama master, que contiene la próxima versión.

#Archivos Compilados

Si envía un cambio que afecte un archivo compilado, como la mayoría de los archivos en resources/css o resources/js del repositorio laravel/laravel, no debe incluir los archivos compilados en el commit. Debido a su gran tamaño, no pueden ser revisados de forma realista por un mantenedor. Esto podría ser explotado para inyectar código malicioso en Laravel. Para prevenir esto de forma defensiva, todos los archivos compilados serán generados y comprometidos por los mantenedores de Laravel.

#Vulnerabilidades de Seguridad

Si descubre una vulnerabilidad de seguridad en Laravel, por favor envíe un correo electrónico a Taylor Otwell a taylor@laravel.com. Todas las vulnerabilidades de seguridad serán atendidas con prontitud.

#Estilo de Código

Laravel sigue el estándar de codificación PSR-2 y el estándar de autoloading PSR-4.

#PHPDoc

A continuación se muestra un ejemplo de un bloque de documentación válido en Laravel. Note que el atributo @param va seguido de dos espacios, el tipo del argumento, dos espacios más y finalmente el nombre de la variable:

/**
 * Register a binding with the container.
 *
 * @param  string|array  $abstract
 * @param  \Closure|string|null  $concrete
 * @param  bool  $shared
 * @return void
 *
 * @throws \Exception
 */
public function bind($abstract, $concrete = null, $shared = false)
{
    // ...
}

Cuando los atributos @param o @return son redundantes debido al uso de tipos nativos, pueden eliminarse:

/**
 * Execute the job.
 */
public function handle(AudioProcessor $processor): void
{
    //
}

Sin embargo, cuando el tipo nativo es genérico, por favor especifique el tipo genérico mediante los atributos @param o @return:

/**
 * Get the attachments for the message.
 *
 * @return array<int, \Illuminate\Mail\Mailables\Attachment>
 */
public function attachments(): array
{
    return [
        Attachment::fromStorage('/path/to/file'),
    ];
}

#StyleCI

¡No se preocupe si el estilo de su código no es perfecto! StyleCI fusionará automáticamente cualquier corrección de estilo en el repositorio de Laravel después de que los pull requests sean aceptados. Esto nos permite enfocarnos en el contenido de la contribución y no en el estilo del código.

#Código de Conducta

El código de conducta de Laravel está basado en el código de conducta de Ruby. Cualquier violación al código de conducta puede ser reportada a Taylor Otwell (taylor@laravel.com):