Relecture d’un ERC : comment répondre aux objections
Quelqu’un affirme en public que votre spécification est fausse. Vous la défendez, ou vous demandez où elle échoue ?
EN 30 SECONDES
La relecture publique est la phase où des développeurs testent votre ERC et soulèvent des objections. Pour la passer, il faut surtout dialoguer : répondre à chaque commentaire de fond, corriger les vrais cas limites, consigner les compromis.
À RETENIR · 3
- Répondez à chaque commentaire de fond, et consignez les objections traitées dans la section Rationale.
- EIP-1 rend l’implémentation de référence facultative. Je livre quand même du code qui tourne avant la spécification.
- Un ERC adopté permet à des équipes qui ne se connaissent pas de bâtir des logiciels compatibles. Statut Final et adoption sont deux étapes distinctes.
Sur cette page
La relecture publique : répondre aux objections
EN BREF Faire accepter un ERC demande un travail de dialogue : vous construisez un consensus, vous ne gagnez pas un débat.
LES MOTS À CONNAÎTRE
- Ethereum Magicians
- Le forum de la communauté qu’EIP-1 désigne comme le lieu privilégié pour discuter d’une proposition.
- Rationale
- La section d’un ERC qui explique ses compromis : ce qui a été retenu, ce qui a été écarté, et pourquoi.
- Éditeur EIP
- Vérifie qu’une proposition est bien formée, complète et cohérente. Selon EIP-1, les éditeurs ne jugent pas l’idée.
EN CLAIR
Écrire le texte n’est qu’une partie du travail. Ceux qui codent ont aussi besoin d’un périmètre clair, d’exemples utiles et de réponses à leurs objections.
ÉTAPE PAR ÉTAPE
Étape 1. Objection. Quelqu’un dit que votre spécification est fausse. Ne la défendez pas tout de suite.
- Objection Quelqu’un dit que votre spécification est fausse. Ne la défendez pas tout de suite.
- Demander le scénario Demandez dans quel scénario votre spécification échoue. Faites décrire le cas, pas le désaccord.
- Cas limite D’expérience, c’est la plupart du temps un vrai cas limite auquel vous n’aviez pas pensé.
- Corriger Corrigez la spécification et remerciez la personne en public.
- Consigner Écrivez le compromis dans la section Rationale. Le relecteur suivant trouve la question déjà traitée.
La Rationale La section d’un ERC qui explique ses compromis : ce qui a été retenu, ce qui a été écarté, et pourquoi. Voir le glossaire devient la mémoire de la proposition. Répondez à chaque commentaire de fond, même quand vous refusez l’idée. « Hors périmètre pour cet ERC », plus deux phrases de contexte, c’est une réponse complète ; le silence, non.
- Trouvez des alliés. Si l’équipe d’un wallet veut implémenter votre ERC, dites-le dans le fil. D’expérience, cet intérêt concret fait plus avancer une proposition que la théorie.
- Menez la relecture comme un projet. Consultez votre fil chaque semaine et répondez à tout ce qui date de plus d’une semaine.
- Si le fil se tait pendant un mois, publiez un résumé et demandez quelles objections restent.
ADAM explique : Soyez patient sans avoir l’air absent. « Je prends deux semaines pour réfléchir à ces retours » n’a rien à voir avec un silence.
Dans la section suivante : Alors, que faut-il vérifier avant même d’ouvrir le fil ?
Ma méthode après trois ERC intégrés au dépôt
EN BREF Ce que je fais autrement aujourd’hui, après ERC-3643, ERC-6960 et ERC-7410.
Commencer par le problème, pas la solution
Avant toute interface, écrivez deux paragraphes sur le cas concret où les standards actuels échouent. Si vous n’y arrivez pas, l’ERC n’est pas prêt.
Livrer l’implémentation de référence avant la spécification
Mon travail sur la suite T-REX et OnchainID m’a donné l’expérience d’implémentation derrière ERC-3643. Validez la conception sur un cas réel avant de déclarer son interface stable.
Trouver au moins trois équipes qui en ont besoin
Avant de publier, contactez en privé des équipes du domaine. Sans trois réponses « oui, on a ce problème », réfléchissez encore.
Un ERC, un problème d’interface
ERC-3643 définit un cadre de jetons à accès contrôlé, ERC-6960 des soldes à deux niveaux, ERC-7410 la mise à jour des autorisations de dépense. Aucun ne remplace le reste d’une application.
Co-écrire quand les domaines se recoupent
J’ai conçu une couche de conformité et une structure de jeton à plusieurs niveaux, et j’ai quand même cherché des co-auteurs pour les angles morts.
Avant de publier sur Ethereum Magicians Le forum de la communauté qu’EIP-1 désigne comme le lieu privilégié pour discuter d’une proposition. Voir le glossaire, vérifiez trois choses : du code qui tourne, au moins trois équipes avec ce problème précis, et un seul problème d’interface. S’il en manque une, l’ERC n’est pas encore prêt.
OBJET OBTENU
Du code avant une interface stable
Pourquoi un standard survit à une fonctionnalité
EN BREF Une fonctionnalité reste dans votre code ; un ERC adopté se retrouve dans chaque base de code qui s’appuie dessus.
Une fonctionnalité livrée
Un ERC adopté
À mon sens, ERC-3643 est arrivé au statut Final parce que nous avons fait le travail ingrat : des fils de forum, des versions revues du texte, des réponses patientes aux relecteurs sceptiques. Le texte final n’en montre presque rien.
Dans la procédure ERC, la politique et le lien avec les gens font le gros du travail ; à côté, écrire la partie technique est facile.
Éditeur EIP Vérifie qu’une proposition est bien formée, complète et cohérente. Selon EIP-1, les éditeurs ne jugent pas l’idée. Voir le glossaire vérifient la forme et s’assurent que rien ne manque ; c’est la communauté qui décide du sort de l’idée.
Sources : EIP-1, ERC-3643, ERC-6960, ERC-7410.
FAQ
Oui. EIP-1 demande une liste d’auteurs, sans exiger de co-auteur. Sur une proposition complexe qui touche plusieurs domaines, des co-auteurs repèrent les angles morts.
C’est le forum qu’EIP-1 recommande pour discuter d’une proposition. EIP-1 recommande aussi de soumettre l’idée à la communauté avant d’écrire une proposition formelle.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Vous savez transformer une objection en correction : demander le scénario, corriger la spécification, consigner le compromis.
- Vous savez expliquer pourquoi un standard adopté va plus loin qu’une fonctionnalité, et pourquoi le statut Final ne suffit pas à le faire adopter.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Un relecteur écrit que votre spécification échoue avec les jetons qui prélèvent des frais à chaque transfert. Votre premier geste ?
Demander le scénario exact où elle échoue, avant de défendre quoi que ce soit. D’expérience, c’est souvent un vrai cas limite : corrigez la spécification, remerciez en public, et consignez le compromis dans la section Rationale.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.