Comment contribuer à PHP: la Foundation sort le guide qu'on attendait tous
Et les RFC, ça fait un peu « comité secret dont on n'a pas le mot de passe ». Bonne nouvelle: la PHP Foundation vient de publier un guide complet qui détaille — enfin clairement — toutes les façons de contribuer au cœur de PHP, à sa doc, et à l'écosystème au sens large. Spoiler: écrire du C et proposer des RFC ne représentent qu'une infime partie du chantier.
On contribue… mais à quoi exactement?
Le guide pose d'entrée une distinction essentielle (et souvent mélangée dans les discussions de couloir): contribuer au projet PHP lui-même — le cœur, la doc officielle, les tests — c'est un chemin. Contribuer à l'écosystème PHP plus large — packages, outils, frameworks, formations — c'est un autre. Les deux sont légitimes, les deux sont nécessaires. Et surtout, la Foundation rappelle un point qui surprend toujours: elle ne possède pas PHP, ne gouverne pas son développement et ne dicte pas les RFC. C'est un projet open-source indépendant, avec ses propres contributeurs et sa propre gouvernance. La Foundation existe pour soutenir ce travail, pas pour le verrouiller.
On n'écrit pas forcément du C? Alors quoi?
C'est là que ça devient intéressant. Le guide dresse une liste concrète de contributions, classées par barrière à l'entrée croissante. Et franchement, les premiers échelons sont à la portée de n'importe qui parmi nous:
- Tester les préreleases. Chaque version majeure, mineure ou patch passe par des alpha, bêta et RC. Plus de code réel tourne dessus, plus on capte les régressions tôt. Vous maintenez un package? Branchez sa suite de tests sur la prochaine prérelease. Vous avez une app en staging? Pointez-la dessus.
- Signaler et reproduire des bugs. Un bug bien rapporté avec un cas de reproduction minimal, c'est déjà la moitié du fix.
- Écrire des tests. Ah, la couverture de tests du core… on en reparlera.
- Améliorer la documentation. Si vous avez déjà galéré sur un point obscur du manuel, vous savez exactement quoi corriger.
- Reviewer des PR et participer aux discussions internals. Pas besoin de merger: juste relire, commenter, apporter un regard.
Et oui, proposer des RFC et écrire du C, c'est le bout du chemin. Mais le guide insiste: ce n'est que deux options parmi beaucoup d'autres.
Tester sur master: le game changer discret
Un conseil que le guide distille et qui mérite qu'on s'y attarde: si vous maintenez un projet sérieux (PHPUnit et Xdebug le font déjà), branchez votre CI sur la branche master de PHP en continu, pas juste au moment des RC. Vous captez les régressions dès qu'elles atterrissent. Le guide met néanmoins en garde: ne bloquez pas votre pipeline là-dessus. Laissez le build master échouer sans faire sauter toute votre suite — on teste volontairement du code in-progress et non-released, c'est le principe.
Pour nous, devs PHP du quotidien
On a souvent l'impression que contribuer à PHP, c'est réservé à une élite de core-devs qui respirent le C et les macros Zend. Ce guide casse cette image. Il y a de la place pour tout le monde — du testeur de prérelease au relecteur de doc, en passant par celui qui réduit un bug bizarre en un script de 10 lignes. Et dans une communauté qui a lancé autant de carrières et d'entreprises, se poser la question du « comment rendre un peu » n'a jamais été aussi simple à transformer en action concrète.
Alors, la prochaine prérelease PHP, on branche quoi dessus?