Source : zone.spip

Pour devenir commiter, 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.

Le développement des traductions de SPIP et de sa documentation officielle se trouvent ici ;
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.

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 :
– Règle ultralibérale : « chacun fait ce qu’il veut dans cette branche. Ajouter, modifier, effacer. » (sur une zone "bac à sable").
– 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@dupon.org, gir@blob.net »
– 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. »
– Règle "ad hoc" : « améliorez les CSS comme vous voulez, mais que personne ne touche au code, zerc@lili.il 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.

Il existe deux raisons qui justifient de forker un projet :
– Premier cas, 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.

Pour savoir ce qu’il ce passe dans Zone.spip, deux moyens sont possibles :
– trac fournis une page qui permet de tout suivre : timeline. Vous pouvez vous inscrire sur la liste SPIP Zone 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.

Télécharger :
– Files sur zone.spip
– Site de démonstration de spip-zone en SPIP 1.9