[changement de "subject", cette discussion méritant d'être menée en
tant que telle]
Maintenant la zone, c'est ton jouet, donc si tu decides que dans les
contraintes, il y a "s'appuyer sur les projets existants => interdiction
de developper une fonctionnalité déjà couverte par un plugin", je n'ai
pas mon mot à dire.
Non, c'est la Charte qui définit ce qu'est spip-zone, ce n'est pas
"mon jouet". Et pour être clair, j'espère d'ailleurs que s'il me
venait à l'esprit de "casser mon jouet", vous reprendriez le flambeau
sur un autre serveur. Moi ce que je veux c'est que cette zone existe,
soit vivante, ouverte, bon esprit et constructive. La seule méthode
pour ça c'était de la monter moi-même, mais je n'en avais pas envie,
demande à Ben combien de fois je l'ai tanné pour que ce soit lui qui
la fasse...
Clairement, la charte n'interdit pas de faire des forks ni des
doublons. En revanche elle demande un "bon fonctionnement coopératif",
et souligne : *communiquer, prévenir les autres, etc.*. Et aussi que
**ce n'est pas chose facile, et en cas de problème il est important de
limiter le recours à la mauvaise foi**.
Ce que je constate, c'est que vous focalisez sur toggg à cause de son
langage, tandis que vincevg continue à commiter des "nouvelles
versions de fck" au moment même où se tient cette discussion. Là aussi
c'est une marque de mépris des autres développeurs de la zone, qui
n'est pas sans conséquence. J'en veux pour preuve ce message sur irc à
l'instant :
je peux plus faire un svn up
Can't convert string from 'UTF-8' to native encoding:
_plugins_/_stable_/FCKEditor/191/T?\195?\160F et en cours.txt
Qui s'inquiète de ce genre de problèmes parmi nous ?
Il faut reconnaître à toggg (sans vouloir défendre son langage) qu'il
s'en préoccupe beaucoup, et veille sans cesse à ce que la zone puisse
produire des paquets, à ce que rien ne "casse", etc.
Après ça, je ne m'associe pas à la forme virulente de sa critique, je
l'ai déjà dit. Mais c'est vrai qu'on peut se sentir démuni quand un
membre du réseau se permet d'ignorer toutes remarques et de continuer
comme un bulldozer dans son coin.
L'important c'est que les choses soient claires, et en l'etat,
l'attitude de Toggg ne me parait pas compatible avec la zone.
Et l'attitude de vincevg ? Si tu n'es pas équilibré dans ta critique,
ça ne permet pas d'avancer.
Mais pour ma defense, il y a accumulation ces derniers temps.
Si tu veux employer ce genre d'arguments, tu dois admettre, pour la
"défense" de toggg, qu'il y a accumulation ces derniers temps, aussi,
de commits je-m'en-foutistes.
Je reprend donc calmement la question : que se passe-t-il si Toggg met
effectivement ses menaces à execution et fait un remove d'un projet car
il considere qu'il devrait etre developpé autrement ?
Dans une telle hypothèse (hypothétique), il y aurait un conflit
aboutissant à la saisie formelle d'un comité (à constituer), qui
évaluerait la situation. Si ça ne tenait qu'à moi, ce serait comme
avec les mômes : tout le monde au lit ! 
Cela dit sans plaisanterie, je fais souvent le ménage, mais je n'ai
pas envie de faire la police. Si un commit bien foireux se présente
(quelqu'un commite par erreur, ou sans savoir ce qu'il fait, des
ressources inutiles), on nettoie sans état d'âme, en signalant le
problème. Ici on est dans un cas limite, et l'important serait de
*discuter*.
Comme d'ab, le mieux est d'avoir une regle, quitte à ne pas l'appliquer
sauvagement, ca evite d'avoir à arbitrer des conflits.
Sur un squelette comme FNSF, c'est assez simple : il y a des chemins en
dur, des logos, ... ca n'est pas réutilisable.
Ca serait sympa de laisser un delai (genre 2 mois), ca permettrait à
ceux qui veulent justement generaliser un squelette specifique de bosser
sur la zone, et d'eviter de servir d'espace de sauvegarde.
Mais ca peut se cadrer dans la charte d'usage.
Dans les deux cas il y a eu des mails publics et privés signalant
qu'il y avait un problème ; dans les deux cas, aucune réponse. Combien
de temps on laisse avant de fermer l'accès ? Qui en décide ? Est-ce la
bonne méthode ?
Pour FCK, c'est amha plus simple : interdire le report de fork d'autres
projets sur la zone.
Ben non, on a bien d'autres forks déjà, et le fork c'est une liberté
essentielle. La question c'est de savoir si c'est fait de façon
justifiée, logique etc.
Ou alors, c'est le principe d'un editeur WYSIWYG qui pose probleme,
Absolument personne ne dit ça ! Ce n'est pas du tout ça qui est en
question, c'est de savoir si on peut commiter sur la zone sans tenir
compte de l'avis des autres. Et de l'autre côté de savoir si on peut
supporter les échanges avec des mots virulents.
Je peux aussi vivre avec, mais par contre, je ne peux pas developper
sachant qu'un énérvé peut se permettre de supprimer mon boulot parce
qu'il ne lui plait pas.
Ta crainte c'est celle que des modifications visent à détruire plutôt
qu'à construire ; ce genre de modifications est clairement
hors-Charte, donc il ne devrait pas y avoir de problème de ce côté.
Enfin, reconnaissons qu'une petite crise c'est pas mal : ça permet de
préciser des choses qui sont de l'ordre de l'implicite. Il manque
sûrement des phrases dans la Charte, qui expliciteraient les notions
de "bonne pratique collaborative", notamment de "code générique",
"chercher des voies constructives", "éviter les violences verbales",
etc.
Et il nous manque ce "comité des sages" pour faire médiateur dans les
situations de conflit.
-- Fil