Cette page a été traduite par l'API Cloud Translation.

Le processus RFC TensorFlow

Chaque nouvelle fonctionnalité TensorFlow commence sa vie sous la forme d'une demande de commentaire (RFC).

Un RFC est un document qui décrit une exigence et les modifications proposées qui la résoudront. Plus précisément, la RFC:

Être formaté selon le modèle RFC .
Être soumis en tant que pull request au répertoire community / rfcs .
Faire l'objet d'une discussion et d'une réunion d'examen avant l'acceptation.

Le but d'une demande de commentaires (RFC) TensorFlow est d'impliquer la communauté TensorFlow dans le développement, en obtenant les commentaires des parties prenantes et des experts, et en communiquant largement les changements de conception.

Comment soumettre une RFC

Avant de soumettre une RFC, discutez de vos objectifs avec les contributeurs et les mainteneurs du projet et obtenez des commentaires rapides. Utilisez la liste de diffusion des développeurs pour le projet concerné (développeurs@tensorflow.org, ou la liste pour le SIG concerné).
Rédigez votre RFC.
- Lire les critères de revue de conception
- Suivez le modèle RFC .
- Nommez votre fichier RFC YYYYMMDD-descriptive-name.md , où YYYYMMDD est la date de soumission et le descriptive-name rapporte au titre de votre RFC. (Par exemple, si votre RFC est intitulée API Parallel Widgets , vous pouvez utiliser le nom de fichier 20180531-parallel-widgets.md .
- Si vous avez des images ou d'autres fichiers auxiliaires, créez un répertoire de la forme YYYYMMDD-descriptive-name dans lequel stocker ces fichiers.
Après avoir rédigé le brouillon de la RFC, obtenez les commentaires des responsables et des contributeurs avant de le soumettre.
L'écriture du code d'implémentation n'est pas une exigence, mais elle peut aider à concevoir des discussions.
Recrutez un sponsor.
- Un sponsor doit être un responsable du projet.
- Identifiez le sponsor dans le RFC, avant de publier le PR.
Vous pouvez publier un RFC sans sponsor, mais si dans le mois suivant la publication du PR il n'y a toujours pas de sponsor, il sera fermé.
Soumettez votre RFC en tant que pull request à tensorflow / community / rfcs .
Incluez la table d'en-tête et le contenu de la section Objectif dans le commentaire de votre pull request, à l'aide de Markdown. Pour un exemple, veuillez consulter cet exemple de RFC . Incluez les descripteurs GitHub des co-auteurs, des réviseurs et des sponsors.
En haut du PR, indiquez la durée de la période de commentaires. Cela devrait être un minimum de deux semaines à compter de la publication du PR.
Envoyez un e-mail à la liste de diffusion des développeurs avec une brève description, un lien vers le PR et une demande d'examen. Suivez le format des mailings précédents, comme vous pouvez le voir dans cet exemple .
Le sponsor demandera une réunion du comité d'examen, au plus tôt deux semaines après la publication du RFC PR. Si la discussion est animée, attendez qu'elle soit réglée avant de passer à l'examen. Le but de la réunion d'examen est de résoudre les problèmes mineurs; un consensus doit être atteint au préalable sur les questions majeures.
La réunion peut approuver la RFC, la rejeter ou exiger des modifications avant qu'elle ne puisse être réexaminée. Les RFC approuvés seront fusionnés en communauté / rfcs , et les RFC rejetés verront leurs PR fermés.

Participants RFC

De nombreuses personnes sont impliquées dans le processus RFC:

Auteur de la RFC - un ou plusieurs membres de la communauté qui rédigent une RFC et s'engagent à la défendre tout au long du processus
Sponsor de la RFC - un responsable qui parraine la RFC et la guidera tout au long du processus de révision de la RFC
comité de révision - un groupe de mainteneurs qui ont la responsabilité de recommander l'adoption de la RFC
Tout membre de la communauté peut aider en fournissant des commentaires sur la capacité du RFC à répondre à ses besoins.

Sponsors RFC

Un sponsor est un responsable de projet chargé d'assurer le meilleur résultat possible du processus RFC. Ceci comprend:

Plaider pour la conception proposée.
Guider la RFC à adhérer aux conventions de conception et de style existantes.
Guider le comité d'examen à parvenir à un consensus productif.
Si des changements sont demandés par le comité d'examen, assurez-vous qu'ils sont faits et demandez l'approbation ultérieure des membres du comité.
Si la RFC passe à l'implémentation:
- S'assurer que la mise en œuvre proposée adhère à la conception.
- Coordonner avec les parties appropriées pour réussir la mise en œuvre.

Comités d'examen RFC

Le comité d'examen décide par consensus d'approuver, de rejeter ou de demander des modifications. Ils sont responsables de:

Veiller à ce que les éléments substantiels des commentaires du public aient été pris en compte.
Ajout de leurs notes de réunion en tant que commentaires au PR.
Motiver leurs décisions.

La constitution d'un comité d'examen peut changer en fonction du style de gouvernance et du leadership particuliers de chaque projet. Pour le noyau TensorFlow, le comité sera composé de contributeurs au projet TensorFlow qui ont une expertise dans le domaine concerné.

Les membres de la communauté et le processus RFC

Le but des RFC est de s'assurer que la communauté est bien représentée et servie par les nouvelles modifications apportées à TensorFlow. Il est de la responsabilité des membres de la communauté de participer à l'examen des RFC lorsqu'ils ont un intérêt dans le résultat.

Les membres de la communauté intéressés par un RFC doivent:

Fournissez une rétroaction dès que possible afin de laisser suffisamment de temps pour la réflexion.
Lisez attentivement les RFC avant de fournir des commentaires.
Soyez courtois et constructif .

Implémentation de nouvelles fonctionnalités

Une fois qu'une RFC a été approuvée, la mise en œuvre peut commencer.

Si vous travaillez sur un nouveau code pour implémenter un RFC:

Assurez-vous de comprendre la fonctionnalité et la conception approuvées dans la RFC. Posez des questions et discutez de l'approche avant de commencer le travail.
Les nouvelles fonctionnalités doivent inclure de nouveaux tests unitaires qui vérifient que la fonctionnalité fonctionne comme prévu. C'est une bonne idée d'écrire ces tests avant d'écrire le code.
Suivez le guide de style de code TensorFlow
Ajoutez ou mettez à jour la documentation API pertinente. Faites référence à la RFC dans la nouvelle documentation.
Suivez toutes les autres instructions énoncées dans le fichier CONTRIBUTING.md dépôt de projet auquel vous contribuez.
Exécutez des tests unitaires avant de soumettre votre code.
Travaillez avec le sponsor RFC pour réussir à obtenir le nouveau code.

Garder la barre haute

Alors que nous encourageons et célébrons chaque contributeur, la barre d'acceptation RFC est maintenue intentionnellement élevée. Une nouvelle fonctionnalité peut être rejetée ou nécessiter une révision importante à l'une de ces étapes:

Conversations de conception initiales sur la liste de diffusion appropriée.
Défaut de recruter un sponsor.
Objections critiques pendant la phase de rétroaction.
Ne pas parvenir à un consensus lors de la revue de conception.
Problèmes soulevés lors de la mise en œuvre (par exemple: incapacité à atteindre la compatibilité ascendante, problèmes de maintenance).

Si ce processus fonctionne correctement, les RFC devraient échouer dans les étapes antérieures plutôt que ultérieures. Une RFC approuvée ne garantit pas un engagement à mettre en œuvre, et l'acceptation d'une implémentation de RFC proposée est toujours soumise au processus habituel de révision du code.

Si vous avez des questions sur ce processus, n'hésitez pas à les poser sur la liste de diffusion des développeurs ou à signaler un problème dans tensorflow / community .