Skip to main content
El recurso de FiveM de Humalike acepta pull requests de la comunidad. Son bienvenidas las correcciones de errores acotadas, las pruebas, las mejoras de rendimiento, las integraciones genéricas y las correcciones de documentación.

​
Habla primero de las funciones

Habla con nosotros en Discord antes de implementar un cambio que:
  • añada una función o una opción de configuración;
  • cambie el comportamiento de NPC, voz, mundo o integraciones;
  • añada o cambie una capacidad de proveedor;
  • cambie la comunicación entre el recurso de FiveM y Humalike;
  • cambie un export, evento, convar, comando o contrato de datos público;
  • añada una dependencia o cambie el empaquetado de las releases.
Esto da a los mantenedores y colaboradores la oportunidad de acordar el contrato público antes de que empiece un trabajo de implementación sustancial. Las correcciones pequeñas, las pruebas y las correcciones de documentación pueden ir directamente a una pull request.

​
Preservar los contratos públicos

No cambies por tu cuenta el contrato de comunicación entre el recurso y Humalike, el flujo de autenticación o licencias, la gestión de credenciales de tiempo de ejecución, las direcciones de servicio ni las cargas útiles del protocolo. Estos cambios requieren la aprobación previa de los mantenedores y una release coordinada. Trata las APIs de proveedor versionadas, los exports públicos, los eventos, las convars y los comandos como contratos de compatibilidad. Los cambios aditivos también necesitan discusión. Los cambios incompatibles requieren un plan de migración explícito. Mantén el recurso central independiente y neutral respecto al framework. Los trabajos, reglas de economía, permisos, eventos privados y hooks de UI específicos de un cliente pertenecen a un puente separado. Una integración genérica de framework debe usar APIs públicas, seguir siendo opcional y preservar el funcionamiento independiente. Nunca hagas commit de credenciales, claves de licencia, endpoints privados, datos de clientes, información de despliegue ni datos generados en tiempo de ejecución.

​
Enviar una pull request

  1. Crea una rama a partir de la rama main actual.
  2. Mantén la pull request centrada en un solo comportamiento o contrato.
  3. Añade pruebas acotadas para los cambios de comportamiento.
  4. Actualiza la documentación cuando cambie la superficie pública admitida.
  5. Explica la motivación, el impacto en la compatibilidad y la validación en la descripción de la pull request.
Ejecuta las comprobaciones documentadas en la guía de contribución del repositorio antes de enviar la pull request. Los mantenedores pueden pedir dividir un cambio amplio o ajustar su diseño para proteger la compatibilidad.

​
Informa de los problemas de seguridad en privado

No publiques vulnerabilidades en una incidencia ni en un mensaje de Discord. Usa el informe privado de vulnerabilidades de GitHub.