SpipContribV2ComparaisonDiscussion

Retour sur SpipContribV2Comparaison et SpipContribV2Propositions

Ajouter votre commentaire en bas avec votre pseudo est separateur


la proposition de [->NicolasR] - 10/10/2006

Bonjour
Bien que n’étant pas admin de spip-contrib ci-dessous ma contribution au débat sous l’angle de propositions de critères de choix et d’une ligne éditoriale affirmée (et visible) pour Spip-contrib. J’y inclus tout ce que j’ai compris des débats sur le sujet sur l’irc, des contributions ci-dessus, et de ma propre analyse , sans chercher à faire un mix équilibré entre les propositions des uns et des autres (je ne cite personne, mais chacun reconnaitra ses propres apports) ... vous en faites bien ce que vous voulez ;-)

Je suppose acquis, convergence la dessus me semble t-il :
-  la volonté de remanier assez profondément l’existant, de limiter la profondeur d’arborescence et d’utiliser aussi les mots clefs dans la nav. Le débat porte sur le contenu des rubriques principales. J’ai vu aussi passer aussi des questionnements sur les espaces des différentes langues.
-  une rubrique principale : Spip contrib mode d’emploi - A propos de SPIP-Contrib - Fonctionnement et actualité de SPIP-CONTRIB (peu importe le nom facile à changer, le contenu est clair)
-  au moins une rubrique principale pour les squelettes
-  au moins une rubrique principale pour les plugins

A) D’abord c’est quoi Spip-Contrib du point de ses utilisateurs

Je cite :
-  selon http://www.spip.net/fr_download : SPIP Contrib’ est le site de référence de la communauté utilisatrice de SPIP. Vous y trouverez tout ce que vous cherchez, astuces, squelettes, etc. Vous pouvez aussi y apporter les vôtres !
-  selon http://www.spip.net/fr_rubrique116.html : De nombreux utilisateurs de SPIP tiennent à jour le site des contributions externes SPIP-CONTRIB : c’est une mine d’informations et de solutions à des problèmes variés.
-  selon http://www.spip-contrib.net/ : Spip contrib a pour vocation de permettre la mutualisation des ajouts développés par les utilisateurs autour de SPIP. Il peut s’agir de squelettes entiers, comme de fonction [1]alités supplémentaires, à ajouter sous forme de plugins, de filtres ou de boucles à inclure dans vos squelettes.

Mais aussi, ca été dit sur les listes zone et dev, Spip-contrib est destiné à etre le centre de documentation « officielle » de tout ce qui sort de manière utilisable de la zone (Plugins avant tout de fait, mais aussi squelettes, themes, etc ...), bref de tout ce qui n’est pas le Core, et qui va se présenter sous la forme de sous-ensemble à placer dans les répertoires « Plugins » ou « Squelettes »

Spip-contrib est multilingue, et doit le rester me semble t-il dans la logique d’etre une site de référence, mais ses différents espaces de langues ne sont pas forcément gérés pareil (ca dépend de leurs admins), sinon ça va être trop lourd de mettre tout le monde d’accord.

Il y a donc trois approches utilisateurs :

-  L’approche des contributeurs, un minimum avertis de Spip par nature, abordant Spip-contrib via son espace de rédaction et qui s’attendent pour certains à y retrouver leurs processus de travail précédents : "j’ai développé mon plugin/squelettes/etc... en autonomie, je veux faire pareil pour sa doc" (d’autant plus quand il s’agit de mises à jour de trucs déjà validés, ou de plugins déjà en production) ; J’ai un truc dans "/Plugins" de la Zone ou je le met, normalement dans "/Plugins" de Spip-Contrib, etc ... Pour espérer motiver ces contributeurs, il faut leur donner le maximum d’autonomie dans leur espace propre (sinon prolifération comme maintenant des sites persos de doc de plugins ou squelettes). Le raisonnement est moins vrai pour les contributeurs plus occasionnels.

-  L’approche des utilisateurs consommateurs, abordant Spip-contrib via son espace public, et qui sont tous des webmasters (ou futurs) de site Spip. Leurs besoins et combinaisons des fonctions sont très variables, et ne peuvent être "à priori" contingentés, par exemple le plugin "Agenda" peut se retrouver dans de multiples usages. Leurs niveau de compétences sont très variables, et aussi évolutifs dans le temps . dans tous les cas il s’agit plutôt de donner des points de repères (mots clefs plutot qu’arborescence en dur par niveaux de compétence) à différent niveaux de compétence pour permettre la progression (fonction pédagogique). Il paraît nécessaire, pour ne pas les troubler, que l’arborescence de Spip-contrib ne développe pas un vocabulaire nouveau (continuité avec Spip.net et la Zone). Et à la fin des fins il faudra bien qu’il mettent leurs code récupérés dans un des fichiers ou répertoires de leur Spip, autant les y préparer.

-  L’approche des admins, débordés par nature selon le concept actuel de Spip-contrib, qui doivent impérativement pouvoir déléguer au maximum dès qu’un contributeur à fait un minimum ses preuves ... Ils ont besoin d’une structure de contenus assez souple pour recevoir des contenus imprévisibles, et d’un usage intensif des sous-rubriques ad-hoc pour pouvoir distribuer largement des droits d’admin restreint.

B) Spip-Contrib pour quelle version de Spip ?

Sacré question car les changements de la 1.9 ont frappé d’obsolescence pas mal de contributions, et cela risque de ne pas s’arranger avec les prochaines version de Spip. par exemple la rubrique documentation actuelle est largement dépassée, ou beaucoup de « Bidouilles » n’ont plus de raison d’être sous leurs formes actuelles. Tout cela introduit une vrai confusion pour l’utilisateur de Spip-contrib en l’état, qui est obligé de faire le tri lui même.

Pour préparer l’avenir à court et moyen terme, je propose d’affirmer le caractère « Post 1.9 » de Spip-contrib, y compris dans l’arborescence et la terminologie ... dans cette logique tout ce qui n’est plus valable pour la 1.9 est passé dans des rubriques archives et sorti de l’arborescence normale. Pour les contribs intéressantes les auteurs sont prévenus pour leur proposer de mettre à jour ... une sorte de « re-validation » en quelque sorte, un vaste chantier.

Dans cette logique « Post 1.9 », comme c’est déjà vrai pour les plugins, et risque de l’être encore plus à l’avenir avec la squelletisation de l’espace privé et autres développement en germe (jquery), la séparation "modification_espace_privé" vs "modification_espace_public" est de moins en moins adaptée, exemple le plugin « Agenda » impacte les deux ... donc ce critère n’est plus pertinent dans l’arborescence principale

C) Raisonner l’arborescence en tenant compte du squelette utilisé

Le squelette "dist" actuellement utilisé, de même que les anciens squelettes de spip-contrib (de mémoire), n’est pas adapté je trouve : ils donnent trop d’importance au coté nouveauté (trop de classement par date), secondaire ici. Aussi ils ne créent pas des espaces spécifiques à chaque langue.

Pourquoi ne pas utiliser, si c’est possible, un squelette façon "http://www.spip.net/?var_skel=2007", en rajoutant les commentaires d’articles, et avec un peu de variante cosmétique ? ... Le code du squelette est à jour, la structure de navigation est globalement adaptée (besoins similaires), et ca affirme une continuité pour l’utilisateur (A ce sujet si l’arborescence de spip-contrib évolue il y aura des liens à vérifier/corriger dans spip.net)

Un autre point est la lourdeur de gestion des mots clefs quand ils sont en trop grand nombre à affecter à chaque article (d’expérience ca tourne au pensum) ... je propose que les nouveaux mots-clefs utilisés pour la nav ci-dessous soient placés sur les sous-rubriques, plus stables ... ceux déjà définis pour spip-contrib actuels sont conservés en repères.

Les breves ? .. à la poubelle ou mis en archive ... le concept de breve n’est pas utile ici (et dépassé ??) .. si un sujet est utile, même bref, on en fait un article, ou on le compile dans un article existant (ou son forum) sinon à quoi sert-il ?

D) Premiers repères pour l’arborescence

A ce niveau ont peut déjà dire pour ce qui est de l’arborescence, en vrac :
-  un secteur par langue mais ensuite chaque secteur doit se comporter de manière autonome
-  pas de distingos genre : outils webmasters/outils rédacteurs ... tous les utilisateurs sont des webmasters
-  pas de classement par usage supposé en dur ... mais thématique par mots clefs en point de repère
-  si utile distinguer l’approche coté rédac, de l’approche coté public
-  coté espace rédac il faut retrouver le vocabulaire (nommage des rubriques) des répertoires de Spip (base de la programmation), de la doc officielle et de la Zone
-  pas de nommage de rubrique genre « divers », « coding party du (date) » (y’a quoi la dedans ?), « Tutoriaux techniques » (on s’en doute que c’est technique) ... Tout ça n’a aucun sens pour l’utilisateur de ce site
-  pareil pour « Bidouilles » .... dont le classement est un vrai souci d’ailleurs

E) Proposition d’arborescence sous forme de visite guidée

Je suppose un squelette façon "http://www.spip.net/?var_skel=2007"

donc
1) une langue par secteur, comme maintenant, on choisit sa langue ensuite c’est comme si on était dans un site spécifique, par exemple la recherche est limité à la langue ... ça ne pose pas de probleme dans l’espace de rédac, et coté public chacun linke directement sur sa langue .. le top serait d’avoir, comme sur spip.net, une url genre « spip-contrib.net/fr »

2) pour l’espace Français l’organisation suivante

    • Repères pour naviguer dans Spip
      • nota : cette rubrique contient quelques articles de référence, mis en valeur, pour que les nouveaux venus se répère ... faut avouer que c’est pas facile quand on arrive
      • les sites de références de la galaxie Spip : liste habituelle des dit sites et listes + commentaire minima sur leur contenu
      • le contenu de Spip-contrib : un résumé pour les nouveaux venus
    • Documentations
      • nota : la on met tout ce qui comprend plus d’explications que de code tout prêt ... les docs finalisées « de référence » sont plutôt à renvoyer sur spip.net
      • 01. Première publication
      • nota : organisation coté public et rédac idem = articles avec titres signifiants au premier niveau de leurs sous-rubriques
      • outils formation, tutoriaux débutant
      • question fréquentes
      • multilinguisme
      • redirection urls et le fichier .htaccess
      • multibase
      • multisite
      • doc plugins (pourrait être mis dans la rubrique plugins)
      • etc ... euh ???
      • le code de spip (compilateur)
      • archives : documentation pour les anciennes versions de SPIP, il se pourrait bien que les autres rubriques de documentation, y atterissent direct pour partie
    • Eléments pour personnaliser son squelette
      • nota : la on met tout les éléments de personnalisation qui peuvent atterrir dans le répertoire « /squelettes » de spip
      • 01. Première publication
      • nota : organisation coté public et rédac idem = articles avec titres signifiants au premier niveau de leurs sous-rubriques
      • Foire aux Boucles - ici je pense que la décomposition type cent20 qui duplique la doc spip.net n’est pas pertinente. par définition peuvent se trouver ici des combinaisons de boucles .. est-il utile de décomposer ?
      • Foire aux Modèles (?) - pour l’avenir
      • Filtres (mes_fonctions.php)
      • Icones et graphisme
      • Thêmes (?) - pour l’avenir
      • archives : boucles et filtres pour les anciennes versions de SPIP
    • Squelettes complets
      • nota : organisation coté rédac = tous les skels au 1er niveau dans une sous-rubrique spécifique chacun ... les 1res publications sont proposées à la racine, les admins créent la sous-rubrique ensuite
      • nota : organisation coté public = rubriquage sur mots clefs, un skel peut être dans plusieurs rubriques + liste par ordre alphabétique
      • EX de mots clés de menu : types blog - type portail - type vitrine - code simple, etc ... les admins rajoutent au fur et à mesure des besoins
      • archives : squelettes pour les anciennes versions de SPIP
    • Plugins
      • nota : la on met tout les trucs qui peuvent atterrir dans le répertoire « /plugins » de spip + les trucs comme sedna et spikini
      • 01. Première publication (régle)
      • nota : organisation coté rédac = tous les plugins (y compris leurs archives) au 1er niveau dans une sous-rubrique spécifique chacun ... ... les 1res publications sont proposées à la racine, les admins créent la sous-rubrique ensuite
      • nota : organisation coté public = rubriquage sur mots clefs, un plugin peut être dans plusieurs rubriques + liste par ordre alphabétique
      • EX de mots clés de menu : Agenda, liste diffusion et email, Authentification ; Sécurité ; cartographie ; diaporama ; portfolio ; audio ; video ; Intégration d’autres applications PHP : commerce ; gestion adhérents, wiki, rss, référencement, statistiques, etc .... à créer par les admins au fur et à mesure des besoins
      • archives : bidouilles pour les anciennes versions de SPIP
    • A propos de SPIP-Contrib - ou titre similaire
      • nota : mis volontairement à la fin, c’est pas un truc d’usage constant
      • voir les 3 propositions plus haut

voila, fini ... bon désolé pour la longueur


EraTional Globalement, je suis assez d’accord avec ton arborescence :
-  L’ajout de d’une rubrique « boussole » est peut etre utile pour les personnes qui se perdent ds la galaxie spip
-  L’intitule « éléments pour personnaliser squelette » est bien. d’accord aussi pour ne pas trop décomposer la rubrique boucles
-  je crois que la document contient trop d’elements : doc est sur doc.spip.org, multibase,site url peuvent etre regroupes :

    • tuto
    • cours
    • installation avancée
    • multilinguisme
      -  je suis contre le principe de 1re publication : cela ne veut rien dire de l’exterieur et on perd un niveau de hierarchie
      -  pour plugins, il faut reflechir sur l’affichage, si on choisit de ne pas placer de ss-rubrique il faut que les mots-cles apparaissent clairement avec un compteur d’articles liés à chaque mot clé (ex. voir page d’acceuil de internet de rue

on avance :)


[cy_altern : j’aime assez cette arborescence (idem EraTional, le truc des premières publications ne m’emballe pas, en revanche +1 pour la logique « Post 1.9 ») mais ce qui me pose problème (sur toute les arborescences proposées) c’est la place des contribs pas en français...

Le coup de secteurs séparés par langues c’est peut être plus pratique pour la gestion et pour pas noyer les contributeurs pas francophones dans la masse MAIS ça ne me paraît pas très fonctionnel pour l’utilisateur. Pour illustrer : si je cherche "le super plugin" qui correspond exactmeent à mes besoins développé par renatof (donc dans le secteur en italien), je ne vais pas le trouver vu qu’il ne sera pas visible dans l’arbo en français...

Par ailleurs, Goetsu et Klike ont bossé sur le squelette de contrib il y a déja un petit moment : c’est disponible ici : http://trac.rezo.net/trac/spip-zone...
]


EraTional : pour l’organisation des langues, un secteur racine par langue est en effet bcp plus simple a organiser. j’aime bien l’opion du nouveau http://www.spip.net avec le bandeau de langue]
avec les liens de traductions avec une utilisation fine des liens de traductions, on peut peut etre sans sortir pour lister les contribs non traduites :
-  soit : lorsqu’on est ds une rubrique donnée, on peut afficher qq chose du genre : « articles disponibles ds d’autres langues non traduits » (boucle un peu complexe a ecrire)
-  soit : en creant systematiquement des articles virtuels en attendant la traduction


Organisation par cible pour éviter une arborescence trop complexe - Baptiste - 11/10

On pourrait mettre en place un groupe de mot-clés « version ». À chaque article, on associerait la(es) version(s) de SPIP compatible(s). Un groupe « cible » également, et à chaque article, on associerait un profil : « utilisateur », « développeur », « bidouilleur ».
Ensuite, sur chaque page de rubrique, un encart bien visible qui permette de trier les articles par version ou/et par profil grâce aux mot-clés. Comme ça, on peut mettre dans une même rubrique des articles aux finalités différentes sans perdre l’utilisateur, puisqu’il peut en un clic trouver les articles qui correspondent à ce qu’il veut faire. Ça permet aussi de basculer très facilement d’un public à un autre - donc de types d’articles - sans changer de secteur.
Une rubrique « question fréquentes » par exemple ne sera pas pertinente si elle est destinée à un bidouilleur et qu’un utilisateur basique la visite. Il ne se demande surement pas fréquemment comment créer sa propre balise (par exemple...). À l’inverse, un bidouilleur n’a pas forcément besoin de savoir que pour garder les articles n’ayant que 30 jours, il faut utiliser le critère age. Mais les deux ont pourtant éventuellement leur place dans une rubrique « questions fréquentes ».



Nat33 (12/10) : suite à la discussion sur la proposition de [->NicolasR]

Je regrette juste la segmentation Elements de personalisation (filtres, boucles etc... = "bouts de squelettes") / Plugins -> à nouveau on discrimine en fonction de l’emballage et non de la fonctionnalité. du coup si je cherche une fonction... je devrais aller fouiller dans deux rubriques, vu que je peux aussi mettre un "bout de squelette" en plugin. Et si je mets un squelette complet en plugin ?

Sinon la boussole, c’est une une vraie bonne idée. On manque vraiment de guide sur spip. y mettre FAQ, "première visite etc...

pour la partie documentation : effectivmeent il y a des "fonctionalités", comme le multi linguisme, qui sont plutot à gérer sous l’angle "how to" que comme une contrib. Mais dans ce cas pourquoi ce type de doc avancée devrait etre géré par spip contrib et pas par spip net ?
On est à la limite de notre domaine d’application.
spip contrib doit pouvoir proposer des exemples, illustrations, animations, turoriaux... mais pas refaire la doc.
On dira que c’est un peu comme la foire aux boucles. On explique les bases sur spip net, maintenant c’est sympa de trouver un exemple de boucle un peu chiadée de menu ou d’agenda etc...

La partie graphisme m’interpelle. on l’avait un peu sous estimée. mais effectivment, pourquoi pas une partie + ciblée, interface, css, modeles images coté "habillage du site". toutefois coller ça au millieu des filtres et des boucles... :/

bref je reste attachée à l’approche fonctionnelle "pour quoi faire" , donc je pense qu’il faut revoir elements de perso et plugins, je préferais l’apellation "modules à installer" de EraTional (plugin, filtres, boucles... ça sera du mot clé)

Pour les secteurs on dégage un consensus (il me semble...)

  • Boussole ou repères (Accueil, guide, Faq ...)
  • Squelettes complets (à tagguer )
  • Modules complémentaires à installer (-> rubricage large cf EraTional + mots-clés /Tag)
  • Actu et communauté spip contrib
  • Doc (tutos et exemples)

    ..
    Et pourquoi pas
  • Habillage (images, icones, css)

Si quelqu’un sait faire focntionner une ancre sur le spikini... qu’il n’hésite pas à corriger ce que j’ai mis ... ça marche pas :(


EraTional Nat33, l’ensemble cela me semble bien. Pour habillage pour l’instant j’eviterai de la placer à la racine squelette / habillage / theme (cf bones) les debutants vont tout confondre ...

ok : déja que pour les anciens c’est pas évident... (Nat33)


Nicolas R (12/10) ... En complément de la synthèse de Nat33 du 12/10 j’ai noté que sont aussi en débat, ou à valider plus explicitement

La gestion du multiliguisme

la remarque de cy-altern plus haut me paraît particulièrement pertinente : Le coup de secteurs séparés par langues c’est peut être plus pratique pour la gestion et pour pas noyer les contributeurs pas francophones dans la masse MAIS ça ne me paraît pas très fonctionnel pour l’utilisateur. Pour illustrer : si je cherche "le super plugin" qui correspond exactmeent à mes besoins développé par renatof (donc dans le secteur en italien), je ne vais pas le trouver vu qu’il ne sera pas visible dans l’arbo en français...

... dans cette logique la langue n’est pas un critère pertinent d’arborescence principale ... d’autant plus qu’un « module à installer » peut être internationalisé par nature (ex "forms" en cours de traduction je crois) ... si l’on admet le principe un « module à installer » ou un « squelette complet » = une sous-rubrique spécifique, alors pourquoi pas tout simplement mettre dans cette sous-rubrique tout ce qui concerne le dit module, y compris les différentes traductions de sa doc ?

Reste le cas des secteurs : Boussole, Actu et communauté spip contrib, Doc ... peut être pour chacun de ces secteurs, une rubrique principale par langue (et le français par défaut si pas de trad) ?? . Les titres des secteurs, rubriques, et sous-rubriques devront être signifiants dans différentes langues ou traduis au moins coté public (blocs multi ... pas facile à maintenir ???)

Il ne faudra pas oublier aussi de traiter l’affichage (coté public) des mots clefs sur sous-rubrique de modules, servant à la navigation par thèmes, dans différentes langues, sinon ce mode de navigation risque d’être incompréhensible pour les non-francophones. Coté espace de rédac il faudra aussi mettre des points de repères (dans les descriptifs de mots clefs ?) sur ces mots clefs pour les admins non-francophones ... à moins d’imaginer un groupe de mot clef par langue, mais ça paraît lourd à gérer

Nat33 (13/10) Multilinguisme

Une autre option avait été évoquée irc avec pierre renato et fil et je sais qui cy-altern, ben etc... :
c’est celle de laisser à chaque communauté étrangère la responsabilité et la liberté de gérer et animer son propre spip contrib.

-  Les avantages avancés sont les suivants :

  • autonomie pour la communauté étrangère,
  • émulation de devoir animer et alimenter un site de façon automome,
  • lisibilité du contenu dans chaque langue

-  Les inconvénients...

  • ben faut fouiller das les sites des autres langues, masi avec le super moteur de recherche on devrait pouvoir y arriver facilement
Renatof sur irc #spip (14/10) Multilinguisme - reporté par Nicolasr
-  renatof : re
-  nicolasr : tu préfere une langue=1 secteur ; 1 langue = 1 site spip-contrib ; tout mélangé ?
-  renatof : well, I think that having one site is good, if not to track translation links between articles
-  renatof : if not..at least

Nicolas R (12/10) ... En complément de la synthèse de Nat33 du 12/10 j’ai noté que sont aussi en débat, ou à valider plus explicitement (suite)

La validation ou non du principe un module/skel=une sous-rubrique spécifique
regroupant tout ce qui concerne la dite contrib (y compris anciennes versions qui ne passent pas en archives), avec droits d’admins restreint à l’auteur pour qu’il gère son sujet ... si c’est oui ça peut être commencé dès à présent sans attendre la finalisation de l’arbo ... c’est assez long à faire et déjà ca fera une premiere passe de tri.

L’affirmation ou non de la ligne éditoriale « post 1.9 »
qui va impacter complètement la manière de ranger les contribs existantes dans la nouvelle arbo. Si c’est oui, une bonne partie de l’existant bascule direct en archives (genre « Bidouilles ») et est sorti de la nouvelle arbo principale (y compris des mots clefs nouveaux) ... si c’est non bah je sais pas trop (au moins faut taguer à tour de bras par versions pour que le visiteur s’y retrouve).

Expliciter le domaine de spip-contrib question doc générale
c’est une idée qui revient dans les avis précédents : "la document contient trop d’éléments, ca devrait être sur spip.doc ", "Mais dans ce cas pourquoi ce type de doc avancée devrait etre géré par spip contrib et pas par spip net ? On est à la limite de notre domaine d’application" ... Ce critère est fort et impacte directement l’arbo et les rangements dedans, il faudrait le stabiliser assez vite (pourquoi pas avec des exemples précis)

Le choix du type de squelette
dans la pratique le squelette utilisé à une influence aussi sur l’arbo (exemple : cas des langues) ... serait-il possible d’installer sur spip-contrib (ou une copie de test) des variantes e skel proposés, histoire de se rendre compte "pour de vrai", selon le mécanisme de "http://www.spip.net/?var_skel=2007" ou du switcher (réservé aux admins)


L’instit - 13/10/2006
Je ne vais pas faire de nouvelle proposition, c’est un peu tard. Je me suis largement exprimé sur IRC pour défendre la proposition d’origine de Nat 33, mais les autres propositions la complètent en partie. Ce qui me semble important, c’est de défendre l’entrée par fonctionnalité et le principe que « Qui peut le plus peut le moins ».

L’entrée par fonctionnalité parce que le public qui peut avoir du mal à se débrouiller avec Spip, c’est le webmaster « de base », qui manipule un peu Dreamweaver ou un autre éditeur Wysiwyg, a quelques notions de code html, voire de css, et on lui a parlé de Spip, ce formidable système qui lui simplifiera la vie, mais quand il l’installe, il a du mal à voir toutes ces fonctionnalités extra dont on lui parle ou qu’il voit en regardant par exemple, les exemples de sites référencés sur Spip.net. il faut donc qu’il puisse identifier clairement à quoi va lui servir tel plugin ou contrib, et pas sa nature. Il faut aussi évidemment qu’il identifie si l’utilisation de cet élément est à sa portée.

Qui peut le plus peut le moins, donc, l’internaute débrouillé trouvera l’info ; je parle ici moins de développeur que de débrouillé dans l’utilisation de moteurs de recherches ou de réseaux de renseignements comme les listes. En croisant les infos données par les listes users, zone, devel, et l’utilisation pertinente de Google, si une info existe, une contrib, on la trouvera, et probablement pas directement en passant par la page d’accueil de Spip-contrib. Donc, encore une fois, il me semble important que cette page d’accueil soit conçue surtout pour les néophytes.

Tous ceux qui se sont exprimés avant moi ici ont énoncés des principes qui me semblent importants ; je précise ma position sur différents points :

-  Spip-contrib rénové doit être articulé autour de la 1.9, parce qu’aujourd’hui, je ne vois pas de raison de ne pas mettre à jour les sites sous les versions antérieures. Il n’y a plus de problèmes, je crois, de compatibilité au niveau des hébergeurs, et l’apport des plugins et des nouvelles fonctionnalités est suffisamment fondamental pour encourager tout le monde à migrer. Il est par ailleurs évident que Spip est plus facile à utiliser et personnaliser dans cette dernière version. Quelqu’un qui se met à Spip aujourd’hui en bavera moins qu’en 1.7, pour créer des squelettes particuliers et personnaliser son interface et sa navigation.

Il me semble important donc que cette incitation à la mise à jour apparaisse clairement et que les articles facilitant la migration soient repris et mis en avant (nettoyage racine, squelettes, etc...)

-  la plupart des bidouilles, et en tous cas celles modifiant le noyau des versions antérieures doivent disparaître. Je ne crois pas qu’il en reste qui soient justifiables sur une version récente.

-  la disparition des brèves ? pourquoi pas, mais il faudra bien garder un système (articles brefs ?) qui permette de présenter sur contrib des infos importantes qui sont ailleurs ; ex : tout le travail sur le graphisme de Paris-Beyrouth, les astuces et analyses de balluche, igor, 3studio, et des webmastrices de choc (Alex, Nat, Romy, etc...) par exemple ; on peut pas citer tout le monde. Ces contribs, qu’elles soient sous forme de docs ou « astuces », on va pas les réécrire pour Contrib. Mais il faut qu’on puisse les trouver. Tapez donc « habillage image » et cherchez en choisissant galaxie spip. Avez-vous la réponse qui vous envoie sur les écrits d’Arno ? non !!?? mais peut-être avec le lien vers la rubrique Images qui apparaît à droite ? non plus. Au-delà de l’interface, il y a donc là un vrai travail d’inventaire.

-  le problème du secteur par langue est épineux : effectivement, si un plugin génial est qu’en italien, et que dans le secteur italien, ce serait bien qu’on puisse le trouver depuis l’entrée française, MAIS si il n’y a pas de doc, que le fichier xml de description une fois installé est qu’en italien, ça fera une belle jambe à pas mal pour l’utiliser. Donc, si on référence ça en français, il va falloir se taper la traduction de la doc, à condition que les Renato ou autres la pondent. ( à la limite, c’est un truc que je veux bien prendre, ça)

-  un détail, mais foire aux boucles, ça fait un peu... foire, peut-être que bibliothèque de boucles et bibliothèque de modèles, ça ferait plus sérieux ?

-  les squelettes, c’est un vrai problème : on le voit bien avec les derniers squelettes qui sont en proposition dans contrib et qui ont donnés lieu à une certaine « moquerie » sur IRC. Considère-t-on que les squelettes sont référencés parce qu(ils apportent des fonctionnalités particulières, un type de site (blog, scolaire, asso,...) ou ce sont des thèmes graphiques. C’est pas du tout pareil même si certains peuvent avoir (et ont) les deux intérêts. A rapprocher de la réflexion de Nat sur une partie graphisme.

-  la galaxie spip : pour celui qui débarque, c’est un terme complètement opaque. Ca recouvre quoi ? les sites « officiels », tous les sites qui causent de spip ? pas évident.

-  trop vague aussi, les notions de « débutant, débrouillé, ou développeur » pour donner la difficulté d’une contrib. Il me semble qu’il seraait plus parlant qu’en en-tête de chaque contrib, il y ait une liste de « pré-requis ». C’est plus lourd pour le rédacteur mais plus précis.

-  quelle que soit l’arbo et la technique de rangement choisie, il est important d’avoir à l’esprit que pour l’instant, le « novice » qui débarque sur contrib, il cherche et parfois trouve des outils complémentaires à la version de base (ou de la doc, mais ça me semble moins poser problème) ; quand il trouve ce qu’il cherche ou à peu près, parfois, il y a plein de messages de forum dessous de mecs qui ont essayé de le mettre en place et qui ont loupé, parce que forcément, l’auteur de la contrib, il a bidouillé un petit truc en plus qu’il a oublié de mettre dans son article ; dans l’idéal, il faudrait donc que les contribs qui sont validées, elles le soient pas juste parce qu’elles paraissent simples à mettre en oeuvre, mais parce qu’on a vérifié que sans manip particulière non explicitement décrite dans la doc, un utilisateur lamba peut la mettre en place et qu’elle fonctionne. Mais ça, c’est du boulot.Et je ne dis pas que c’est facile. Ca nécessite certainement de trouver plus de validateurs ou de faire des équipes validateurs+testeurs. Il faut que les testeurs se mettent dans la peau du novice :

  1. J’installe un spip (distib de base)
  2. Je télécharge la contrib
  3. j’envoie les fichiers par ftp
  4. je suis à la lettre les indications de l’auteur de l’article
  5. Ca fonctionne impec

-  Tout à fait d’accord pour souligner l’importance du squelette. Le squelette actuel est parfait pour la dist de spip, notamment parce qu’il donne un aperçu des différents types d’info que peut proposer un squelette, mais sur contrib, il perturbe la lecture et disperse les informations importantes. On a pas besoin des commentaires de forum en page d’accueil, par exemple, ni des brèves dans les rubriques.

-  pour finir, sur IRC est revenu à plusieurs reprises l’idée que « tout le monde s’en fout ». Je ne crois pas que ce soit le cas. Mais dire à des gens qui pourraient avoir envie de donner un coup de main qu’on les attend en annonçant : « on en cause sur irc ce soir 21 heures, venez nombreux », c’est un peu marcher sur la tête. La première fois que j’ai vu ça, mon réflexe a pas été : « chouette, j’y vais », mais « IRC, c’est quoi c’te bête ». Il a déjà fallu que je cherche ce que c’était, que je trouve comment me connecter, que je télécharge chatzilla, et que une fois connecté, je comprenne comment on s’en sert. Quand on organise un colloque ou une conférence là ou je bosse, on envoie aux participants potentiels les horaires, mais aussi un plan d’accès, les possibilités de parking , etc...Y a t-il une doc sur spip-contrib qui explique comment les gens qui veulent discuter du truc peuvent retrouver les habitués sur IRC ? Je sais, rien à voir avec spip, mais les outils, faut les donner. (je ne reproche évidemment rien à personne en disant ça, je cherche ou ça coince). Passer par la liste users pour demander régulièrement qui veut participer me semble une bonne piste.

Notes

[1tient il manque un « n » sur spip-contrib à cet endroit

Discussion

Aucune discussion

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom