fr-Questions fréquentes

Q: Que devient spip-contrib ?

R: ​SPIP Contrib reste le site qu'on connaît, il propose des contribs, des trucs des astuces, des bout de docs, un peu de tout quoi . Par contre les "grosses" contribs ou les contribs qui gagneraient à bénéficier d'un système d'archivage tel que trac et donc d'un travail communautaire passe sous trac.

Q: Que devient spip-lab ?

R: c'est aux participants et animateurs de ​spip-lab d'en décider ; ce site peut accueillir toutes les contributions actuellement présentes sur spip-lab, mais n'a pas forcément vocation à «absorber» tout ce qui se fait autour de SPIP.

Q: Comment devenir commiter ?

R: Il faut postuler auprès de l'équipe des commiters, qui prendra en compte les critères suivants :

• les besoins courants de recrutement (inutile d'être trop nombreux)
• le fait d'avoir "fait ses preuves" dans la communauté, sur spip-contrib ou sur spip-dev par exemple
• le caractère désintéressé de la démarche
• l'absence d'incompatibilité de toute nature
• l'accord du postulant avec la Charte de spip.org
• la présentation d'un projet à commiter, qu'il s'agisse d'un nouveau projet à apporter sur le serveur, ou de participation à un projet existant (avec l'accord des responsables du-dit projet).

Il faut aussi avoir démontré un minimum de compétence technique avant de commencer à intervenir en-dehors de la zone du projet que l'on apporte, avoir conscience de l'écologie du projet, et respecter scrupuleusement le système de droits d'intervention défini ci-dessous.

Q: Et les traductrices et traducteurs ?

R: le développement des traductions de SPIP et de sa documentation officielle se trouvent sur ​http://www.spip.net/rubrique4.html ;

• pour traduire la partie officieuse de la doc (la partie spip.org), il suffit de s'inscrire sur spip.org puis de commencer à éditer les pages correspondantes dans le wiki

• pour traduire et internationaliser les contribs, il faut devenir commiter, et maintenir d'un côté un module spécialisé dans l'interface de traduction de spip.net, et de l'autre (sur SVN) implémenter les appels à la fonction _L() ou _T(). Ces deux types d'activités peuvent être menées par des personnes différentes.

Q: Droits d'intervention (et de commit)

Une fois accepté comme commiter, on reçoit un login (qui est en fait son email), et un mot de passe spécifique à subversion; ce mot de passe permet, sur le plan technique, de commiter dans l'ensemble de l'arborescence des fichiers installés dans le repository subversion.

CELA NE SIGNIFIE PAS QU'ON A L'AUTORISATION DE COMMITER PARTOUT.

Chaque branche (ou sous-branche, voire même fichier) de l'arborescence est maintenue par une ou plusieurs personnes, qui définissent les règles d'intervention pour cette branche. Ces règles peuvent éventuellement êtres fluctuantes dans le temps, au gré de la composition des équipes de dév, ou en fonction d'impératifs comme la stabilisation d'un projet, par exemple, ou pour toute autre raison.

Il est *essentiel*, avant d'intervenir sur un fichier, de prendre connaissance des règles d'intervention liées à ce fichier, en remontant dans l'arborescence, à partir du fichier en question, jusqu'à trouver un fichier nommé _REGLES_DE_COMMIT.txt' ; il est obligatoire de se conformer strictement à ces règles.

Les règles peuvent aller d'une extrême liberté à une extrême besoin de contrôle. Par exemple :

1. Règle ultralibérale : « chacun fait ce qu'il veut dans cette branche. Ajouter, modifier, effacer. » (sur une zone "bac à sable").

1. Règle ouverture maximum dans le cadre d'un projet précis : « chacun est libre d'*améliorer* ce projet en intervenant directement ; en cas de doute écrire aux responsables de la branche : toto@…, gir@… »

1. Règle "contrôle strict" : « nul ne peut intervenir sur les fichiers de cette branche sans avoir au préalable envoyé un patch au format diff -pu aux responsables de la branche, et reçu de l'un d'eux un "OK" formel. »

1. Règle "ad hoc" : « améliorez les CSS comme vous voulez, mais que personne ne touche au code, zerc@… est la seule à modifier du code sur cette branche (envoyez-lui vos propositions de patches, elle les intégrera) ; en ce qui concerne les fichiers extension_xxx.php, en revanche, n'hésitez pas à les modifier ou en ajouter, sans demander d'autorisation préalable. »

Etc. Si un ensemble de règles émergent, on essaiera de penser à les formaliser un peu, histoire de ne pas avoir un casse-tête impossible :)

Remarque : Il est techniquement possible, avec subversion, d'installer un script qui vérifie qu'un "commit" est conforme à telle ou telle règle binaire, du genre "untel peut commiter ici mais pas là". Mais ça n'est pas très simple à configurer (d'où un manque de "fluidité"), surtout si le script doit juger de la pertinence de telle ou telle intervention (si on peut corriger une virgule ou ajouter un commentaire, mais pas modifier la css, ou l'inverse...).

Mais si l'on ne réussit pas à se coordonner avec ce système de règles d'intervention, ce n'est pas une mesure technique qui permettra de sortir de l'impasse.

Q: Quand faut-il forker un projet ?

R: Si, pour des raisons techniques ou esthétiques, il est impossible de faire autrement, il faut forker -- par exemple, pour changer la couleur d'un squelette, l'internationaliser ou y ajouter un module, il est en général inutile de forker... en revanche s'il s'agit de changer la nature du projet (transformer le "bouton mémo" en "outil à tout faire dans spip de l'extérieur"), il faut probablement forker.

Deuxième cas, si après avoir discuté avec la personne responsable du projet, celle-ci fait la sourde oreille ou maintient sa position, il faut réfléchir aux arguments apportés :-) et ensuite pourquoi pas forker.

Q: Comment savoir ce qu'il ce passe dans Zone.spip ?

R: deux moyens possible :

• trac fournis une page qui permet de tout suivre : timeline
• Vous pouvez vous inscrire sur la liste ​spip-dev qui permet de dicuter à propos de la Zone
• Enfin si vous voulez recevoir la liste des commit par email, vous pouvez vous inscrire sur la liste ​SPIP Zone-commit

Q: Les plug-in proposés sur Zone.SPIP ont-ils été testés sur les validateurs du W3C et sont-ils conformes aux standards du Web ?

R: ...

en-FAQ