ManqueDeRetravail

Retravailler dans le contexte des wikis consiste à éditer une page ou un groupe de page afin de récrire les discussions et commentaires dans une forme plus compacte. L'aspect-clé est que vous récrivez le texte pour les futurs lecteurs : tirer des leçons, supprimer ou clarifier les références vers des événements qui ne sont plus d'actualité, fournir un résumé près du haut de la page, présenter les idées principales avant de plonger dans les détails, etc.

Cela n'arrive pas souvent. Cela prend du temps et de l'énergie. Les personnes n'aiment pas retravailler. C'est laborieux, les récompenses pour la personne qui produit le travail sont minimes. Voir MeatBall:ProblèmesRemaniement.

En outre le temps et l'énergie pourraient être investis dans quelque chose de nouveau au lieu de nettoyer quelque chose de vieux. Si les pages sont sujbectives ou si leur importance est éphémère, alors cela ne fait pas de sens d'investir du temps et de l'énergie en elles.

Cette page a démarré comme l'un des points sur CritiqueDeWiki.


Autres Wikis

Meatball n'est pas typique. Sur la plupart des wikis, les gens simplement clairs n'aiment pas retravailler. Retravailler est vraiment laborieux et les récompenses minimales. Là où le retravail apparaît, c'est généralement le résultat d'un ou deux individus. Il est bien plus facile pour les gens de se souvenir où ils en sont dans leurs têtes, que de tout clarifier sur le papier.

Retravailler

Retravailler est un nouvel art et seulement une petite quantité de personnes semblent vraiment le maîtriser, si ce n'est pas du tout. Aussi, voyons-nous rarement cela arriver, et si cela arrive nous sommes souvent mécontents des résultats. Est-ce un échec du wiki ? Remanier n'arrivera jamais dans d'autres systèmes, cela n'arrivera pas du tout dans un BBS ou dans un blog. Ainsi, je pense que s'il y a échec, c'est notre échec, c'est l'échec des personnes qui utilisent le wiki. Ou peut-être que le problème est l'impatience, nous avons simplement essayé de parvenir plus difficilement et plus longtemps à de bons résultats.

Les wikis ont aussi des cultures tout à fait différentes, supportant ou qui entravent le remaniement. Signer est souvent perçu comme un obstacle majeur au remaniement et il y a des communautés wiki qui découragent de signer alors que d'autres invitent aux contributions signées. Aussi, il n'existe pas de pratique "wiki" commune à ce titre.

CommunityWiki est probablement à une extrême du spectre, du fait de ses contributions signées par l'image. Elles sont magnifiques mais semblent décourager le remaniement même plus que ne le font les signatures normales.

Citation

Ensuite à nouveau, peut être que les quelques premiers qui ont vraiment commencé à retravailler on laissé les autres personnes prendre du recul, de fait qu'il est très difficile d'obtenir plus d'un ou deux efforts de remaniements sérieux qui fonctionnent (sur un unique RecentChanges) ? Peut-être qu'un ou deux remanieurs travaillant très dur décourageront le retravail plus en profondeur tout comme un fondateur travaillant très dur dissuadera d'autres lecteurs de se transformer en contributeurs. – AlexSchroeder sur CritiqueDeWiki

Expériences Pendant le Retravail

Le mode discussion à l'intérieur des pages wikis semble selon moi être un mauvais usage. Les IndicationAuteurs comme nous le faisons avec la notation ![new:ThomasKalka:2005-12-22 19:31 UTC] est la mauvaise voie. Les commentaires sont atomiques, ont une date et un auteur. Simplement permettre ceux-ci comme séparés, en micro-contenus imbriqués aussi pour les pages wiki présente quelques avantages :

  • ce serait plus facile d'ajouter des commentaires
  • plus de magie serait possible comme
    • la date des billets
    • l'étiquetage par tag des entrées
    • un moyen transparent de cacher / plonger à l'intérieur du passé

Quel sorte de support technique aimerais-je avoir pour retravailler ?

  • un moyen facile de taguer les discussions à un niveau sous-atomique
  • un moyen facile de marquer les discussion comme "retravaillées" → point pris et noté quelque part ailleurs.
  • quelque chose comme le remaniement

ceci est plus poétique que rationnel à cette heure, sentez vous libre de commenter néanmoins.

Quand je lis quelque chose que quelqu'un a écrit, je prends fréquemment de petites notes, en faisant tourner "notepad.exe" ou un vi ou le buffer EMACS, en listant les points qui ont été produits.

Ce serait intéressant (mais probablement lourd à produire) et potentiellement très puissant, si nous pouvions annoter les commentaires des personnes avec des "points-clés". Peut-être que nous devrions appeler cette idée une "GrangeCommentaire?" ou une "GrangeWiki?."

Ce serait très facile à faire et discret.

Alors, quand vous allez remanier la page, vous n'avez pas besoin de relire la totalité de la page. Vous pouvez juste aller sur les points clés que les personnes ont identifiées dans la grange, et résumer selon ce dont vous vous souvenez dans votre tête.

C'est un des moyens qui pourrait amener à encourager le retravail : en le rendant plus facile à produire.

Le système devrait être intallé pour permettre l'usage de la grange.

Les commentaires des personnes occuperaient les 60% à gauche de la page. Les 40% à droite sont réservés pour la grange.

Pour ajouter quelque chose dans la grange, vous cliquez dedans et saisissez une phrase courte. Cela devient une phrase-clé..

C'est "wiki," dans le sens où vous pouvez l'éditer, et cela applique le mécanisme de liens, l'italique, le gras etc.

J'ajouterais ici la gaucherie sociale d'effacer les ajouts d'autres utilisateurs. C'est comme les réduire au silence ou détruire leurs contributions : "Merci nous n'avons vraiment pas besoin de votre commentaire."

Pour encourager le remaniement, je ferais un résumé de deux lignes dans les modifications récentes et le coeur de notre fil-rss, modifications digérées. Pour faire un bon résumé de deux lignes, vous devez remanier la page.

Je suis en divergence très profonde (et avec quelque colère) sur la notion que c'est simplement notre "problème social".

Ce remaniement est quelque chose auquel nous "avons besoin de nous habituer".

Je suis en divergence très profonde avec la ligne : "Retravailler est un nouvel art et seul un petit nombre de personnes semble vraiment le maîtriser, s'il y en a."

Balogna. Je sais comment retravailler. Tout le monde ici sait comment retravailler. Retravailler n'est pas difficile, comme dans "nous n'avons pas de Skillz fou." Ce peut être une "forme d'art", mais tout le monde aime voir quelque chose qui a été retravaillé même juste un tout petit petit nombre de bits, par quelqu'un avec des capacités basiques.

Non. La raison simple est : nous ne le faisons pas.

Oh, je suis en désaccord très divergent avec MeatballWiki:ProblèmesRemaniement..! Et ma raison numéro un pour savoir "pouquoi les refactoring sont rares… ?"

Parce que cela n'est simplement que de la priorité pas suffisamment haute. A la fin de la journée, vous avez un choix entre :

  • (A) parler de quelque chose qui est important pour vous et immédiatement pertinent pour le contexte actuel, ou
  • (B) retravailler quelque vieux document sur le XML-RPC vs. battaille SOAP du passé.

Là où passé = quelques mois ou il y a des années. L'EchecModification arrive parce que les changements dans le monde vont plus vite que ne vont nos documents du wiki et l'EchecModification est exactement le problème avec le remaniement.

J'ajouterai que si nous nous turbo-boostons nous mêmes avec quelque technologie hi-tech de retravail, nous pouvons produire des modifications qui peuvent faire que le retravail de Haranya Loka devienne possible. Et nous pouvons utiliser quelque technologie plus hi-tech pour couper nous-même les poids morts : en lançant des pages dans des archives virtuelles et d'autres non.

Ce qui nous fera avancer ici est ordinateurs, ordinateurs, personnes et ordinateurs. Et je vous supplie dans 15 ans d'essayer et de me prouver sans rire que j'ai tort.

Linux ne peut pas être produit en faisant des allers et retours de CD à travers tout le pays. Vous devez avoir un Internet.

L'argument que Linux pourrait avoir été écrit en transportant des CDs ci et là à travers le pays parce qu'il est possible de graver des CDs et de les mettre dans des enveloppes pour les faire parvenir à destination oublie quelque chose.

L'argument que nous pouvons faire beaucoup de refactoring et que ce sera encore pertinent et n'engloutira pas le passé dans une haute-technologie wiki, mais plutôt sur le retour d'un esclavage auto-imposé, est un argument bogué.

Les encyclopédistes des villes dans l'histoire ancienne peuvent s'être fouettés eux-mêmes dans le dos avec des chats à neuf queues pour ne pas avoir été suffisamment tenaces ou solides afin d'assembler, éditer et copier les encyclopédies à la main pour tout le monde, mais nous n'allons pas faire cette erreur. Nous allons inventer des chips pour ordinateurs à la place.

C'est un échec du wiki.

BlocRésuméAvecPuces :

  • Ce n'est pas un problème social
  • C'est de la technologie
  • Tout le monde sait comment retravailler.
  • Retravailler est cher.
  • Retravailler n'est pas une priorité suffisamment haute.
  • Nous avons besoin d'ordinateurs, d'ordinateurs, de gens et d'ordinateurs.

Produisons quelque pensée critique ici : Pourquoi est-ce que vous ne pouvez pas produire Linux en transportant des CD par allers et retours à travers le pays ?

  • Les chemins de communication sont là, après tout. (Code source informatique et discussion) -→ CD-ROM -→ lettre -→ CD-ROM -→ Code source informatique.

Mais le problème est que cela prend trop de temps d'envoyer vos messages et de les faire revenir. Votre latence est trop élevée.

La récompense est moins de temps dans la venue.

Et le nombre de gens pour qui le processus est une priorité suffisamment haute tombe aux alentours de zéro.

De ce fait, pas de Linux.

Les facteurs critiques semblent être alors :

  • Les priorités gérées par les personnes qui peuvent s'impliquer dans le processus.
  • La puissance (l'énergie ou la force appliquée au fil du temps) de la technologie.

La technologie ne réfère vraiment pas au code source Linux dans cet exemple. La technologie renvoie au chemin de communications, dans cet exemple : le type gravant le code source sur le CD, puis écrivant l'enveloppe, puis la postant à l'autre type, qui l'ouvre, installe le source, lit la discussion et continue à travailler dessus.

Du fait du très petit nombre de messages et du très faible nombre d'interactions qui peuvent arriver en unités de temps, nous touchons la seconde barrière majeure : la Priorité.

Il y a tant de scénarios "tout ou rien", où vous avez eu cette étape gigantesque dans la courbe. Et ceci arrive quand quelque chose combat contre les priorités de quelqu'un. Nous avons tous fait cette expérience : "j'aurais fait ça et ça, mais cela n'était simplement pas de la priorité la plus haute.'

Et avons "eu seulement une toute petite chose de faite ?" Assistons -nous à tout avec quelque degré d'attention ? Il y a des choses qui s'échelonnent en degrés, mais il y a beaucoup d'entre elles qui touchent le quanta "tout ou rien" et nous en sommes là. C'est le truc global "PetitesModificationsProduisentDesModificationsGéniales".

Helmut, je te respecte, je suis toujours flatté de ta présence ici, je valorise ton point de vue, je t'envoie des petis coeurs avec des ailes plumées dans mes esprits à cette heure. Tu es impressionnant.

Mais je pense simplement que tu as complètement tort sur ce point :)

BlocRésuméAvecPuces :

Si nous sommes vraiment sérieux au sujet du retravail, alors je pense que nous devrions y réfléchir d'un point de vue technique : "Comment pouvons-nous modifier l'InterfaceUtilisateur wiki de façon à ce qu'elle puisse rendre le remaniement facile."

Nous avons entendu beaucoup d'idées. Et je suis sûr que nous pouvons avoir encore plus d'idées.

Je migrerais pour transitionner la discussion vers ces types de questions :

  • Quelles idées avons-nous au sujet de la manière dont wiki permet le remaniement ?
  • Quelles modifications de l'InterfaceUtilisateur faciliteraient le remaniement, une fois que vous les avez dédidées ?
  • "Qu'est-ce que le retravail ?" Quand nous retravaillons, que faisons-nous précisément ?
  • Où est le temps passé dans le remaniement ? Je parle ici de l'analyse de Therblig. Etude motion. Vieille école. Comme dans the book, pas le film. (voir : Gilbreth) 1

Questions sur la Mise en Place :

  • Que va faire l'EspritDeRuche pour mettre ça en place ?
  • Que peut mettre en place la GreaterWikiCommunity? ?
  • Que peut mettre en place AlexSchroeder ?

BlocRésuméAvecPuces :

  • Nous devrions analyser la technologie de retravail.
  • Comment fonctionne le retravail ?
  • Comment pouvons-nous le rendre meilleur marché ?
  • Que pouvons-nous implémenter ?

Voilà quelques pensées immédiates sur ce qu'est le remaniement, ou comment retravailler le ModeFil en au moins un résumé, ce qui serait un bon point de départ, non ?

  • (1) Pour chaque commentaire :
    • (1A) Lire le commentaire. Noter qui est le commentateur et quels sont les nouvelles idées majeures qui en sortent.
    • (1B) Notez l'auteur et les mots-clés.
  • (2) Regardez l'ensemble de mots-clés qui représentent les idées.
  • (3) Ecrivez les idées sobrement et succintement, sous forme de résumé.

Quelques personnes peuvent penser qu'écrire est la partie difficile. "Nous ne savons simplement pas comment ércire'. Ceci est l'étape #3. Je diverge vraiment fermement.

Ce n'est pas la dernière étape qui est le problème.

C'est l'étape 1A ! C'est toutes les montagnes, et montagnes et montagnes de lecture qui doivent être faites. Mon bon seigneur, c'est de la consommation d'énergie. Je veux dire que c'est ennuyeux à mourir de lire et relire quelque chose que vous avez déjà lu avant. Mon bon monsieur, c'est ennuyeux.

Ainsi, je penserais que si nous devions faire quelque chose, nous devrions faire ce que nous pouvons pour détruire l'étape 1A.

Et je veux dire : c'était la raison globale du BlocRésuméAvecPuces. Et à chaque fois que je les ai utilisés et revenait pour retravailler quelque chose, ces blocs résumés avec puce : je leur en étais très reconnaissant. Ils fonctionnent si bien. Cela prend beaucoup moins de temps d'aller dans le bloc, que cela ne prend de temps de tout relire et relire pour scanner les idées.

C'est ce qui m'amène à penser que la GrangeWiki? peut être une bonne idée. Prenez le côté droit de la page et faites en la grange. Peut-être que pour chaque paragraphe, nous alignons le côté droit avec le gauche. Et le rendons auto-éditable, les trucs sur la droite. Vous n'avez pas à cliquer sur "éditer cette page" pour l'avoir ; Vous mettez simplement votre souris sur le coté droit et commencez à placer des mots-clés qui relèvent les idées principales.

Ce pourrait être un début, ce pourrait aider.

De ce fait, une fois la discussion terminée, vous allez simplement sur la droite et retirez tous les mots-clés. A partir de là, vous pouvez très facilement réactiver l'ensemble de la conversation dans votre esprit, sans véritablement la relire et vous pouvez vous faire confiance pour écrire un résumé juste de la discussion ou peut-être une récriture de page complète ou ce que vous voulez.

C'est le type de chose sur lequel je peux aider.

Mais je soupçonne que cela écorche la simplicité ; n'est-ce pas Alex ?

Je sais que nous ne pouvons pas mettre en place tout ce dont nous rêvons. Je sais qu'il pourrait y avoir peu de raisons à imaginer des fonctionnalités que nous ne pouvons pas implémenter à bon marché. Je peux imaginer combien c'est irritant d'entendre des choses fantastiquement impossibles, telles que le DevelopersVirtualWorld, que nous ne pouvons pas nous-mêmes implémenter ici. (Nous le ferons, mais cela prendra les efforts d'une civilisation).

Mais nous devons sérieusement ne pas nous moquer nous-mêmes de ce que peut faire notre technologie actuelle (ou la technologie à portée de mains).

Si je devais nommer une technologie à laquelle je pense et qui est à portée de main, qui ferait une différence profonde, je nommerais un SVG wiki. Une autre est les BlocsCodeMachine : quand les programmeurs sont en train de tirer quelque donnée structurée à partir de wiki (et par cela, je veux dire : "structurée simplement au-dessus du HTML et des contenus de pages"), ceci permettra tout aussi bien tout un ensemble de choses.

La boîte résumé de choses à retravailler a été à notre portée et malgré le fait que je l'interprète comme un désintérêt pour Alex, je pense que c'est vraiment une modification géniale et je ne veux jamais revenir en arrière. Mais c'est une modification relativement petite.

Modifier comment nous devrions retravailler, je pense, doit être géant. Mais nous devrions probablement brainstormer là-dessus, si nous sommes vraiment sérieux à ce sujet. Nous devrions si nous sommes sérieux et si nous acceptons que c'est un problème de technologie et non un problème type "oh, nous avons simplement de nous donner un coup de fouet pour que nous retravaillons un peu plus nos documents", alors je pense que notre prochaine étape serait de passer quelques jours à brainstormer sur les technologies de remaniement.

Il pourrait y avoir quelque chose, très proche de (en "espace implémentation) ce dont Alex peut faire usage, pour rendre les choses plus faciles à retravailler.

Ainsi, je suppose que mes idées essentielles ici sont :

  • Etudier ce qu'est le remaniement, quelles sont les dépenses,
  • brainstormer sur les fonctionnalités,
  • voir ce qui est implémentable à court terme par Alex.

BlocRésuméAvecPuces :

  • Comment arrive le remaniement ?
    • Lire les commentaires.
    • Noter les idées majeures.
    • Ecrire un résumé.
  • Lire les commentaires et noter les idées essentielles est très coûteux.
  • Ce que suggère : la GrangeWiki?
  • Nous ne pouvons pas tout mettre en place. Mais nous ne pouvons pas tout mettre en place. Mais nous ne devrions pas nous moquer nous-mêmes de nos limites.
  • SVG wiki, BlocsCodeMachine : en étendue, probablement des effets majeurs (mais pas en retravail.)
  • Lion pense : si intéressé, nous devrions étudier le remaniement et brainstormer sur les fonctionnalités "faciles".

ThomasKalka, si mon inteprétration est juste, je suis tout à fait là avec toi. Tout à fait d'accord avec toi. J'ai été d'accord avec toi depuis des années, et nous avons les timbres datés pour le prouver !

  • Les commentaires devraient être modélisés différemment des documents.
  • Nous pouvons trouver des moyens de faire que les fils soient retravaillables, malgré les protections de commentaires et les retraitements spéciaux des commentaires.
  • Nous devrions être complètement en train de taguer nos pages, (les rendre plus faciles à retrouver, les rendre plus faciles à leur tour pour être reliées et réutilisées) et nous devrions pouvoir complètement même taguer les commentaires individuels.

Je pense que ous avons besoin, en tant que communauté de : Pulvériser l'idéal de simplicité.

Quand l'idéal de simplicité nous sert, comme nous l'avons fait avec la naissance de wiki, c'est une chose énorme. Mais cet idéal ne nous sert plus. Au lieu de cela, il est en train de nous contrôler.

Alex : je comprends que cela prend du temps d'implémenter les choses, et de maintenir les choses. Tel que je le comprends en tant que programmeur collègue, programmant depuis l'âge de 7 ans en Basic, programmant en Pascal depuis que j'ai 10 ans, montant sur C et C++ depuis que j'ai 11 ans, et parlant, écrivant et lisant dans un nombre de langages de programmation - je sais quelle grande chose est la simplicité. Mais il y a la chose globale d'Einstein : "Aussi simple que possible, mais pas plus simple."

Je pense que le format basique wiki est joliment joué. Il y a des choses que nous pouvons ajouter, comme les BlocsCodeMachine ou l'email vers les pages wiki et des trucs comme ça qui rendent les améliorations incrémentales à la forme basique et consolident la forteresse.

Mais je pense que si nous contournons ces "durs problèmes de wiki", que nous devons produire une reconceptualisation majeure de ce que nous faisons et comment les données sont modélisées dans le backend.

Si ces modifications sont impossibles à implémenter pour nous, du fait de la nature où en est la technologie wiki à cette heure, et du temps dont nous disposons, c'est ok. Nous ne devons pas produire l'ultime. Mais nous devrions au moins connaître ce que nous voulons, et pourquoi nous le voulons et comment les problèmes en sont réduits à ça même si nous ne pouvons pas les implémenter.

Ce que je veux dire en termes pratiques : si le retravail est vraiment un problème technique (pas un problème social), et si la réponse à ce problème technique est vraiment difficile et hors d'atteinte, alors nous devrions au moins connaître ces choses.

De cette façon, au moins, nous ne perdrons pas d'effort à "ouch, ouch, je m'auto-flagelle parce que notre wiki n'est pas retravaillé, ouch, ouch." Et quand les gens demandent : "qu'allez-vous faire pour le réparer', nous pouvons dire "C'est un problème que nous connaissons. Nous faisons ces petites modifications X, Y et Z qui peuvent aider un peu. Mais pour vraiment résoudre le problème, nous pensons FOO. Et FOO est difficile du fait de BAR." Où BAR est un sous problème de technologie difficile.

Puis nous pouvons pointer les gens vers FOO et BAR et les personnes peuvent travailler du sur FOO et BAR, s'ils sont intéressés.

Mais au moins nous aurons fait ça avec cette conversation.

Si nous ne trouvons pas quelque chose de facile pour supporter le remaniement, nous ne comprenons pas le problème. Le ManqueDeGranularité? semble être le problème principal. Voir SupportGranularitéDansWiki?.

Je prendrai un louvoiement différent là dessus, sans tact. ReTravailler?/ReFactoriser? est un processus de Convergence. Mais avec différents esprits projetant simplement des idées aux alentours, la Convergence semble défavorable eu égard à la technologie. Peut-être que cette croyance est contraire à l'EspritDeRuche. Quand les discussions sont à propos d'idées abstraites non destinées à mener vers le court terme WebSeitzWiki:DAndD, alors il est difficile d'évaluer où un Retravail a amélioré la clarté (ou tout autre métrique de bien) et à quel coût. Je pense que le médium TeamWiki? est génial pour faire du travail DAndD?. Je pense que le WikiPublic? est moins efficace en tant qu'espace de conversation non dirigé. Mais c'est simplement mon effet…

Vraiment, c'est quelque chose avec lequel je suis d'accord. Je pense que sur Community Wiki nous avons beaucoup de pages d'exploration ou philosophiques. Elles sont sujbectives et provisoires par nature. Il y a très peu de raffinement à produire, si vous êtes d'accord avec l'idée de départ. Autre que ça, vous pouvez discuter : diverger, diverger sur des points, offrir des points de vue supplémentaires, des liens, etc. Pour ce type d'interaction, notre système fonctionne très bien. C'est un bon mix de wiki et style de forum.

Et pour ces pages où quelques personnes partagent des intérêts et veulent investir suffisamment d'énergie, nous voyons vraiment le retravail. Et je ne pense pas que nous faisons même ça très mal. Je me souviens que les gros efforts de remaniement sur MeatballWiki étaient aussi le travail d'un individu unique dédié qui retravaillait un ensemble de dizaines de pages ou plus. Cela arrivait à peu près tous les quelques mois ! Ce n'était jamais une chose commune.

Et je suis d'accord avec Lion que quelquefois le bénéfice du retravail est trop petit -- je ferais mieux de retravailler sur quelque chose de nouveau !

Aussi, fondamentalement je pense que notre format actuel n'a pas besoin de beaucoup de remaniement.

Je pense qu'Alex a fondamentalement raison : notre format actuel ne requiert pas de remaniement.

Ceci dit, ce serait beau d'avoir des résumés de nos conversations. Retravailler n'est pas nécessairement converger sur des opinions ; Une simple "mise en valeur de conversation" serait intéressante, une convergence sur ce qui "s'est dit de notable" étant toute la convergence nécessaire qui est demandée.

Ou, peut-être que nous devrions prendre une feuille de la personne qui a mentionné la propriété de la page, (je ne peux pas trouver rapidement le texte sur cette page ?), mais au lieu de produire une propriété de page, faire en sorte que nous ayons tous une section en haut de la page où nous résumons notre position personnelle.

De ce fait, nous ne craignons jamais de déranger le texte d'un autre, mais nous obtenons un véritable retravail. Cece pourrait fonctionner. Nous n'avons pas à relire tous nos textes ; nous nous assurons simplement que c'est cohérent avec nos propres pensées dans nos propres têtes. Ceci élimine beaucoup du temps dépensé à produire un remaniement.

Tout ce qui amène probablement une communauté plus proche du point de pouvoir écrire un bon résumé de page en trois lignes, réagir rapidement sur les développememnts d'un chemain de pensées (résumé sur modifications récentes et dans le fil rss) est bien.

Lion, je suis fondamentalement d'accord avec ta critique sur mon point de vue, qui me semble désormais une voie démodée ou stéréotypique. C'est démodé parce que les personnes aiment répondre que "quelque chose n'est pas fait" avec "oui, c'est parce que c'est difficile à faire". Tout comme les gens sont agréables avec les autres et se promettent de l'aide, mais "n'ont simplement pas de temps" par la suite. Ton "Les personnes ne sont simplement pas intéressées" est beaucoup plus en rapport avec le point, même si je ne suis pas habitué à ce que cw soit socialement direct. Cette conversation à propos de "l'art du retravail" est définitivement bancale, même s'il y a probablement dedans une sorte d'artisanat et même si nous savons que quelques personnes le font extrêmement bien (Alex par exemple), que d'autres ne le feront pas et je ne vois pas comment tu peux dire que "tout le monde peut" si nous sommes dans la situation où "personne ne le fait". C'est un peu comme "tout le monde peut chanter". Ce qui est avéré, mais la qualité du chant n'est pas toujours une invitation à l'écoute. Mais ce n'est pas le point-clé. Tu as raison. Point.

Les wikis n'offrent pas beaucoup de support technique pour le remaniement et cela fait du sens de penser à propos du SupportTechniquePourRetravailler.

Par respect pour les pages et les contenus que vous n'aimez pas, pourquoi ne commentez-vous pas ou ne les modifiez-vous pas ?

Personnellement, j'aime lire les pages web qui ont les points-clés en gras. S'il y avait une convention communauté pour le supporter, peut-être que nous pourrions tous démarrer à écrire comme ça.

Ou nous pourrions avoir quelque autre syntaxe pour fournir un contexte différent comme quand on utilise des marqueurs. Les types de 37signals utilisent ça pour souligner leurs textes.

En outre, JakobNielsen recommande encore l'utilisation du gras pour mettre en valeur les phrases-clés sur les pages web.

Je ne suis pas d'accord avec Lion sur le fait qu'il soit si trivial de savoir comment retravailler les pages. D'abord, je ne suis pas sûr jusqu'à quel point vous pouvez compresser une conversation sans que vous n'en perdiez quelque chose, voir Conversational writing kicks formal writing's ass.

J'adore cet article, je l'ai transmis à des milliards de personnes et je crois même l'avoir pointé ici. Vous vous souvenez que j'ai écrit ici LangageClair non ? Je n'ai absolument aucune idée comment ce magnifique article réfute ce que je suis en train de dire ici. Le problème de comprimer les conversations est de "perdre quelquechose." Si quelque chose est occasionnellement perdu même si c'est important, ça va aussi. Si c'est vraiment important, quelqu'un le remarquera et le remettra lui-même.

Note

Cette page a démarré sur LackOfReworking


LangueFrançaise PageTranslation LackOfReworking

Footnotes:

1. Lion, commentant sur “Cheaper by the Dozen,” le film : “Oh, God; What a sad, sad, sad day it is for the Gilbreths.”

Define external redirect: GrangeCommentaire ManqueDeGranularité GrangeWiki GreaterWikiCommunity ReTravailler DAndD TeamWiki ReFactoriser WikiPublic SupportGranularitéDansWiki

EditNearLinks: InterfaceUtilisateur JakobNielsen MeatballWiki ModificationsDigérées

Languages: