Encore un nouveau WikiBlog !

Source CommunityWiki à remanier : Seul le lien original fait référence . Désolé mais le copie-coller d'un wiki vers ce blogwiki peut se montrer pratique mais nécessite un sérieux remaniement du code pour ôter le MotWiki présent dans toutes les définitions de liens. AmHA ne facilite pas le développement du ContenuMobile pour notre TrainDesIdées. Remaniement en cours. L'article de référence peut être remanié et complété. -- ChristopheDucamp

Il y a des tonnes de MoteursWiki différents 1 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 lots 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ée 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 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 moteurs wiki 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 WikiGateway permettra aux wikis de mieux inter-opérer les uns avec les autres et avec d'autres logiciels.

Deuxièmement, le projet wikigateway permettra à la PageDatabase 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 switcher leurs MoteursWiki sans douleur.

Troisièmement, Le projet de WikiFenêtre ? (traduire WikiWindow) permettra à différents utilisateurs d'interagir avec la page database en utilisant n'importe quel "frontend" (NDT ?) de MoteurWiki que chaque utiliateur 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 CommunityProgrammableWikis 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 puis une communauté de développeurs pourrait remanier le code ensemble tout simplement comme du texte sur des pages wiki.

:Voir CommunityProgrammableWiki:SpwIdeas pour quelques idées de Mitchell Charity à propos du CommunityProgrammableWiki qui je pense pourraient être appliquées ici.

Ces outils :

• permettront aux utilisateurs et communautés d'essayer de nouvelles fonctionnalités et différents MoteursWiki rapidement et fréquemment
• permettront aux differents moteurs wiki d'accéder aux PageDatabases de chacun d'eux
• permettront aux développeurs d'ajouter des fonctionnalités avec moins de "forking", et de fusionner plus facilement ensemble les forks.

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

• le fait de permettre aux fonctionnalités wiki de s'écouler plus facilement d'un moteur wiki à un autre
• le fait de permettre aux moteurs wiki de s'écouler plus facilement d'une communauté wiki à une autre
• le fait de permettre aux communautés wiki de s'écouler plus facilement d'un MoteurWiki à un autre
• le fait de permettre aux MoteursWiki de s'écouler l'un dans l'autre.

– BayleShanks

Voir aussi : Futures:WikiDiffusion.

Je voudrais que cette page soit dénommé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 ParadigmShift ? 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 parce 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 ? (traduire NewFeatures ?) 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 2, yadda yadda.) Le nom de cette page est un énoncé de perception, tandique 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 fond 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 rouge 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'ils 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 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ésEnLigne 3. 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 les choses du type WikiPedia. Tous ont divergé (All will and have diverged). – 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-jeu ressemblant 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 du au crash des dotcoms pointe vers les même conclusions ; si le temps des développeurs est devenu plus rare, alors peut-être quele nombre de projets simultanément développables doit chuter, tout comme les industries se consolident quand leurs profits s'assèchent. – BayleShanks

They are. 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 qu'on pourrait se soucier des choise. Mais il y aurait aussi de la résurgence. Il semble simplement qu'avec les wikis, les projets fourchent 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 fragmentation 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 que, d'abord, il devienne moins nécessaire de forker un wiki afin d'ajouter de nouvelles fonctionnalités, et ensuite, il devienne plus commun pour les forks/enfants de devenir ré-incorporé à 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

Great ! 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 ? 4 - 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

BayleShanks

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

BayleShanks

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 standardiser essentiellement sur un moteur wiki par langage de programmation ; mes choix personnes 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 ceal pourrait se manifester par me faire préférer produire plus sur MoinMoin que OddMuse.

AlexSchroeder

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 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.

EvanProdromou

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 inexclusable très mal écrit. Je sais – j'en ai écrit vraiment un bout.
• Il est difficile à skinner.
• Il exige une database.
• Pas de WikiMots 5.
• 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.

BayleShanks

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 pyton", "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 capable 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.

AlexSchroeder

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 en conséquence, les arguments essentiels seraient differents pour chaque concours. Ceci nous démange tous d'écrire peut-être quatre morceaux avec des titres comme "Le plus Facile à Installer", "Jeu de Fonctionnalités les plus Utiles", "Mieus 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.

Discussion Langue Française

TraductionEnCours. Seul le lien original TooManyWikiEngines fait office de référence. Une page très intéressante qui risque de bouger souvent avant de devenir une PageStable ?. La discussion au milieu reste à traduire avec les difficultés d'un LangageLien de proximité restant à dénouer…

PageTranslation LangueFrançaise TooManyWikiEngines DossierWikiTechnologie