Partenaires / Contributions
Contribuer à inAi Open Source
Contributions ciblées à des outils publics, des expériences, des services publics et des projets de référence.
inAi publie ouvertement une sélection de logiciels natifs d'IA afin que les constructeurs puissent les utiliser, les inspecter, en tirer des leçons et les améliorer. Les contributions ciblées sont les bienvenues lorsqu'elles correspondent à l'objectif et à l'étape actuelle du projet. Chaque référentiel est différent, le meilleur chemin de contribution commence donc par le projet lui-même.
Lisez les instructions actuelles, recherchez les problèmes existants et ouvrez un problème avant d'investir dans une fonctionnalité substantielle ou un changement architectural. Une petite amélioration bien expliquée est généralement plus utile qu’une proposition générale.
Commencer le projet
Le portefeuille Open Source d'inAi comprend des outils actifs, des prototypes expérimentaux, des utilitaires de référence et des projets existants. Ces étiquettes comptent. Ils décrivent comment un référentiel doit être lu et quel type de contribution est susceptible d'y correspondre.
Les besoins du projet évoluent avec le temps. Le référentiel, ses problèmes actuels et ses conseils de contribution sont la source de vérité pour la configuration technique, les attentes en matière de révision, les licences et ce qui est utile actuellement.
La contribution n'est pas seulement du code
Différents projets nécessitent différents types de travail. En fonction du référentiel et de son état d'avancement, une contribution utile peut prendre l'une des formes suivantes.
Code et correctifs ciblés
Corrigez un défaut reproductible, améliorez la fiabilité ou apportez une petite modification d'implémentation qui correspond à l'objectif actuel du projet.
Tests et rapports de problèmes
Ajoutez une couverture utile ou signalez un problème avec l'environnement, les étapes de reproduction, le résultat attendu, le résultat réel et toute preuve nécessaire pour le comprendre.
Documentation et exemples
Clarifiez l'installation, expliquez le comportement, ajoutez un exemple minimal, améliorez le dépannage ou corrigez les instructions incomplètes ou obsolètes.
Compatibilité et expérience des développeurs
Améliorez le packaging, l’installation, les messages d’erreur, la compatibilité de la plateforme ou du fournisseur, ou le flux de travail de développement local.
Interface et accessibilité
Lorsqu'un projet comprend une interface utilisateur, améliorez la clarté, la navigation, l'utilisation du clavier, l'accessibilité ou le déroulement d'une tâche réelle.
Rapports de sécurité
Signalez les vulnérabilités suspectées en privé. Les résultats de sécurité n’ont pas leur place dans les problèmes publics ordinaires ou les demandes d’extraction.
Avant de commencer
Quelques minutes d’alignement peuvent éviter des journées de travail sur un changement qui ne correspond pas au projet.
Étape 1
Texte Commencez par le fichier README, l'état actuel, les conseils de contribution, la politique de sécurité, la licence, les instructions de configuration et la documentation de test lorsqu'ils sont disponibles.
Étape 2
Texte Vérifiez les problèmes ouverts et fermés et les demandes d'extraction avant de créer un rapport ou une implémentation en double.
Étape 3
Texte De petites corrections autonomes peuvent être directement envoyées à une pull request lorsque les instructions du référentiel le permettent. Ouvrez d'abord un ticket pour les nouvelles fonctionnalités, les modifications architecturales, les nouveaux fournisseurs ou dépendances majeures, les modifications apportées aux interfaces publiques, les paramètres de sécurité par défaut ou les réécritures générales.
Étape 4
Texte Résolvez un problème clair. Évitez de mélanger des nettoyages, des refontes, des modifications de dépendances et de nouvelles fonctionnalités sans rapport dans la même contribution.
Étape 5
Texte Utilisez le niveau de vérification approprié au projet. Expliquez ce que vous avez testé, ce que vous n'avez pas pu tester et si le changement affecte le comportement, la configuration, les interfaces ou la documentation.
Étape 6
Texte Expliquez le problème, le changement proposé, la portée délibérément laissée de côté, la vérification effectuée et toute limitation connue. Liez le problème pertinent lorsqu’il en existe un.
Battements utiles au sens large
Une contribution utile identifie un objet réel : un référentiel, un fichier, une commande, une étape de configuration, un comportement, un test, un exemple ou une interface. Il explique ce qui s'est passé, ce qui était attendu et pourquoi la différence est importante. Il propose ensuite un changement suffisamment petit pour être compris et examiné.
Un problème important ou une pull request comprend normalement :
Le projet et une partie du projet concerné.
Le problème ou l’opportunité abordée.
Étapes de reproduction ou contexte pertinent.
Comportement attendu et comportement réel.
Le changement proposé et sa portée prévue.
Comment le changement a été testé ou vérifié.
Limitations connues ou cas non testés.
La documentation change là où le comportement ou la configuration a changé.
Tout problème, discussion ou travail antérieur qui fournit un contexte.
Des preuves claires et un changement ciblé sont plus utiles qu’une grande déclaration selon laquelle un projet devrait être différent.
À quoi s'attendre après la soumission
Les contributions sont considérées par rapport à l'objectif du projet, à son stade actuel, à sa qualité technique, à sa clarté, à sa maintenabilité et à ses priorités actuelles. Le calendrier de l’examen varie selon le projet, la portée et la capacité disponible.
Une proposition peut être acceptée, révisée, reportée, partiellement adoptée ou refusée. Une idée utile ne correspond pas toujours au projet à ce moment-là, et la soumission ne garantit pas une révision, une fusion, une publication ou un rôle de responsable continu. Ouvrir un problème avant un travail substantiel est le meilleur moyen de réduire les efforts inutiles.
L’historique du référentiel public est l’enregistrement normal de la paternité. Un accusé de réception supplémentaire peut être utilisé le cas échéant.
Ne présumez pas qu’un problème, une pull request ou une demande de contribution est un travail rémunéré. Les travaux sponsorisés, commandés ou en cours doivent être convenus séparément par écrit avant de commencer. Soumettre ou accepter une contribution ne crée pas en soi un emploi, un contrat, un stage, un partenariat ou une autorité pour représenter inAi.
Conservez les contributions publiques en toute sécurité pour pouvoir les examiner
Les problèmes GitHub et les demandes d’extraction sont publics. N'incluez pas d'informations d'identification, de jetons, d'informations personnelles, de documents confidentiels, d'ensembles de données privés, de données de clients ou d'employeurs, de code propriétaire ou de fichiers locaux qui ne doivent pas être publics. Utilisez des exemples synthétiques ou aseptisés lorsque des preuves sont nécessaires.
Soumettez uniquement le matériel que vous avez le droit de partager. La licence et les instructions de contribution de chaque référentiel font autorité.
Quels que soient les outils utilisés pour le créer, la personne qui soumet une contribution reste responsable de comprendre le changement, de le tester, de vérifier qu'il peut être partagé et de le corriger si nécessaire.
Alerte de sécurité
Texte N’ouvrez pas de problème public. Utilisez la politique de sécurité du référentiel ou la voie de reporting privée. Lorsqu'aucun itinéraire spécifique au projet n'est disponible, contactez inAi pour établir un canal privé. N'incluez pas de détails sur l'exploit ou de preuves sensibles dans le premier message.
Quand GitHub ne suffit pas
GitHub est la bonne voie pour apporter des améliorations ciblées à un référentiel public existant. Contactez inAi avant le début de la mise en œuvre lorsqu'une proposition implique un travail soutenu, plusieurs référentiels, un développement sponsorisé ou commandé, une recherche formelle, une intégration commerciale ou un accès au-delà du projet public.
Les tests de produits sans modification du référentiel appartiennent à la catégorie Testeurs. La collaboration en matière de recherche relève du domaine universitaire/recherche. L'emploi, le contrat ou l'intérêt en matière de développement continu appartiennent à la catégorie Travailler avec nous.
Commencez par un changement utile
Choisissez le projet, identifiez un problème réel et apportez la première contribution suffisamment petite pour être comprise et examinée. Le référentiel vous dira quel est le projet ; un problème clair ou une pull request devrait montrer comment vous pouvez l'améliorer.