Quoi que vous fassiez, faîtes en sorte que ce soit complètement transparent s’il vous plaît. Je n’ai aucune envie de devoir apprendre git pour pouvoir contribuer.
Bon, je vais partager mon ressenti et faire quelques propositions … à voir ce que ça donne.
Déjà pour ma situation, je suis un auteur plutôt actif. Cette année j’ai écrit des dizaines de pages de vulgarisation, écrits des dizaines et des dizaines de pages de contenus universitaires. Tout ça pour dire que je sais écrire et que j’ai des idées d’écriture (déjà des projets pour 2019…).
J’ai écrit des contenus sur ZdS. Parfois plus ou moins bien reçus … le dernier gros contenu que j’ai envoyé date d’il y a presque un an.
Voilà mes principaux points de blocage.
Voilà ce que j’aimerais voir progresser sur ZdS.
Une interface d’écriture qui soit agréable à lire pour l’auteur. Le style machine à écrire c’est drôle 5 min mais c’est ultra épuisant pour les yeux. Et puis les boutons, etc. déjà dits.
Une communauté plus souple intellectuellement. C’est un point humain difficile, mais honnêtement c’est désagréable d’écrire pour se prendre des "ouinouin je comprends pas c’est nul faut interdire" ou alors de lire des auteurs qui sortent des "personne peut me comprendre je suis trop intelligent pour vous". Je sais que je risque de m’en prendre plein la gueule pour ça, mais honnêtement ça fait maintenant des années que j’en connais certains et bizarrement c’est toujours les mêmes qu’on arrive pas à cadrer, et toujours les mêmes qui sont en or et adorables. Avoir un guide de bonne conduite serait pas la mer à boire, mais on va encore débattre des mois et des mois …
Une communication. Actuellement, il y a à peine quelques partages sur Twitter ou Facebook, mais rien qui casse trois pattes à un canard. Une comm’ c’est aussi par exemple faire des affiches et faire des partenariats. Pourquoi est-ce qu’on prendrait pas la peine d’au moins contacter les gens qui nous intéressent ? (Par exemple Zeste de Science ?)
L’équipe de communication ne fonctionne pas des masses, c’est clair. À commencer parce qu’il n’y a pas vraiment d’équipe de communication en ce moment, mais c’est littéralement un autre sujet.
Tiens, puisqu’on est dans les trucs désagréables 
, un truc possible est une mise en avant (disons même « éditorialisation ») du contenu, qui se fasse sur des temps long (pas une mise en avant épisodique). C’est-à-dire que certains contenus, qui soient attractifs ou attirant, soient mis en valeur ; un peu comme ce qui se faisait il y a fort longtemps sur le site du zéro.
L’avantage, outre d’inciter à écrire des tutos longs (et certains reprochaient sur le sujet d’il y a deux ans l’absence de tuto sur lesquels se baser pour écrire les siens1), est de désamorcer les critiques sur la complexité : un tuto complexe ne sera probablement pas mis en avant ainsi, et basta. Il ne gêne pas, ne fait fuir personne, ne limite la visibilité d’autrui…
Après, je suis bien conscient que ce genre de chose est plus dure à faire sur ZdS, à cause de la très grande diversité des thème abordés.
L’exemple donné était un tuto unity qui nécessite des connaissances en C#, et l’absence d’un tel tuto sur ZdS, obligeant soit à rediriger à l’extérieur (au risque que le lecteur ne revienne pas), soit à écrire le dit-tuto… Les gens qui cherchent un tuto plus complexe arrivant de toute façon peu par la page d’accueil. ↩
Il ne gêne pas, ne fait fuir personne, ne limite la visibilité d’autrui…
Et est donc encore moins lu ? C’est quoi l’intérêt de publier si c’est pour finir dans les abimes de ZdS ?
Quelles sont les chances d’arriver sur un contenu technique depuis la page de la bibliothèque ? À priori, on arrive dessus par moteur de recherche, par présence sur la page d’accueil (nouveaux contenus) ou par lien (partage, réseaux sociaux…).
Si le but1 est que les contenus les plus accessibles soient mis en avant (durablement sur la page d’accueil, ou en en-tête dans la bibliothèque), pas sûr que ça pénalise les autres contenus si on n’y accède très peu par ces moyens-là.
Malgré les récentes améliorations, une page comme ça met peu en avant les contenus. Que l’on recherche un contenu précis ou que l’on furète, il est compliqué de trouver ce que l’on cherche, ou de savoir ce sur quoi on va tomber.
C’est un vrai si. Ce n’est pas forcément notre but. ↩
Je suis un peu dubitatif sur cette discussion 
(EDIT : pour expliquer mes doutes, on parlait récemment de grosses discussions philosophiques qui servent à rien versus un peu plus de pragmatisme. Je ne suis pas sûr de voir comment cette discussion va donner des résultats concret.
D’ailleurs, si je peux me permettre, comme cette discussion est la seconde discussion "Auteurs, qu’est-ce qui vous motive(rait) ?", c’est quoi le bilan concret de la première discussion ?)
Ont été pointé, négativement, mais sans qu’on puisse agir dessus : […] la motivation.
(C’est ballot, je trouve que c’est la chose vraiment importante a faire. Quand je vois le boulot de mon éditrice, 90% de ce qu’elle faisait avec les auteurs était pour aider à conserver la motivation, ne pas lâcher quand il y avait des baisses de régimes)
De façon plus générale, j’ai l’impression que poster sur zds ne sert quasiment à rien.
Je trouve l’argument étrange. Tu n’es pas obligé de poster que sur ZdS. Si tu veux plus de visibilité que sur ZdS, tu peux publier sur ZdS et ailleurs.
Je suis dans le même cas. ZdS ne m’apporte aucune visibilité et j’ai déjà mon cercle d’experts pour les relectures techniques. Je publie sur mes sites et fais ma pub directement.
@Gabbro Du coup, pour le tableau de Gabbro, ce qui m’intéresserait, c’est de faciliter la republication de contenu. Pour le moment, même un contenu écrit en markdown est lourd à publier sur ZdS, parce qu’il faut créer manuellement les parties, copier-coller manuellement, etc. J’aimerais avoir juste a copier-coller la page markdown ici. Ou encore mieux, indiquer le dépôt ou un dossier dans un dépôt où serait les sources markdown.
- Je n’ai pas envie de passer par une phase de validation formelle
Je trouve au contraire que la validation est le principal intérêt de publier sur un site communautaire. (Puisque je n’attends pas de ZdS qu’il me donne de la visibilité). La validation du contenu, c’est ce qui va différencier un blog/billet d’un vrai article.
@Gabbro Par contre, un peu de souplesse dans la validation serait bien, en particulier si le contenu technique est déjà validé en amont. Par exemple un article qui aurait été publié dans un cadre scolaire ou pro et qui a déjà été validé par des collègues. Ou des contenus comme https://zestedesavoir.com/forums/sujet/3703/la-programmation-en-c-moderne/ qui sont relus plusieurs fois pendant la rédaction par des membres de la communauté qui sont experts dans leur domaine.
- L’interface à base de clic de l’éditeur ne me plait pas. Je veux rédiger en markdown / org sous Emacs/vim/what ever. […] En gros, je veux des PR de rédaction/relecture comme y’a des PR de code sur Github. **.
Pour le moment, l’éditeur de ZdS ne m’apporte rien en termes d’aide à la rédaction. C’est pour ca que je préfère bosser directement sur GitHub (et donc bénéficier de ses outils : édition online/offline, PRs, GitHub pages, etc). Et pour la rédaction a plusieurs, c’est plus simple aussi.
Je m’en moque un peu que ZdS propose un éditeur qui fait exactement la même chose que tous les autres éditeurs. Ce qui m’intéresse, ce sont des outils que j’ai pas encore (ou une meilleure intégration des outils). Par exemple :
@Gabbro
Un mode Plan comme dans Word, pour créer et modifier plus facilement le plan d’un article, en ayant un vue globale sur le plan.
Un système d’annotation comme dans Word, pour indiquer les corrections/commentaires lors des reviews.
Un gestionnaire de références comme zotero, pour gérer et publier facilement des refs. D’ailleurs, ca serait encore mieux de pouvoir utiliser directement ce type d’outils pour la biblio d’un article sur ZdS.
Outils d’aide à la génération d’index. De table des figures. Etc. (Pour les très gros cours, qui aurait pour vocation a avoir un PDF imprimable).
L’interopérabilité avec les outils de rédaction : word/libreoffice, excel, etc.
Générer des graphiques dans le markdown directement. Pour éviter de passer par un outil externe, puis exporter le graphique en image. Et devoir tout refaire dès qu’on a la moindre modif.
Pour les articles de programmation, il serait intéressant de pouvoir mettre des snippets de code provenant d’une code plus complet et exécutable. Par exemple, si je fais un tuto pour écrire en Hello World en C++, je vais vouloir afficher la ligne de code qui permet de faire cela :
1 | std::cout << "hello, world!" << std::endl; |
Mais cette ligne de code n’est pas un programme complet executable. Donc que j’aimerais, c’est que le lecteur puisse cliquer sur cette ligne de code, pour avoir le programme complet :
1 2 3 4 5 | #include <iostream> int main() { std::cout << "hello, world!" << std::endl; } |
Avec un bouton "Exécuter" pour lancer ce programme.
Non, je ne pense pas. l’auteur initial reste maître des PR qu’il accepte ou non.
Pour chipoter. L’auteur peut s’opposer à un PR dans son article. Mais pas à ce que l’article soit forké (s’il est sous certaines licences CC) et que la PR soit faite sur le fork.
On se retrouve un peu dans un situation grotesque, où l’on peut modifier les articles des autres (comme un wiki) mais uniquement en passant par une phase très lourde. Pas sûr de voir le bénéfice.
@Gabbro J’ai tendance à etre pour les articles communautaires. On devrait pouvoir intervenir plus facilement sur les articles qui ont une licence compatible avec l’édition. L’étape de validation est suffisante pour éviter qu’un article soit repris n’importe comment par un nouvel auteur. Peut ajouter simplement un option "J’accepte que le staff puisse ajouter ultérieurement des auteurs pour maintenir à jour cet article". (EDIT : d’ailleurs, @Staff c’est le cas pour mes articles. Pas besoin de les forker, vous pouvez ajouter librement des auteurs pour maintenir a jour les articles que j’ai écrit)
Si le but est que les contenus les plus accessibles soient mis en avant
@Gabbro Les gros articles qui font venir du monde (par exemple le tuto Arduino de Eskimon) devrait etre visible en page d’accueil. Et il devrait y avoir une vraie volonté de rédaction de big tutos debutants et qu’ils soient mis en avant. C’est ca qui fait venir les gens.
J’écris aussi des tutos très techniques pour un public tres specifiques. Et j’aimerais pas trop qu’ils ne soient pas visibles du tout. Mais il faut etre honnête, ce type de tuto en page d’accueil n’apporte aucune visibilité a ZdS. Et très peu de lecteurs pour ce tuto. Le principal intérêt pour moi, c’est de pouvoir linker le tuto dans une conversation sur les forums, quand les gens veulent une réponse plus détaillée qu’un simple message.
Fin.
@Gabbro et @gbdivers, pour la mise en avant des publications je proposait ça. Assez simple à implémenter, utilisable à de nombreux endroits (page d’accueil, accueil de la bibliothèque, sous-section de la bibliothèque, voir page de membre). Ce qui permet de pallier à de nombreux manques :
Voilà. #mytwocents
Pour toutes les idées qui impliquent un quelconque développement : ben, c’est simple, /ZdS c’est du développement communautaire**. On pourra avoir les meilleures idées du monde, si personne ne se motive pour les développer, ça ne sera jamais fait. Les forums de dev et de suggestions regorgent d’idées qui pourraient être vachement bien à mettre en place, mais que personne n’a jamais développé.
Pour celle des graphiques en particulier, voir par ici.
On pourrait imaginer des hackatons. Ça fait depuis avant la sortie publique qu’on en parle. Ça aussi, il faut l’organiser.
Salut,
Je vais probablement faire des redites, bien que j’ai tout lu.
Personnellement, les choses qui me motiveraient en tant qu’auteur sont les suivantes :
De manière secondaire, j’apprécierai :
notons que zmarkdown va ajouter un module complet quant à la typographie qui fera que les guillemets seront rendus comme français, que les espaces insécables seront insérés etc. Donc à part mettre des majuscules et des points, la typographie ne sera plus un soucis après la v27.
J’ajoute que le markdown actuel gère déjà :
A partir de ', ..., -- et --- respectivement.
(EDIT : pour expliquer mes doutes, on parlait récemment de grosses discussions philosophiques qui servent à rien versus un peu plus de pragmatisme. Je ne suis pas sûr de voir comment cette discussion va donner des résultats concret.
Très concrètement, il y a plusieurs trucs qui ressortent sur la politique de validation et de suivi (y compris dans ton message). Actuellement, l’équipe arrive, officiellement, mais aussi officieusement, à la fin de la chaine. Ce n’est pas la première fois que je cherche un moyen de faire autrement (confère cette proposition (validation durant la béta) et les presse-agrumes), et ça semble demandé de la part des auteurs.
Ce suivi, ce travail d’éditeur, ZdS ne le fait pas actuellement, et ça fini avec des tutos écrit au 3/4 en déshérence sur la béta. On peux faire mieux avec 0 développement. Après l’échec des presse-agrumes, ce n’était pas dit du tout qu’il faille partir dans cette direction.
Par contre, un peu de souplesse dans la validation serait bien, en particulier si le contenu technique est déjà validé en amont.
Normalement, c’est déjà le cas. Les validations sans béta sont nettement plus lourdes.
Donc à part mettre des majuscules et des points, la typographie ne sera plus un soucis après la v27.
D’expérience, il y a aussi les listes qui sont souvent typographiées assez chaotiquement. Mais les guillemets automatiquement français, je dis « Merci ! ».
- Mise en avant de contenu cool (page d’accueil, home de la biblio);
Je parlais de mettre en avant les contenus qui attirent du monde. A mon avis, c’est surtout les big-cours. Et pour cela, ce qu’il faut avant tout, c’est des big-cours. Ce n’est pas vraiment un problème d’outils.
- Mise en avant de contenu thématique trans-domaine (genre concentré de savoir);
Pareil pour ca. L’idée est intéressante, mais cela ne nécessite pas d’outil spécifique. Il suffit de créer un (méta) article, du type "Vous voulez apprendre le Python ? Voici la liste des ressources à lire, et une proposition de plan d’apprentissage".
Un exemple de ce type de méta-article : https://alp.developpez.com/tutoriels/debuter-cpp/
HS : D’ailleurs, je ne vois pas de raison de ne pas faire cela tout de suite. Il n’est pas nécessaire d’attendre que les big-cours soient finis. Et pour régler la question de l’édition collaborative et les PRs, je lances ca sur mon GitHub.
Ca sera 2 articles "communautaires", qui n’appartient pas a un auteur (donc le staff sera libre d’ajouter les auteurs qu’ils voudront). La liste des auteurs est a mettre dans l’article directement (l’historique GitHub ne sera pas conservé lorsque l’article sera transféré sur ZdS)
Le repo est en public donc faites les commit ou les PRs que vous voulez.
Pour discuter de ces articles sur le forum :
Ou sur le discord (cf ma signature)
Et n’hésitez pas à créer ce type de méta-article pour les autres langages.
Pour toutes les idées qui impliquent un quelconque développement : ben, c’est simple, /ZdS c’est du développement communautaire**. On pourra avoir les meilleures idées du monde, si personne ne se motive pour les développer, ça ne sera jamais fait. Les forums de dev et de suggestions regorgent d’idées qui pourraient être vachement bien à mettre en place, mais que personne n’a jamais développé.
(HS : j’aime ton pragmatisme et ton ton direct)
Je n’ai pas parlé des exos par exemple, parce que c’est un projet de dev que je souhaite faire. Donc je suis d’accord a 100% avec toi : proposer une idée, c’est bien. S’investir pour défendre et concrétiser cette idée, c’est mieux.
En fait, c’est peut etre une erreur de ne pas avoir parler des exos. Pas du module d’exercices, mais de rédiger des exos. Quand on prend un livre, on ne peut pas cliquer dans les QCM qui sont dedans, mais ca n’empeche pas d’avoir des exos. Avoir des exos dans les cours est au final indépendant d’avoir un outil pour les exos.
@Gabbro Du coup, je pense que c’est a ajouter dans la liste des idées : avoir des exos dans les cours (ceux pour qui cela a un sens). La validation devrait regarder si c’est pertinent d’avoir des exos et demander aux auteurs de les ajouter. (Je crois que c’est ce que fait informaticienzero pour le cours C++ par exemple. C’est ce que je fais aussi pour mon cours).
Au pire, mettre un tag invisible dans le markdown des articles, de facon a ce qu’on puisse plus tard, quand le module d’exo sera dispo, reprendre les anciens exos et le reformater pour le module d’exo.
Ce suivi, ce travail d’éditeur, ZdS ne le fait pas actuellement, et ça fini avec des tutos écrit au 3/4 en déshérence sur la béta. On peux faire mieux avec 0 développement. Après l’échec des presse-agrumes, ce n’était pas dit du tout qu’il faille partir dans cette direction.
Ok. C’est le "Ont été pointé, négativement, mais sans qu’on puisse agir dessus : […] la motivation" qui m’a mit un doute, sur le fait de chercher uniquement des solutions techniques, sans remettre en question le processus complet. Les derniers messages me rassurent.
C’est le "Ont été pointé, négativement, mais sans qu’on puisse agir dessus : […] la motivation" qui m’a mit un doute, sur le fait de chercher uniquement des solutions techniques, sans remettre en question le processus complet.
En aucun cas. J’étais même un peu déçu de surtout voir des points techniques. 
Du coup, je t’aime aussi très fort
Ah, une fonctionnalité qui manque, c’est la sauvegarde auto des zones de texte dans un localstorage. Ça éviterait de perdre plus d’une demi-heure de texte parce qu’on a fait F5 sur la page au lieu de F4 (qui ferme le panneau latéral), parce qu’on a pas sauvegardé parce que le système de sauvegarde est pas pratique du tout.
Sur certain PC portable le F4 ferme directement le pc. Lorsque l’utilisation de la touche FN n’est pas activé dans le bios.
@SpaceFox
J’avais proposé un truc comme ca fut un temps mais il y a eu qu’un engouement modéré…
(et comme je suis totalement incompétent dans ce domaine je peux pas m’en charger … la bonne excuse )
@Vael: Ton idée a fait son bout de chemin. Avec une implémentation et tout.
Elle est juste bloquée au niveau des tests … Et la débloquée semble compliqué/chiant.
Ce suivi, ce travail d’éditeur, ZdS ne le fait pas actuellement, et ça fini avec des tutos écrit au 3/4 en déshérence sur la béta. On peux faire mieux avec 0 développement. Après l’échec des presse-agrumes, ce n’était pas dit du tout qu’il faille partir dans cette direction.
Le pépin aussi, c’est que nous sommes une communauté de bénévoles. Un travail d’éditeur, c’est à plein temps. Je crains qu’on ne parviendra pas à réaliser ceci (améliorer oui, mais véritablement faire un travail d’éditeur, un suivi…). Et idem pour l’aspect com’ (qui en est lié).
Ecrire un cours complet, c’est aussi un boulot a plein temps.
Developpez un site web comme ZdS, c’est aussi un boulot a plein temps.
On passe notre temps sur internet a faire des boulots a plein temps benevolement. On n’est plus a ca pres 
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte