BeaucoupTropDeMoteursWiki

Cette page a démarré sur TooManyWikiEngines

Il y a des tonnes de MoteursWiki différents1 ci et là. Ceci fournit une diversité vibrante d'idées, mais veut aussi dire que la somme totale des efforts de développeurs de wiki s'éclate en 1000 morceaux.

Un aspect du problème est qu'afin d'essayer quelques nouvelles fonctionnalités, un développeur a simplement besoin de forker un MoteurWiki. Les différents moteurs wiki sont comme des ensembles de petites "piscines-bien-propres", chacune d'entre elles disposant de quelques caractéristiques uniques, la plupart d'entre elles étant empaillées dans leurs MoteursWiki.

De façon similaire, il est difficile pour une nouvelle fonctionnalité ou un nouveau MoteurWiki d'être adoptés par beaucoup de communautés wiki ; les communautés sont "empaillées" avec leurs moteurs wiki en cours, parce qu'il est difficile de migrer le contenu vers un nouveau moteur.

Mon effort personnel pour améliorer la situation est non pas d'essayer et de faire que les personnes soient convaincues d'arrêter de "forker" les wikis, mais plutôt de créer des outils qui rendent la situation plus fluide. Des outils qui permettent aux nouvelles fonctionnalités de s'écouler plus facilement d'un MoteurWiki à l'autre. Et de permettre aux MoteursWiki de s'écouler en toute fluidité l'un dans l'autre. Un autre mot pour "fluidité" ici est probablement "l'inter-opérabilité".

Premièrement, le projet WikiPasserelle permettra aux wikis de mieux inter-opérer les uns avec les autres et avec d'autres logiciels.

Deuxièmement, le projet WikiPasserelle permettra à la DatabasePage d'être exportée à partir d'un wiki et d'être importée dans un autre. Eventuellement, elle traduira aussi d'un style de WikiSyntaxe vers un autre. Ceci permettra aux communautés wiki de basculer sans douleur leurs MoteursWiki .

Troisièmement, Le projet de FenêtreWiki permettra à différents utilisateurs d'interagir avec la page database en utilisant n'importe quelle interface de MoteurWiki que chaque utilisateur désire.

Quatrièmement, les WikiProgrammableParLaCommunauté permettront aux utilisateurs de communautés d'ajouter des fonctionnalités aux MoteursWiki existants sans les forker, même si le développeur du MoteurWiki est trop occupé pour accepter les fonctionnalités.

Cinquièmement, les WikiProgrammableParLaCommunauté permettront aux développeurs de communautés de fusionner et remanier ensemble différents MoteursWiki. Par exemple, on pourrait installer un WikiProgrammableParLaCommunauté hébergeant UseMod, OddMuse et tous les autres descendants de UseMod, et ensuite une communauté de développeurs pourrait remanier ensemble le code tout simplement comme du texte sur des pages wiki.

:Voir CommunityProgrammableWiki:SpwIdeas pour quelques idées de Mitchell Charity à propos du WikiProgrammableParLaCommunauté qui selon moi pourraient s'appliquer ici.

Ces outils :

C'est ce que je veux signifier par produire la situation plus fluide ;

BayleShanks

Voir aussi : Futures:WikiDiffusion.

Je voudrais que cette page soit appelée différemment. Je l'appellerais "TowardsEasilyAmmendedWiki," ou quelque chose comme ça. J'aimerais lier vers cette page ou la copier pour les WikiFutures. – LionKimbro

Sens-toi libre de copier la page. Je pense que le nom TowardsEasilyAmendedWiki ne capte pas vraiment le sujet de cette page. Des choses comme ExtensibleWikis, WikiProgrammableParLaCommunauté et WikiPlugins semblent faire partie de faciliter la modification de production de logiciel wiki. Mais des idées comme faciliter aux individus et communautés le changement de MoteursWiki, et faciliter la fusion de différents wiki "fork" semblent être différentes de cela (même si cela reste en rapport avec l'objectif ultime d'accélérer l'évolution du logiciel wiki).

BayleShanks

Je suis d'accord avec Bayle, les nouveaux noms n'améliorent pas la situation. Que pensez-vous de WikiEngineFlexibility ou WikiEngineIndependence ou WikiEngineDependence (selon la manière dont vous voulez le formuler !). – AlexSchroeder

Que penser de WikiFlexibilityPlan? ? LiquidWikiPlan? ? WikiDiffusionPlan? ? BaylesDiffusionPlan? ? – LionKimbro

Peut-être que cette page pourrait être tranchée : une pour expliquer le but (indépendance du moteur wiki sous-jacent), listant différentes technologies pour parvenir à ce but avec un brève description, et puis migrer les détails vers les pages pertinentes. – AlexSchroeder

Je pensais que c'était ce que j'avais fait :) Cependant, mon point de vue sur cette page est fondé sur un problème -il y a trop de moteurs wiki et ainsi le temps de développement et les idées sont éparpillées-, plutôt qu'un unique objectif. Je suis en train de régler le problème face au peu d'objectifs qualitativement différents. Par exemple, plus d'indépendance des fondamentaux des moteur wiki traite les symptômes du problème en posant la question moins que de l'existence de plus de milliers de moteurs différents. Le wiki programmable par la communauté traite la cause du problème en ôtant quelques-uns des besoins des développeurs pour démarrer leurs propres projets.

BayleShanks

En tant qu'avertissement, pourrais-je lancer l'idée ici d'un ChangementDeParadigme? ? Peut-être que la raison pour laquelle le MoteurWiki original n'a pas été "forké" dans la compréhension commune de la définition mais plus "explosé", est que nous explorons encore les moyens de comprendre un ajout qui n'est pas une autre étape de l'expansion en évolution d'un paradigme (par ex. emacs a été plus loin que le paradigme d'un éditeur de texte, il peut encore être utilisé de cette façon qui est peut-être la raison pour laquelle EmacsWiki est encore moins consciemment de l'exploration de quelque chose de totalement nouveau plutôt que l'exploration de possibilités radicales des NouvellesCaractéristiques? plutôt que tout autre chose – Ok, peut-être est-ce un mauvais exemple) mais quelque chose de nouveau ?

Oui, je suis d'accord, ceci est en grande partie l'explication de la raison pour laquelle il y a BeaucoupTropDeMoteursWiki. Un wiki est une classe de très grandes choses nouvelles et très différentes ; c'est aussi général et aussi basique qu'un "livre". – BayleShanks

Que pensez vous de UnifiedWikiEngines? (c.f. UnifiedWikis, ModificationsRécentesUnifiées, FaisceauxUnifiés, yadda yadda.) Le nom de cette page est un énoncé de perception, tandis que vous voulez un énoncé d'intention. Alors mettons-le en faisceau :) Cela semble plutôt intéressant.


Depuis un an et demi, il y a eu une explosion de courte durée dans le développement wiki pendant que les développeurs de wiki commençaient à échanger des idées et du code sur MeatballWiki. Actuellement, les principaux développeurs wiki n'apprécient plus les levées de fonds dot.com qui nous ont donné le temps de loisir pour hacker wiki. Alternativement, nous sommes ennuyés et déconnectés pour aller sur d'autres choses. Maintenant les bloggers entrent dans la mêlée et sont en train de réinventer la roue pour plusieurs raisons diférentes. Le chemin est d'ignorer les wikis qui vous ignorent et de se concentrer sur ceux mis en faisceau autour de c2.

N'oubliez pas que "wiki" est un abus de langage ; ils sont si simples qu'il y a presque un style plus qu'une technologie. Les personnes ajouteront la technologie qu'elles veulent simplement comme les personnes changeront la CSS de leurs pages personnelles tant qu'elles le veulent. C'est facile, aussi ce sera fait. C'est cool et intéressant et ça ne vaut pas la peine de s'en soucier. La question est de savoir quels wikis vous voulez nourrir ? Je suis intéressé dans les wikis en tant que CommunautéEnLigne. D'autres sont intéressés par les WikiLogs, d'autres sont intéressés par WikiAsPIM, d'autres sont intéressés par les wikis en tant que Wiki:CollectiveNotepad, et beaucoup d'autres sont intéressés dans des choses du type WikiPedia. Tous ont ou auront divergé. – SunirShah

Je suis d'accord que l'idée de "wiki" est trop vaste pour être servie par un ou quelques programmes. Mais je pense aussi que le nombre de moteurs wiki ciblant chaque sous-ensemble similaire d'objectifs est si large que le temps des développeurs s'éclate beaucoup trop.

Je pense que le manque du temps des développeurs dû au crash des dotcoms pointe vers les même conclusions ; si le temps des développeurs est devenu plus rare, alors peut-être que le nombre de projets simultanément développables doit chuter, tout comme les industries se consolident quand leurs profits s'assèchent. – BayleShanks

C'est le cas. Les projets de moteurs wiki mourront. Seuls ceux avec des communautés viables survivront, comme TWiki et MoinMoin. UseModWiki pourrait mourir. C'est l'évolution. – SunirShah

Oui, je suppose que cela pourrait prendre soin des choses. Mais il pourrait aussi y avoir une résurgence. Il semble simplement qu'avec les wikis, les projets bifurquent tout le temps.

Par exemple, UseMod a déjà fait naître OddMuse, tout comme quelques autres UseMod:UseModDescendents. Le parent, UseMod, peut mourir. Mais il y a simplement autant de fragmentations si n'importe lequel des enfants survit, et plus de fragmentation si de multiples enfants survivent.

Et durant ce temps, le temps passé à réaliser de nouvelles fonctionnalités dans OddMuse ne bénéficie pas à UseMod, ou UnrealWiki, ou IAwiki, ou WikiProgrammableParLaCommunauté. Et vice versa.

Aussi, j'aimerais faire qu'il devienne d'abord moins nécessaire de forker un wiki afin d'ajouter de nouvelles fonctionnalités, et ensuite, qu'il devienne plus commun pour les forks/enfants de se retrouver ré-incorporés à l'intérieur du parent (remaniement du code à travers tous les projets en rapport). – BayleShanks

Ce sont/étaient/sont les objectifs du projet InfiniteMonkey. – SunirShah

Génial ! Alors tout le monde pense la même chose, il me semble . – BayleShanks

Deux pensées, j'aime ces idées ! Je pense que ce qui est discuté ici résonne comme le SeamlessWiki? - qui évolue dans la direction pointée par Sunir, wiki n'est plus nécessairement une technologie, plutôt un style ou une qualité.. – MarkDilley

Hmmm, je dirais que c'est une technologie. Si l'internet n'avait pas existé, je ne peux penser à quelque mode de conduite que j'appellerais un "wiki".

Standardiser un Moteur Wiki

Comme je l'expliquais au-dessus, c'est difficile à faire, aussi je pense que la meilleure stratégie est d'essayer et d'accroître la "fluidité". Cependant, c'est une discussion qui en vaut la peine.

J'ai remarqué sur l'article le plus récent de SlashDot sur les wikis que deux personnes sont en train de raconter que MediaWiki deviendrait le standard de-facto.

Aussi, pourquoi ne pas faire au moins une tentative pour concentrer notre développement sur MediaWiki ? La raison la plus respectable est qu'ils aimeront différents styles architecturaux de logiciel wiki. Une autre raison est qu'il est plus facile d'ajouter des fonctionnalités à votre propre projet que des les obtenir chez quelqu'un d'autre (mais cette dernière raison n'est pas si respectable parce que je suspecte que vous obtiendrez votre fonctionnalité à l'intérieur de l'autre logiciel, cela prendra simplement quelques semaines).

Par exemple, pourquoi, AlexSchroeder ne passe pas son temps à ajouter des fonctionnalités agréables à MediaWiki au lieu de continuer à développer OddMuse ? Je suppose que c'est parce que 1) Alex préfère Perl à PHP, et 2) Alex aime être capable d'ajouter n'importe quelle fonctionnalité dont il a envie au projet sans avoir à demander la permission à quelqu'un d'autre (ai-je raison ?).

Ma préférence néanmoins serait que nous produisions au moins un petit essai pour nous concentrer à standardiser un moteur wiki par langage de programmation ; mes choix personnels en cours sont :

  • OddMuse pour Perl (bien que, pour rester réaliste, TWiki doit être probablement aussi inclus)
  • MediaWiki pour PHP (PHPWiki est géant, et je n'ai jamais véritablement essayé MediaWiki, mais tout le monde ailleurs semble l'apprécier)
  • MoinMoin pour Python

Python est actuellement mon langage personnel favori, aussi je serais dans le camp MoinMoin, je pense. Même si je pense qu'OddMuse est meilleur. Je suppose que cela pourrait se manifester par me faire préférer produire plus sur MoinMoin que OddMuse.

Il me semble que tu as raison à propos des raisons qui me motivent pour avoir mon propre projet ; j'ajouterais probablement "facilité d'installation" sur liste des caractéristiques que je considère comme importantes. Je pense que sur #wiki nous sommes en train de démarrer à voir ce qui va se passer plus souvent désormais : à travers les recommandations que nous produisons contre PhpWiki et pour PmWiki, nous guidons déjà les utilisateurs. Je pense que nous avons besoin de plus de critique de projets, plus de recommandations bien fondées, fondamentalement nous avons besoin de plus de compétition. La liste originale des moteurs (Wiki:WikiEngines) est en train d'échouer à nos attentes parce que c'est une liste désordonnée et non commentée. Cela n'est pas bon, parce vous devez les essayer tous afin de produire une décision informée.

Aussi une chose à noter est la liste magnifique de Wiki:TopTenWikiEngines, qui fait un bon travail de diminution vers le bas du champ de combat pour les nouveaux réalisateurs.

Je pense que choisir MediaWiki comme le standard de facto du moteur wiki est une idée horrible :

  • Le développement de MediaWiki a toujours et sera toujours concentré sur Wikipedia.
  • Il est difficile à déployer.
  • Le code est d'une manière inexcusable très mal écrit. Je sais – j'en ai écrit vraiment un bout.
  • Il est difficile à skinner.
  • Il exige une database.
  • Pas de MotWikis
  • Il est si lent qu'il exige des tonnes de serveurs Squid, des ajouts de mémoire-cache, etc., etc., simplement pour fonctionner correctement. Le code est développé comme si vous aviez tous ces serveurs bonus disponibles et si vous ne le faites pas ils s'éteignent.

Ceci n'est pas pour dire que je ne pense pas que MediaWiki est important pour toute discussion à propos de l'interaction technique wiki, mais je ne pense pas que MediaWiki soit le VHS du monde wiki. Je pense vraiment que les moteurs wiki devraient disposer d'un moyen facile pour basculer vers le "mode syntaxe du MediaWiki", de telle façon que les administrateurs qui savent qu'ils disposeront d'une communauté WikiPedia-pleine-de-jugeotte pourront facilement démarrer de cette façon. (Je pense que PmWiki 2 aura une syntaxe MediaWiki en option.) Mais comme nous migrons désormais dans l'ère du WysiwygWiki, je pense que cela va devenir moins important.

Merci Evan, c'est simplement le type de chose que nous avons besoin d'entendre ! Comme le disait Alex, c'est simplement ce dont nous avons besoin : des évalutions plus critiques et de la compétition.

Je propose que CommunityWiki puisse maintenir un WikiSoftwareAwards? en continu (ou au moins deux fois par an). Nous aurons différentes catégories, comme celle "Meilleurs moteurs wikis (top 3)", "meilleur moteur python", "meilleur moteur perl", "meilleur nouveau moteur", "meilleur package logiciel wiki qui n'est pas un moteur wiki", etc. Les résultats pourraient être annoncés sur le CommunityWikiBlog.

Que nous soyons ou non capables de parvenir à un consensus sur tout reste incertain, mais essayons ; les discussions sur ce sujet peuvent extorquer le type de comparaisons critiques que nous voulons générer.

Cela m'intéresse de faire quelque chose à propos de cet emplacement. Je pense que nous sommes d'accord sur le fait que les tableaux avec des listes de fonctionnalités ne sont pas appropriés. En supposant que nous avancions véritablement sur ça, je pense que ce qui renverrait beaucoup mieux nos aperçus serait une collection de petits morceaux d'opinions.

De ce fait nous pouvons écrire un petit morceau de texte argumentant le cas pour chaque moteur wiki nominé. La discussion pourrait tourner sur les catégories que tu proposes, mais par conséquence, les arguments essentiels seraient différents pour chaque concours. Ceci nous démange peut-être tous d'écrire quatre morceaux avec des titres comme "Le plus Facile à Installer", "Jeu de Fonctionnalités les plus Utiles", "Mieux Adapté Pour Un Trafic Elevé" et "Moteur Wiki Préféré pour les Hackers Python". Dans chaque morceau, nous recommanderions un moteur wiki. Le prochain semestre, nous écrirons un autre jeu de quatre billets recommandant chacun un moteur wiki.


PageTranslation LangueFrançaise TooManyWikiEngines DossierWikiTechnologie

Footnotes:

1. ou des WikiClones

Define external redirect: SeamlessWiki WikiDiffusionPlan WikiFlexibilityPlan NouvellesCaractéristiques LiquidWikiPlan ChangementDeParadigme WikiSoftwareAwards BaylesDiffusionPlan

EditNearLinks: WikiLog MoteurWiki WikiAsPIM WysiwygWiki WikiPlugins ExtensibleWikis UseMod PmWiki InfiniteMonkey DatabasePage MoteursWiki MeatballWiki MediaWiki EmacsWiki MotWiki SunirShah PhpWiki MoinMoin CommunautéEnLigne UseModWiki PageDatabase UnrealWiki

Languages: