Tout le monde peut contribuer à OpenXLA, et nous apprécions les contributions de chacun. Il existe plusieurs façons de contribuer, y compris:
Répondre aux questions sur les forums de discussion OpenXLA (openxla-discuss)
Amélioration ou développement de la documentation d'OpenXLA
Contribuer au codebase d'OpenXLA
Contribuer de l'une des manières ci-dessus à l'écosystème plus large de bibliothèques basées sur OpenXLA
Le projet OpenXLA respecte le Règlement de la communauté Open Source de Google.
Avant de commencer
Signez le Contrat de licence Contributeur
Les contributions à ce projet doivent être accompagnées d'un Contrat de licence du contributeur. Vous (ou votre employeur) conservez les droits d'auteur sur votre contribution. Cela nous donne simplement l'autorisation d'utiliser et de redistribuer vos contributions dans le cadre du projet.
Si vous ou votre employeur actuel avez déjà signé le CLC Google (même s'il s'agissait d'un autre projet), vous n'avez probablement pas besoin de le faire à nouveau.
Accédez à <https://cla.developers.google.com/> pour consulter vos contrats actuels ou en signer un nouveau.
Examiner le code de conduite
Ce projet respecte le code de conduite de Tensorflow.
Processus de contribution
Guide du développeur
Pour savoir comment configurer un environnement de développement pour OpenXLA, y compris comment obtenir du code, le compiler, exécuter des tests et soumettre des modifications, consultez le guide du développeur.
Normes de code
Style de codage: nous suivons le guide de style du code de Google. Consultez plus particulièrement les guides C/C++ et Python. Tout code envoyé doit être strictement conforme à ces guides de style.
Changements compacts: nous respectons les pratiques techniques de Google. Consultez en particulier le guide sur l'écriture de modifications compactes. Cela augmentera considérablement la vitesse de fusion de votre code, ce qui améliore la facilité d'examen, et réduit la probabilité d'effets secondaires involontaires d'une modification. Même en cas de modification importante, il existe de nombreuses stratégies pour la diviser en modifications plus incrémentielles.
Couverture des tests: toutes les modifications doivent inclure des tests unitaires appropriés. Les tests unitaires ne doivent pas dépendre de la synchronisation du matériel (processeur, GPU, etc.) et doivent utiliser librement des simulations afin d'effectuer des tests déterministes et ciblés. Les modifications visant à étendre le code existant actuellement difficile à tester doivent apporter des améliorations appropriées en termes de testabilité.
Toutes les modifications doivent inclure des résultats de benchmark appropriés ainsi que dans le titre des modifications pour que les avantages soient clairement compris.
En cas de doute concernant les conventions dans le code, il est toujours judicieux d'examiner le code préexistant et d'essayer de suivre les modèles déjà en place dans OpenXLA.
Processus d'examen
Toutes les contributions, y compris celles des membres du projet, doivent être examinées. Nous utilisons les demandes d'extraction GitHub à cette fin. Pour en savoir plus sur l'utilisation des requêtes d'extraction, consultez l'aide de GitHub.
Le code doit respecter toutes les normes listées ci-dessus avant d'être examiné. Celles-ci ne sont pas facultatives. Il est essentiel que le demandeur s'assure que son code est conforme avant de demander un examen afin d'être sûr d'accepter les modifications dans les meilleurs délais.
Tous les tests doivent réussir. Si vous constatez qu'un test ne fonctionne pas et que le problème n'est pas lié à votre environnement de compilation ni à vos modifications, veuillez contacter les responsables.
Essayez d'éviter toute dérive des objectifs pendant le processus d'examen. Il incombe au demandeur et à l'auteur de l'avis de répondre à cette question. Si une modification commence à devenir trop importante, envisagez de la diviser en plusieurs modifications.
Avant de fusionner une modification, elle est soumise à des tests internes utilisant du code interne à Google et à d'autres fournisseurs de matériel. Cela peut potentiellement ajouter des étapes supplémentaires au processus d'examen en cas d'échecs dans les tests internes que notre CI publique ne détecte pas. Le Googleur chargé d'examiner votre modification communiquera les échecs des tests internes et décrira ce qui doit être corrigé.
Questions fréquentes (FAQ)
"Ce changement d'infrastructure n'est pas lié à mes relations publiques. Pourquoi devrais-je le faire ? »
L'équipe XLA ne dispose pas d'équipe d'infrastructure dédiée. Il nous appartient donc à tous de créer des bibliothèques d'aide et d'éviter tout problème technique. Nous considérons qu'il s'agit d'une partie régulière des modifications apportées à XLA, et tout le monde est tenu d'y participer. Nous créons généralement l'infrastructure selon les besoins lorsque nous écrivons du code.
Les examinateurs XLA peuvent vous demander de créer une infrastructure (ou d'apporter une modification importante à un PR) en même temps que le document de relations publiques que vous avez rédigé. Cette demande peut sembler inutile ou orthogonale par rapport à la modification que vous essayez d'apporter. Cela est probablement dû à un décalage entre vos attentes concernant la quantité d'infrastructure que vous devez créer et celles de votre évaluateur.
Une non-concordance des attentes est acceptable ! C'est normal lorsque vous débutez dans un projet (et cela nous arrive parfois même à nos anciens chapeaux). Il est probable que les projets sur lesquels vous avez travaillé dans le passé ont des attentes différentes. C'est aussi normal et attendu ! Cela ne signifie pas que l'un de ces projets a la mauvaise approche ; ils sont juste différents. Nous vous invitons à traiter les demandes liées à l'infrastructure, ainsi que tout autre commentaire d'examen, afin de découvrir ce que nous attendons de ce projet.
"Puis-je aborder votre commentaire lors d'une prochaine demande de renseignements ?"
Concernant les demandes d'infrastructure (ou d'autres demandes importantes) dans les demandes d'extraction, on se demande souvent si la modification doit être effectuée dans la demande d'extraction initiale ou si elle peut être effectuée dans le cadre d'un suivi lors d'une demande d'extraction ultérieure.
En général, XLA n'autorise pas les auteurs de relations publiques à traiter des commentaires dans le cadre d'une demande de relations publiques de suivi. Lorsqu'un examinateur décide qu'un problème doit être traité dans une demande de réadmission donnée, nous attendons généralement des auteurs qu'ils le traitent dans cette demande, même si la demande constitue une modification importante. Cette norme s'applique en externe et en interne au sein de Google.
XLA adopte cette approche pour plusieurs raisons.
Confiance:il est essentiel de gagner la confiance de l'évaluateur. Dans un projet Open Source, les contributeurs peuvent apparaître ou disparaître à volonté. Une fois que nous avons approuvé un RP, les examinateurs n'ont aucun moyen de s'assurer que les suivis annoncés sont effectivement effectués.
Impact sur les autres développeurs:si vous avez envoyé une demande d'extraction concernant une partie spécifique de XLA, il est fort probable que d'autres personnes examinent la même partie. Si nous acceptons des dettes techniques dans votre demande d'extraction, toutes les personnes qui consultent ce fichier seront affectées par cette dette jusqu'à ce que la demande de suivi soit envoyée.
Bande passante des réviseurs:le report d'une modification d'un suivi impose plusieurs coûts à nos examinateurs déjà surchargés. En attendant le suivi, les examinateurs oublieront probablement de quoi il s'agissait lors de la première demande d'extraction, ce qui rendrait le prochain examen plus difficile. En outre, les évaluateurs devront suivre les suivis attendus, s’assurer qu’ils se produisent réellement. Si la modification est véritablement indépendante de la demande d'extraction d'origine et qu'un autre examinateur peut l'examiner, la bande passante est moins problématique. D'après notre expérience, ce n'est que rarement le cas.