Nous n’avons pas vraiment fixé le périmètre de cette équipe.
Tout comme la @maintenance se limite aux dépôts git spip/* je pense que cette team devrait se limiter aux mêmes dépôts (+spip-league)
Des avis ?
Pas d’avis, pas de rôle 
Ici tu avais rédigé en introduction About the architecture category :
En gros, comment écrire du code plus robuste, organiser les fichiers, les dépôts (par composants), pour qu’il soit logique pour des dévs, en respectant au mieux les usages des communautés des languages respectifs.
Est-ce que ça convient aux 15 personnes de l’équipe ? Quels sont les manques ou choses en trop ?
Bonsoir à toutes et tous,
Alors, la description, que tu avais proposée, @JamesRezo, et rappelée par @b_b, me convient bien, je suis vraiment preneur !
Sur la question du périmètre, je pense que ce serait pas plus mal de se limiter aux seules « orgas » que tu cites, du moins dans un premier temps, afin de ne pas trop se disperser ; les pratiques proposées et mises en place pourront toujours infuser bien au-delà.
Donc, j’ajoute dans le About que c’est limité au 2 groupes git et c’est bon ?
La description actuelle ne concerne peu ou prou que l’infrastructure, où et comment on découpe notre code, quels composants externes on utilise ou pas, les processus de participation (comment on propose du code, comment on le vérifie humainement ou automatiquement etc).
Mais l’architecture logicielle c’est aussi (en tout cas ça peut aussi) être de définir et cadrer les API centrales, du vrai contenu de notre code mais bas niveau (contrairement à la team fonctionnelle plus haut niveau), non ? Ou bien on laisse ça à la team fonctionnelle ? Ou bien ya des sujets qui recoupent les deux ?
Pour moi, une infrastructure, c’est le réseau, ses règles, les machines qui sont dedans et leur système d’exploitation (au sens large) et les « services » qu’on fait tourner dessus.
Je ne crois pas que ça parle de processus de participation, ou alors j’ai pas compris ce que j’avais recopié ?
Je ne sais pas ce que tu entends par « API centrales »:
Au mieux, cette équipe peut émettre une opinion, un cadre pour produire des « web services » (API Web de SPIP ?).
Aussi, produire ou cadrer les APIs, au vrai sens du terme, des composants de SPIP que ce soit en PHP ou en JS … Tu parles de celles-là ?
Je ne comprends pas ce que tu veux dire par « vrai contenu de notre code », ni ce que tu entends par bas et haut niveau …
Enfin, on a encore rien vu du travail de la team fonctionnelle sur ce forum. On ne sait donc rien de ce qu’elle pourrait faire ou pas faire.
Je ne peux donc pas trop te répondre en l’état, mais oui, il y aurait intérêt à ce qu’il y ait un lien (non-hiérarchique de préférence et donc, sans haut ni bas) entre les 2 équipes.
Ce que je souhaitais fixer avant tout, c’est la limite « géographique » au delà de laquelle les membres de cette équipe n’ont pas à intervenir au nom de celle-ci, mais je crois que la réponse de @bricebou convient : spip/* et spip-league/* (c’est pour ça que les groupes git bien définis, c’est bien 
)