Skip to main content
La ressource FiveM de Humalike accepte les pull requests de la communauté. Les corrections de bugs ciblées, les tests, les améliorations de performances, les intégrations génériques et les corrections de documentation sont les bienvenus.

​
Discuter d’abord des fonctionnalités

Parlez-nous sur Discord avant d’implémenter un changement qui :
  • ajoute une fonctionnalité ou une option de configuration ;
  • modifie le comportement des PNJ, de la voix, du monde ou des intégrations ;
  • ajoute ou modifie une capacité de fournisseur ;
  • modifie la communication entre la ressource FiveM et Humalike ;
  • modifie un export, un événement, une convar, une commande ou un contrat de données publics ;
  • ajoute une dépendance ou modifie l’empaquetage des releases.
Cela donne aux mainteneurs et aux contributeurs l’occasion de s’accorder sur le contrat public avant qu’un travail d’implémentation conséquent ne commence. Les petits correctifs, les tests et les corrections de documentation peuvent aller directement en pull request.

​
Préserver les contrats publics

Ne modifiez pas de votre propre initiative le contrat réseau entre la ressource et Humalike, le flux d’authentification ou de licence, la gestion des identifiants d’exécution, les adresses de service ou les charges utiles du protocole. Ces changements nécessitent l’approbation préalable des mainteneurs et une release coordonnée. Traitez les API de fournisseurs versionnées, les exports, événements, convars et commandes publics comme des contrats de compatibilité. Les changements additifs nécessitent tout de même une discussion. Les changements cassants exigent un plan de migration explicite. Gardez la ressource principale autonome et neutre vis-à-vis des frameworks. Les métiers, règles d’économie, permissions, événements privés et hooks d’interface propres à un client appartiennent à un pont séparé. Une intégration de framework générique doit utiliser des API publiques, rester optionnelle et préserver le fonctionnement autonome. Ne commitez jamais d’identifiants, de clés de licence, d’endpoints privés, de détails clients, d’informations de déploiement ou de données d’exécution générées.

​
Soumettre une pull request

  1. Créez une branche à partir de la branche main actuelle.
  2. Limitez la pull request à un seul comportement ou contrat.
  3. Ajoutez des tests ciblés pour les changements de comportement.
  4. Mettez à jour la documentation lorsque la surface publique prise en charge change.
  5. Expliquez la motivation, l’impact sur la compatibilité et la validation dans la description de la pull request.
Exécutez les vérifications documentées dans le guide de contribution du dépôt avant de soumettre la pull request. Les mainteneurs peuvent demander de scinder un changement trop large ou d’en ajuster la conception pour protéger la compatibilité.

​
Signaler les problèmes de sécurité en privé

Ne publiez pas de vulnérabilités dans une issue ou un message Discord. Utilisez le signalement privé de vulnérabilités GitHub.