Wikini:SuggestionsDeRoadMapParOlivierB

Pour info, il y a déjà une feuille de route (roadmap) sur la page OuEnSommesNous et les sujets sont sensés être discutés sur la page SujetDuMoment. -- ProgFou

Mes suggestions (OlivierB) pour l'évolution de WikiNi à la date du 19/11/04

Tout d'abord, je ne suis pas membre des programmeurs de WikiNi donc mes suggestions valent ce qu'elles valent. Bon nombre d'entre elles ne sont d'ailleurs pas de moi, mais sont récupérées parmi les nombreuses suggestions / contributions proposées sur WikiNi.net.

Ces suggestions ont pour objectifs :

Rendre le WikiNi plus modulaire et permettre ainsi une évolution rapide de l'application par l'ajout de modules optionnels. De cette manière, éviter de patcher à tout va le moteur WikiNi et ainsi éviter les problèmes d'incompatibilités avec les versions futures de WikiNi.
Améliorer la gestion des utilisateurs et de la sécurité. à voir peut être la possibilité d'interfacer les utilisateurs/mots de passe avec d'autres applications.
Disposer d'une interface d'administration correcte. L'interface d'administration pourrait être indépendante du Wiki (comme dans Spip) ou être une partie du Wiki avec un accès restreint.
Protéger le contenu contre les malveillances.
De proposer une RoadMap? pour WikiNi.

Etape 1 : Revoir la gestion des utilisateurs

Permettre de différencier les différents types d'utilisateurs en créant des groupes. Les groupes par défauts pourraient être :
- Administrateurs : utilisateurs ayant tous les droits sous WikiNi (accès lecture, modifications, suppressions quelque soit les droits associés à la page). Les administrateurs auront en plus les droits d'administrations (interface d'administration, création/suppression d'utilisateur, gestion des droits utilisateurs, ...) au fur et à mesure qu'ils seront implémentés.
- Modérateurs : Les mêmes droits que les administrateurs en ce qui concerne les droits d'accès aux pages. Pour le reste des fonctionnalités, les modérateurs auront les mêmes droits que les utilisateurs normaux.
- Utilisateurs enregistrés.
- Utilisateurs anonymes.
- + autres groupes créés selon les besoins par l'administrateur.
Ajouter la notion de groupe sur les droits des pages
Initialiser l'interface d'administration :
- Ecran de gestion des groupes (création/suppression/affectations des utilisateurs à un groupe).
- Ecran de gestion des utilisateurs (création/suppression/affectation à un groupe ou plusieurs ?)
- Ecran de définition des droits par défaut des pages.
- Ecran de gestion des droits des groupes (base de la gestion des droits aux fonctions/actions: pour l'instant sert à accorder les droits d'accès à l'interface d'administration aux groupes)

Sujets en cours correspondant à cette étape : InterfaceDAdministrationWikiNi
Contributions existantes : ACLGroup

Etape 2 : Revoir les fonctions de créations d'utilisateurs

Permettre aux administrateurs de définir la méthode de création des utilisateurs :
- Méthode actuelle : création libre sans confirmation par email. Sémantiquement mauvais car rien n'indique si l'adresse email appartient vraiment à l'utilisateur.
- Création libre avec autorisation après confirmation par mail. Méthode la plus utilisée sur les logiciels Web, elle permet de "garantir" l'authenticité de l'adresse email. Par contre l'inconvénient est qu'il faut pouvoir avoir accès à la fonction mail() de PHP (ce n'est pas le cas chez tous les hébergeurs).
- Création après acceptation de la part d'un administrateur. Formulaire envoyé par mail aux administrateurs qui permet de demander la création d'un utilisateur en lui demandant ses motivations.

Sujets en cours correspondant à cette étape : PropositionsDEvolutionDeLActionUserSettings

Etape 3 : Mettre en oeuvre les fonctions anti-spammer / anti-malveillances

Ajouter la fonction anti-spammer : black-list IP ou black-list domaine des liens externes.
- Ajouter les fonctions d'ajout d'un spammer dans la liste (autorisé par défaut pour les groupes administrateurs et modérateurs, l'administrateur pouvant décider d'ajouter ce droit à d'autres groupes).
- Suppression d'un spammer dans la black-list (administrateur par défaut).
- Fonction de demande motivée pour être enlevé de la black-list (tout le monde, même les black-listés dans le cas d'une black-list sur IP).

Sujets en cours correspondant à cette étape : ProtectionContreLeVandalisme

Etape 4 : Sortie officielle de version exemple 0.5

A faire avant la sortie de la version :

Permettre à l'installation de choisir entre plusieurs niveaux de sécurité pour le fonctionnement du Wiki :
- Pour la création des utilisateurs : choisir le mode initial.
- Pour les droits d'accès aux pages : choisir le mode par défaut et l'appliquer aux pages existantes (documentation Wiki).
Sortir des versions PRE pour la détection et la correction des bugs.
Une fois le niveau de bug acceptable sortir officiellement la version.

Etape 5 : Rendre modulaire les actions

Permettre l'ajout/suppression d'actions (officielles ou contributions) sans connaissance informatique (de préférence à partir de l'interface d'administration - étape préalable installé les fichier de l'action sur le serveur : ftp ou upload).
Permettre d'associer des droits aux groupes sur les actions. Les groupes seraient associés à des actions. Si le groupe ne posséde pas d'association avec une action alors celle-ci ne lui sera pas accessible. L'administrateur aura dans tous les cas accès à toutes les fonctions installées
Prévoir un espace de téléchargement sur le Web pour mettre les actions officielles et contributions.

Sujets en cours correspondant à cette étape : ActionEtDroitDUtilisation

Etape 6 : Sortie officielle de version exemple 0.6

A faire avant la sortie de la version :

Réorganiser l'archive de distribution pour séparer le noyau de WikiNi des actions à ajouter.
Sortir des versions PRE pour la détection et la correction des bugs.
Une fois le niveau de bug acceptable sortir officiellement la version.

Etape 7 : Rendre modulaire le parsing Wiki

Permettre d'apporter des plus par rapport à la synthaxe Wiki et donc d'ajouter des fonctions comme le formatage de tableau, etc...

Etape 8 : Sortie officielle de version exemple 0.7

etc ...

Une fois ces gros travaux accomplis on pourrait avoir un WikiNi à la carte : soit très simple et léger, soit très complet tant au niveau de l'administration que des fonctionnalités.

De plus, il devrait être plus facile d'étendre les possibilités de WikiNi sans toucher au noyau donc le développement pourra se décomposer en 2 parties :

le maintien et l'évolution du noyau WikiNi.
L'ajout de modules pour en augmenter les possibilités.

Qu'en pensez-vous ?
--OlivierB

Dans l'ensemble on partage à peu près les mêmes points de vue : gestion des groupes, interface administration, etc.
Les freins actuels :

l'équipe actuelle est composée de développeur plutôt occasionnels, la plupart pères de famille et avec de longues journées de travail... les gros chantiers (= quelques jours de codage + quelques jours de discussion) sont donc longs à mettre en oeuvre ; pour ma part, par exemple, je ne peux consacrer environ que 4 à 6 heures par semaine à WikiNi (en plus ça part dans tous les sens et j'ai un peu de mal à suivre en ce moment)
beaucoup de gens (dont des développeurs) sont actuellement à peu près satisfait de WikiNi tel qu'il est et ne sont pas près à s'investir pour travailler sur de gros chantier : pire, il ne faut pas que les nouvelles fonctionnalités pénalisent l'application
le cycle de proposition/discussion/réalisation est assez long
il y a beaucoup de proposition qui font leur apparition mais elle ne sont pas beaucoup suivies... pas suivies, donc pas discutées, donc pas acceptées ; je pense qu'il faudrait que nous fassions plus d'effort pour suivre le cycle des propositions ; beaucoup de bonnes idées n'ont pas données de résultat parce que les gens se sont lassés de voir que ça n'avançait pas ; d'un autre point de vue, presque personne n'a fait d'effort pour l'animation : je suis presque le seul à essayer de faire vivre les outils de suivi que sont les pages SujetDuMoment et OuEnSommesNous ; résultat on se disperse en 25000 sujets et rien n'avance ; je suis tout prêt à remettre en cause mes qualités d'animateur et si quelqu'un à d'autres idées je suis preneur

Les points positifs :

tout le monde est motivé et le projet est très ouvert à tous les nouveaux développeurs ; je propose d'ailleurs de donner les accès CVS en écriture à OlivierB et TheTransporter
WikiNi est une bonne base, à mon humble avis, et les directions choisies vont dans le bon sens
développement selon le principe "qui ne dit mot consent"

Donc n'hésitez pas à faire des propositions concrètes (description fonctionnelle + code) mais ne vous attendez pas à déplacer les foules ;) Cela dit, "qui ne dit mot consent" alors lachez vous !
(Tiens, une idée comme ça, si WikiNi était une assoc (ou en passant par une assoc), je pense que nous pourrions prendre des étudiants en convention de stage, ça pourrait peut-être intéresser certains.)
-- CharlesNepote

Dans la catégorie des freins (mais je n'appelle pas ça un frein), je me situe dans le point deux : les fonctionnalités de Wikini me conviennent, et conviennent, je l'ai constaté, à la plupart des utilisateurs de Wikini, quand je parle d'utilisateur de Wikini, je ne parle pas d'administrateur technique ou fonctionnel, mais des utilisateurs pour qui écrire publiquement et facilement sur Internet est une révolution. Je connais même des administrateurs/animateurs qui suppriment des fonctionnalités pour ne pas perturber les débutants dans le monde des wikis.
Je comprends tout à fait le désir de faire évoluer un outil comme Wikini : il est jeune, il a une petite popularité, le code est facile à apréhender ,puisque le projet est jeune, mais parfois je me pose la question des motivations sur les evolutions : pourquoi ne pas installer, si on veut d'un outil disposant de tous les "bell and whistle" mediawiki ou phpwiki, qui fonctionne en php et mysql ?
Cela dit une interface d'administration (pour lutter contre le spam par exemple) et la possibilité d'installer des modules simplement ne seraient pas inutiles. Je ne suis pas persuadé qu'il soit interessant de disposer d'une gestion fine des utilisateurs/groupes : si ce genre de besoin apparait, migrer vers un wiki qui le propose me semble la solution la plus raisonnable : utilisons les bons outils existant plutot que de vouloir sans arrêt faire vouloir tout faire a des outils qui ne sont pas prévus pour ça.
Pour ce qui est de l'ouverture du CVS, tout à fait d'accord pour OlivierB. Au sujet de TheTransporter, j'attends, ne serais-ce qu'un accusé de reception au mail que j'ai pris le temps de rédiger en reponse à ses questions qu'il m'a envoyé de façon privée. -- DavidDelon
PS : Je ne suis pas du opposé à une interface d'administration ... en fait ce sont les priorités que tu as proposé qui me semble a revoir : je verrai plutot anti-spam / nettoyage + modularite en priorité. -- DavidDelon

On peur revoir les priorités ce n'est pas un problème. On peut également décomposer en bloc fonctionnel et se répartir les tâches. J'ai lancé une tâche sur les PropositionsDEvolutionDeLActionUserSettings sur laquelle je suis en cours d'étude puis de réalisation. D'autres peuvent participer ou tout simplement donner leurs avis (pour garder la cohérence de l'appli par exemple). -- OlivierB

En ce qui concerne le WikiNi actuel (surtout depuis que j'y ai ajouté l'ActionAttach), il me convient parfaitement ... sur un intranet. Là pas de problème de piratage/vandalisme, la gestion des utilisateurs peut même être complété par un htaccess si besoin est, de plus je sais qui utilise telle ou telle adresse IP. Donc je n'ai pas vraiment besoin de plus. J'avoue avoir été tenté de l'utiliser sur Internet pour un site à venir mais là je trouve qu'il lui manque encore des fonctionnalités basiques au niveau sécurité.
Avant de trouver WikiNi j'ai regardé et testé mediawiki et phpwiki :

phpwiki est une horreur au niveau de la procédure d'installation. Il faut tout faire à la main et si je me rappelle bien il faut pour cette installation un accès telnet sur le serveur ce que ne fournisse que peu d'hébergeurs. Je n'ai donc pas été plus loin avec phpwiki.
mediawiki est un super wiki mais il est aussi super gourmand. Après une iInstallation sur un serveur en réseau local sans aucun problème, je tente l'installe sur Free et là il refuse de s'installer à cause la quantité mémoire très faible autorisée par Free (5Mo si je me rappelle bien au lieu des 55Mo demandé par mediawiki). Je traffique l'installation pour l'installer quand même et lors des tests mediawki plante à cause d'un ... problème mémoire insuffisant.

Après un certain temps de recherche j'ai fini par trouver WikiNi (grâce à son adaptation pour spip). Installation en local sans problème, installation sur Free idem et temps de réponse convenable.
WikiNi était l'outil que je cherchai même s'il ne disposait pas de toutes les fonctions désirées. Il y avait beaucoup de contributions intéressantes (ActionAttach, acl group, ...) donc c'était parfait je n'avais plus qu'à installer ces patches dans mon WikiNi. Enfin presque car avant j'ai préféré suivre un peu la vie du site et je me suis aperçu (un peu déçu ;o) que ce n'était pas la bonne solution surtout dans le cas où je voudrai mettre à jour la version de WikiNi (patch de sécurité par exemple comme la version 0.4.2).
Charles, David en ce qui concerne le temps, je suis comme vous un brave père de famille (3 petits monstres) donc je comprends très bien qu'il est difficile dans ces conditions de faire avancer rapidement les choses. Maintenant, vous pouvez peut être voir les choses différemment. En effet, je pense que ce qui manque au projet c'est une canalisation des bonnes volontées (les nombreux contributeurs) pour dire voilà notre priorité numéro 1 c'est ça (par exemple anti-spam ;o) et ce concentrer sur ce sujet. Une fois bouclée on passe à la suivante. C'est pour cela que je me suis permis de faire cette suggestion de RoadMap?.
Pour l'ouverture CVS, on va attendre un peu car il faut que je me remette dans le bain de PHP (ça fait longtemps que je ne programme plus - je suis maintenant plus adminsitrateur système/sgbd) et que je consulte les sources. Par contre, je suis intéressé pour vous aider autrement (à voir comment exactement) mais il faut savoir que je fais partie de l'équipe (petite équipe) de linuxgraphic.org et j'ai déjà beaucoup d'engagement pris en ce moment.
WikiNi est un bon projet et le travail déjà fait est excellent.
-- OlivierB

J'aime bien wikini, parce qu'il est simple et léger. Comme l'a dit DavidDelon avant moi, si on veut plus de fonctionnalités, il faut peut être se tourner vers d'autres outils. Mais il y a quand même une chose que je regrette, c'est qu'il manque un administrateur qui ait tous les droits sur toutes les pages.
Par exemple, à l'installation, il pourrait aussi y avoir la création d'un utilisateur (qui serait administrateur), et toutes les pages de bases lui appartiendraient (un peu comme dotclear, qui lors de la phase d'installation, demande la création de l'administrateur, ce dernier ayant tous les droits). C'est vraiment le seul truc qui me manque dans wikini.
Sinon, une des grosses faiblesses de wikini, c'est à mon avis son site web... il est trop grand, les pages sont trop longues (ça doit être un enfer à animer). Personnellement je m'y perds un peu (voir beaucoup). J'aimerais par exemple savoir quelles sont les fonctionnalités qui sont en cours d'intégration, qu'est-ce qui est fait au niveau développement, qu'est-ce qui reste à faire ? Peut être que la réponse est rien, mais c'est pas grave.
Typiquement, une fois qu'un sujet est discuté, quels sont les actions qui sont entreprises ? est-ce que ça implique une prochaine version ?
Voilà, je ne sais pas si je suis très clair...
-- NicolasArnaud