Cette page vise à organiser un vote concernant les fonctionnalités proposées dans
ErgonomieGroupeDePages. Étant donné que plusieurs fonctionnalités peuvent (et même devraient) être retenues, il faut trouver au préalable une organisation pratique à ce vote (comptage des points etc.).
- Il y a déjà eu d'autres votes de ce genre pour WikiNi, par exemple pour les ReglesFormatageTableau, mais je ne parviens pas à retouver l'organisation (je pense que tout s'est fait par mail...) -- LordFarquaad
Organisation du vote
Organisation en deux phases:
- Ceux qui le souhaitent (inscrits ou non) peuvent faire une proposition de solution (théorique, pas une implémentation) reprenant (partiellement) les fonctionnalités proposées. Une proposition doit être consistante: elle ne peut contenir de conflits de fonctionnalités. Il n'est pas exclu d'émettre des critiques (positives ou négatives) sur les proposition émises...
- On organise un vote simple: chaque membre inscrit a droit à un vote en faveur de la solution qu'il préfère. La solution ayant obtenu le plus de votes est retenue et implémentée (soit par l'équipe, soit par un contributeur).
Rappel des fonctionnalités proposées
- Catégories multiples
- Catégories principale et secondaires
- Sous-catégories
- Pages de même nom dans des catégories distinctes
- Toute page doit appartenir à au moins une catégorie
- Une page de description pour chaque catégorie
- Choix de la catégorie lors de l'édition
- Affichage de la liste des catégories de la page
- Affichage de la position dans l'arborescence
- Changement de catégorie
- Héritage des droits
- Style et catégories
- Toute page définit une catégorie
Propositions de solutions (théoriques)
Solution 1
(Proposée dans
GestionDeGroupeDePages)
Fonctionnalités retenues
- Sous-catégories
- Pages de même nom dans des catégories distinctes
- Une page de description pour chaque catégorie
- Affichage de la position dans l'arborescence
- Toute page définit une catégorie
Fonctionnalités incompatibles
- Catégories multiples
- Toute page doit appartenir à au moins une catégorie (ou alors il faut une catégorie racine qui n'en est pas vraiment une, ce qui n'a pas de sens...)
- Choix de la catégorie lors de l'édition (déterminée par l'URL de la page)
Description du principe
Le nom de la page définit la catégorie dans laquelle elle est. On définit un séparateur (par exemple le point ".") et on nomme une page selon
NomDeCategorie?.
NomDeLaPage?. Un nom de page peut posséder plusieurs points (sous-catégories) au aucun (les catégories ne sont pas obligatoire, compatibilité avec les pages existantes). Ce nom est le même apparaissant dans l'url, dans la base de données (aucune modification de la base de données) et dans la page (avec sans doute une mise en forme particulière pour faciliter la navigation).
La syntaxe des
NomsWiki?? est étendue pour permettre les points, de façon à pouvoir facilement faire des liens vers des pages appartenant à une catégorie/sous-catégorie.
NomDeCategorie? correspond également à une page et
NomDeCategorie?.
NomDeLaPage? peut être vu comme si
NomDeLaPage? était une "sous-page" de
NomDeCategorie?.
Cette solution est entièrement compatible avec les anciennes versions de
WikiNi, et ne devraient pas poser de problème pour les modules non plus (tant qu'ils n'ont pas hardcodé la syntaxe des noms de pages). Il y a également une mini-roadmap pour la mise en oeuvre.
Fonctionnalités implémentables par la suite
- Catégories principale et secondaires
- Affichage de la liste des catégories de la page
- Changement de catégorie (via RenommerUnePage)
- Héritage des droits
- Style et catégories
Vote
- Je suis pour -- Progi1984
- Pour l'instant moi aussi mais il faudrait d'autres propositions... -- DidierLoiseau
- Cette solution me plait entre autre car elle conserve la structure de la base intacte et qu'elle offre une possibilité simple d'implémenter une gestion des discutions à la Wikipédia par un simple ajout d'un .Discussion au tag d'une nouvelle page (A voté) -- StephaneAulery?
- Je suis pour aussi et je pense que depuis le temps que cette solution est proposée, s'il y avait beaucoup d'inconvénients, ils auraient déjà été énoncés. -- JulienLanglois?
- Pour la liste des inconvénients fonctionnels, j'ai ajouté les incompatibilités. On retiendra également que la catégorie doit être indiquée dans l'URL et qu'il faudra allonger plusieurs champs dans la base de données. -- DidierLoiseau
Solution 2
À la
MediaWiki?.
Fonctionnalités retenues
- Catégories multiples
- Une page de description pour chaque catégorie
- Affichage de la liste des catégories de la page
- Affichage de la position dans l'arborescence
- Changement de catégorie
- Héritage des droits
- Style et catégories
Fonctionnalités incompatibles
- Pages de même nom dans des catégories distinctes
- Toute page doit appartenir à au moins une catégorie
- Toute page définit une catégorie
Description du principe
Une action
Action inconnue "category" ajoutée dans le texte de la page détermine la ou les catégories de la page. On peut imaginer donner la liste des catégories comme argument, séparées par des virgules. La première est la catégorie principale. Les catégories peuvent s'imbriquer (sous-catégorie) en incluant une catégorie fille dans la page de description de sa catégorie mère. Pour éditer la page de catégorie, il faut cliquer sur son nom dans une page lui appartenant. Il faut aussi créer une manière de nommer les pages de catégorie automatiquement, par exemple
CategorieMachin?.
Fonctionnalités implémentables par la suite
- Catégories principales et secondaires
- Sous-catégories
- Choix de la catégorie lors de l'édition
Vote
Solution 3
Implémentées dans la base de données. C'est la méthode de nombreux CMS : on choisit la catégorie dans une liste déroulante.
Fonctionnalités retenues
- Choix de la catégorie lors de l'édition
- Une page de description pour chaque catégorie
- Affichage de la liste des catégories de la page
- Affichage de la position dans l'arborescence
- Changement de catégorie
- Héritage des droits
- Style et catégories
- Toute page doit appartenir à au moins une catégorie
Fonctionnalités incompatibles
- Pages de même nom dans des catégories distinctes
- Toute page définit une catégorie
Description du principe
La liste des catégories est une base de données (simple fichier texte ou carrément mySQL). Cette base sert à générer la liste de catégories disponibles ainsi que les noms des pages des catégories. On peut considérer que cette solution est une variante de la solution précédente dans laquelle le processus des catégories est totalement masqué pour l'utilisateur par le biais de champs de base de données et d'interfaces graphiques associées.
Fonctionnalités implémentables par la suite
- Catégories multiples
- Catégories principale et secondaires
- Sous-catégories
Vote
Autres propositions pour l'organisation des votes
(il s'agit des propositions d'organisation du vote qui ont été discutées avant de choisir l'organisation utilisée dans cette page)
Proposition 1
Toute personne inscrite (une seule fois) à
WikiNiPointNet a le droit de voter. Chaque votant exprime ses votes sous la forme d'une liste par ordre décroissant de ses préférences. On attribue ensuite des points (à déterminer) à chaque choix, et on fait la somme des points reçus par chaque fonctionnalités sur l'ensemble des votants. Les fonctionnalités ayant obtenu le plus de points sont choisies prioritairement sur les fonctionnalités avec lesquelles elles sont en conflit. Dans la mesure du possible, les fonctionnalités sont implémentées en commençant par celles qui ont eu le plus de points.
Proposition 2
Comme la proposition 1 sauf que chaque votant à droit à un certain nombre de points (par exemple 15) qu'il attribue selon son gré aux fonctionnalités qu'il préfère.
Proposition 3
C'est la proposition qui a été retenue. Voici l'historique des discussions qui ont mené à ce choix:
Le grand avantage de cette organisation est que cela va éviter de devoir résoudre des conflits de fonctionnalités après le vote, et permettre d'attaquer l'implémentation directement.
- Pour l'instant c'est cette proposition qui me paraît la meilleure -- LordFarquaad
- Je vote ;-) aussi pour cette solution qui me semble éviter de s'enliser par la suite dans des conflits entre fonctionnalités -- JmPhilippe
- Note que ce sont là juste trois propositions que j'ai faites pour lancer directement la discussion, mais rien n'empêche d'en faire d'autres. -- LordFarquaad
- Oui mais je pense que c'est la bonne méthode, il faut proposer différents scénarios réalistes en mettant bien en évidence les limites de chacun puis laisser les utilisateurs se prononcer; je n'ai pas fait plus d'investigations mais j'ai le sentiment qu'il n'y a pas 50 possibilités intéressantes -- JmPhilippe
- Je vote pour -- Progi1984
- Je pense qu'il est inutile d'attendre plus longtemps: apparemment tout le monde s'accorde sur cette proposition et je pense qu'on peut donc se lancer dans sa première phase. -- LordFarquaad