Auteurs, qu'est-ce qui vous motive(rait) ?

Maintenant j'ai peur (c'est une crainte, pas une critique) que ça devienne le lieu de tous les savoirs populistes.

Qu'appelles-tu savoirs populistes ?

Que le peuple réclame. (?)

PS : Holosmos dit des choses très sensée à mon avis !

+1 pour tout. J'ajoute qu'en tant que valido, suivre les bêta n'est pas facile. Déjà pour retrouver le topic bêta d'un tuto en validation il faut passer par le profil de l'auteur, chercher dans ses messages postés… Y'a mieux .

Et faudrait vraiment un système de commentaires "in-tuto". Un peu comme les commentaires dans les PDF ou les documents Office. Pour les bêtas ce serait le top.

J'y avait réfléchi 5 minutes il y a pas longtemps sur IRC¹ : le gros problème "technique", c'est de savoir à quoi "ratacher" les commentaires. Si il est facile de ratacher les commentaires à un mot, une lettre ou un paragraphe, ça devient moins évident quand le contenu est constament en train de changer : à quoi rattacher le commentaire alors ? (donc GG les ingénieurs de chez Microsoft pour celle là, et dans une moindre mesure ceux de Github²). Ça demanderait d'y réfléchir plus sérieusement, puisque c'est une demande récurente, mais j'ai aucune idée de comment faire ça à priori.

@pierre : j'y avais également un peu réfléchi. Pour moi, on attache des commentaires à une version et si, comme sur GH, le passage d'une version à l'autre ne rend pas le commentaire obsolète, on le conserve.

Pour cibler un passage particulier, il ne me semble pas absurde, du moins dans un premier temps, d'utiliser la syntaxe Markdown ``.

un guide de la bêta où auteur et relecteurs savent ce qu'ils doivent faire ;

Prévu

Partons du travail déjà effectué par la communauté et Vayel sur ce post .

Le mieux serait de rattacher aux paragraphes. Mais c'est vrai que c'est un truc assez bordélique à gérer. Une solution pourrait être de les stocker "en dur" directement dans le Markdown, mais ça polluerait le tout lors de l'édition via le textarea. Ou alors il faut passer par un "textarea" en contenteditable (genre comme StackEdit.io) et ne pas les afficher.

C'est un peu ce que OC a réussi à faire avec CLAIRE. Chaque élément est pourvu d'un ID stocké séparément en bdd, il est donc assez facile d'identifier chaque élément. Ici, la nature même du Markdown rend ça plus complexe.

En attachant un commentaire à un paragraphe et une version, ça permet d'avoir un truc relativement facile à gérer. Lors de l'ajout d'un commentaire, il n'y a pas de question à se poser, il suffit d'enregistrer le numéro de la version commentée et un identifiant de paragraphe (genre, la partie + numéro de paragraphe), l'identifiant ne changera pas vu qu'il est rattaché au numéro de version.

Lors d'une nouvelle version, si le paragraphe n'a pas changé, on migre automatiquement le commentaire à la nouvelle version (a priori, pas difficile). Si le paragraphe n'est plus présent dans la nouvelle version (parce qu'il a été modifié/supprimé/déplacé dans une autre partie), on ne migre pas le commentaire et on signale à l'auteur qu'il faut qu'il migre lui-même le commentaire : c'est lui le plus à même de savoir si le commentaire est toujours d'actualité ou non et si oui, où il faut le mettre. Ça nécessite donc en plus d'avoir un mécanisme qui permet à l'auteur de déplacer un commentaire entre les versions/paragraphe, à moins que l'on limite la migration d'un commentaire à un paragraphe de la version la plus récente.

Au passage, il pourrait être intéressant de faire d'avoir des commentaires rattachés à une partie entière du tuto, à moins d'utiliser une convention du genre commenter le premier/dernier paragraphe lorsque l'on veut parler de la partie entière.

Grossièrement, pas si éloigné de :

Mais avec une touche de « on est le peuple, on a le droit de savoir, démerdez vous pour qu'on sache ».

Ce que j'entends par là, c'est un mouvement de réactions du genre « c'est compliqué, mais rendez ça simple pour qu'on sache sans effort, on en a le droit et vous en avez le devoir ».

Tu veux dire qu'il ne faut pas simplifier à l'extrême et que certaines notions ne peuvent être expliquées trop simplement au risque d'être dénaturées ?

Je crois qu'il parle de l'idée suivante : Si un auteur à la malchance de ne pas publier un contenu pour débutant, il se prendrait des remarques désobligeantes en Beta-lecture tout comme après la validation.

Je ne pense pas que cela soit problématique, contenter tout le monde c'est dur. Surtout si on fait un contenu très avancés.

Cela prend en compte la "sur-vulgarisation" du coups.

https://zestedesavoir.com/forums/sujet/3211/annotations-pour-validation/

Mais je n'avais pas reposté dans la ZEP que tu avais créée sur l'ergonomie de la validation vu que pour moi c'était plus une petite suggestion qui méritait réflexion avant de s'embarquer plus loin.

Actuellement sur les tutos que je valide j'utilise un Framapad en ligne (ça me permet de relire depuis n'importe où) où je reporte mes remarques par partie. Sauf que je trouve que faire un commentaire directement sur le texte est parfois plus simple pour comprendre la remarque.

Il faut faire attention aussi à ne pas que le système d'annotations vienne "pourrir" la relecture à cause de 50 annotations sur le même paragraphe. Peut-être dans un premier temps réserver ce système aux validateurs pour voir comment il fonctionne, comment les gens s'en serve, etc.

À partir d'un certain stade ça n'est même plus de la simplification.

Typiquement, en mathématiques, une grosse majorité des notions sont déjà simples. Dans le sens où, on ne peut pas les réduire dans leurs énoncés sans changer d'objet.

Il y a un moment où pour apprendre il faut apprendre et pas attendre. On peut rendre les choses simples mais rarement faciles. Et ça n'est pas par manque de volonté. Si on pouvait exprimer toutes les maths dans un langage et un niveau de compréhension digne d'un enfant de 15 ans, on l'aurait déjà fait pour se faciliter la vie.

Personne n'aime apprendre quelque chose d'inutilement compliqué. Mais reprocher à certains contenus de l'être alors qu'ils ne peuvent pas être simplifiés, ça me fait peur.

Je ne dis pas que ZdS connait se problème. Mais régulièrement je me sens confronté à des remarques qui d'ici quelques semaines reprendront ce que je viens de dire. Et pas toujours venant de membres lambda pseudo-éclairés (ce qui est plus inquiétant).

Cela dit, pourquoi pas définir ? Par exemple en géographie, la ville est différent du sens commun. En donnant une définition, on rend le discours compréhensible.

Je ne vois pas bien le rapport.

Mais définir ne rend pas forcément la chose plus facile. L'écrasante majorité des définitions n'ont aucune utilité pour comprendre un sujet, mais uniquement pour le formaliser.

dans la plateforme actuelle, vous incite à publier sur ZdS ?

C'est le SdZ mais en ouvert et je peu me concentrer sur un GROS tutorial.

dans la plateforme actuelle, peut vous rebuter pour produire du contenu ?

Rien ne m'arrete a par mon propre temps. Quelques trucs un peu fatiguant dans l'interface. Mais on s'y fait.

vous inciterait à publier sur le site, notamment sur un sujet particulier (par exemple, un contenu pour débutants) ?

Si je peu me permettre. Ce ne seront pas les petits contenus qui feront le site mais les gros tutoriaux de reference. Comme ceux due SdZ.

faciliterait l'aide aux auteurs ?

Je propose un systeme de "watching". Ainsi. Un gars qui a fait un tuto (ou sont habitue) sont notifie quand un nouveau tuto prends de l'ampleur. L'idee est d'etre proactif. Quand un tuto commence a devenir grand mais toujours cache, quelqu'un peu venir chaleureusement l'aider. Le guider.

Comment attirer (de manière pratique) de nouveaux auteurs (des visiteurs (non-membres) qui seraient intéressés pour contribuer) ?

A mon avis, les "articles" (ces news communautaire de haute qualite) sont vraiment bien. Il faut continuer et les encourager. Ainsi, en plus de tutoriaux, le site devient un site de news vraiment bonne tourne autour de la connaissance avec des news qui vont au bout des choses.

Absolument d'accord !
A mes yeux, les petits tutos sont bien souvent spcécialisés ou destinés à un public avertie. Ils attirent donc beaucoup moins de monde.

Je ne suis pas sur d'avoir tout compris mais un système de Watching me parait intéressant, c'est une autre forme de mise en avant du contenue et ca me plait. On pourrait facilement imaginer un système d'abonnement / d'inscription à un tuto et recevoir une notification lorsque celui est mis à jour ? (un peu à la manière du forum)

Comme on parle de watching, est-ce que une option pour recevoir un email à chaque tuto/article/topic est envisabeable ? Comme ça a été dit ailleurs, il y a majoritairement deux types de personnes qui viennent sur ZdS : ceux qui viennent régulièrement et d'autres qui viennent beaucoup moins régulièrement pour voir les nouveaux articles/tutos. Ce deuxième groupe apprécierait sûrement un email à chaque tuto/article sorti. À approfondir ? Je crée un topic dans Bugs et suggestions* ?

Ça permettrait d'éviter que cette seconde catégorie oublie ZdS.

Je verrais bien des groupes d'intérêt plutôt. On peut regrouper les gens par centre d'intérêt (un genre de tag sur le profil), ce qui peut permettre d'identifier des groupes dans la communauté. Après faut voir ce qu'on peut en faire. D'ailleurs ça recoupe éventuellement avec les discussions sur la nouvelle page de profil.