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

Le processus TensorFlow RFC

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

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

Être formaté selon le modèle RFC .
Être soumis sous forme de pull request au répertoire community/rfcs .
Faire l’objet d’une discussion et d’une réunion d’examen avant acceptation.

L'objectif d'une demande de commentaires TensorFlow (RFC) 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 modifications de conception.

Comment soumettre une RFC

Avant de soumettre une RFC, discutez de vos objectifs avec les contributeurs et les responsables du projet et obtenez des commentaires précoces. Utilisez la liste de diffusion des développeurs du projet concerné (developers@tensorflow.org, ou la liste du 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 descriptive-name se rapporte au titre de votre RFC. (Par exemple, si votre RFC est intitulée Parallel Widgets API , 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 au format 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 obligation, mais cela peut aider à concevoir des discussions.
Recrutez un sponsor.
- Un sponsor doit être un mainteneur du projet.
- Identifiez le sponsor dans le RFC, avant de publier le PR.
Vous pouvez publier une RFC sans sponsor, mais si dans le mois suivant la publication du PR, il n'y a toujours pas de sponsor, elle sera fermée.
Soumettez votre RFC sous forme de pull request à tensorflow/community/rfcs .
Incluez le tableau 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 RFC . Incluez les identifiants 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 prendre au moins 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 de révision. Suivez le format des mailings précédents, comme vous pouvez le voir dans cet exemple .
Le sponsor demandera une réunion du comité de révision, 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 en revue. L'objectif de la réunion d'examen est de résoudre des 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 de pouvoir l'examiner à nouveau. Les RFC approuvées seront fusionnées dans community/rfcs , et les RFC rejetées verront leurs PR fermés.

Participants aux 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 des RFC.
comité de révision - un groupe de responsables qui ont la responsabilité de recommander l'adoption de la RFC
Tout membre de la communauté peut aider en fournissant des commentaires indiquant si le RFC répondra à ses besoins.

Commanditaires du RFC

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

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

Comités d'examen des RFC

Le comité d'examen décide par consensus s'il convient 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.
Ajouter leurs notes de réunion sous forme de commentaires au PR.
Fournir les raisons de leurs décisions.

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

Les membres de la communauté et le processus RFC

Le but des RFC est de garantir 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 dont ils sont intéressés par le résultat.

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

Fournissez vos commentaires dès que possible afin de laisser suffisamment de temps pour l’examen.
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 une RFC :

Assurez-vous de bien 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 directives énoncées dans le fichier CONTRIBUTING.md du 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

Même si nous encourageons et célébrons chaque contributeur, la barre d'acceptation des RFC reste 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 lors de la phase de feedback.
Absence de consensus lors de la revue de conception.
Préoccupations soulevées lors de la mise en œuvre (par exemple : incapacité à obtenir une compatibilité ascendante, préoccupations concernant la maintenance).

Si ce processus fonctionne bien, les RFC devraient échouer dans les premières étapes plutôt que dans les étapes ultérieures. Une RFC approuvée ne garantit pas un engagement à la mettre en œuvre, et l'acceptation d'une proposition de mise en œuvre de la RFC 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 .