Améliorer l'outil de rédaction

Bonjour =)

J’ai parcouru ce site : https://stackoverflow.com/documentation et ce site : https://www.juliabox.com/ et je trouve ces outils de rédaction communautaires superbes ! A mon sens, je trouve que ces outils permettent de motiver les auteurs à écrire et favorise les "pertes" de contenus qui restent éternellement en bêta.

J’ai conscience que ça serait un chantier énorme mais pensez-vous qu’il y aurait possibilité de voir ça sur le site à la clémentine ? Ça aurait du sens non ?

J’ai pas compris ce que tu proposes, peux-tu développer un peu ?

favorise les "pertes" de contenus qui restent éternellement en bêta.

Le but est justement d’éviter de perdre bêtement du contenu en bêta, la bêta doit amenée à une publication sur le site.

Je pense qu’il disait de façon détournée que le contenu passerait plus facilement en version finale, non ?

J’sais pas. J’ai – no offense – rien compris.

J’avoue partager le même avis qu’Arius. Je comprends que l’op veut proposer quelque chose pour qu’il y ai moins de "perte" entre les beta et les publications, mais je ne vois pas trop en quoi zds devrait s’inspirer de Juliabox ou stackoverflow…

Bonjour,

Vous n’avez pas vraiment regardé le lien qui pointe vers SO. Ce n’est pas SO classique. Je n’ai par contre pas compris où se trouvait la même chose sur juliabox. J’aurai expliqué le principe si je n’étais pas sur téléphone. :|

Salut,

Pour Juliabox je pense qu’il parle des Jupyter notebooks. Ce sont des documents qui mêlent code, explications et graphiques parfois interactifs qui se partagent facilement.

Pour Juliabox je pense qu’il parle des Jupyter notebooks. Ce sont des documents qui mêlent code, explications et graphiques parfois interactifs qui se partagent facilement.

Ha c’est du même genre que R-markdown, mais pour python si je comprends bien non ?

Mais en quoi ça serait vraiment différent de l’outil actuel de rédaction et surtout comment cela aiderait à diminuer les "pertes" lors de la mise en béta ?

Pas tout à fait. R-markdown est un peu le nouveau venu (2014) dans cette discipline, et est un logiciel de bureau.

Jupyter Notebooks (avant c’était IPython) est un vieux (2001) projet mais encore très activement développé (sa popularité est énorme et continue de croitre, principalement depuis l’avénement des data sciences, domaine où l’exploration interactive de données est central). C’est pas particulièrement pour Python. C’est une sorte de serveur web + son interface web, que tu peux lancer localement. Le code est exécuté sur le "kernel" de ton choix. Plus de 40 langages sont supportés.

Après, rien n’empêche un rédacteur d’utiliser ces outils et de convertir son notebook en markdown pour la publication, puis de mettre un lien vers le notebook pour le téléchargement (pour les Jupyter Notebooks il y a Nbconvert).

L’idée de la documentation à la Stack Overflow permettrait de régler le problème de motivation des auteurs lors de la rédaction de tutos collaboratifs: chacun peut écrire un court article qui explique quelque chose de précis, ce qui facilite la validation, puis on les organise.

Je vais tenter d’être plus clair :

Prenons au pif cette page : https://stackoverflow.com/documentation/android/85/getting-started-with-android#t=201707021117039659997, comme vous le voyez sûrement, à chaque bloques (ou sections) qui délimite les titres, on peut voir les liens : éditer, Partager et Discuter. Le lien éditer nous permet…d’éditer chaque bloques instantanément.

Ce qui es bien je trouve c’est qu’on peut rajouter des paragraphes, modifier rapidement directement et le résultat est visible pour tout le monde tout de suite, ainsi plutôt que d’écrire de son côté, les potentielles contributeur peuvent très vite contribuer et recommencer une partie le lendemain. La différence par rapport à maintenant est surtout le côté "live", ça se peut se faire en continue de tel sorte (je pense) à garder une certaine motivation pour les auteurs. =)

En faite je sous entendais les contenus en bêta disponibles dans la page des membres (donc peu visible). Parce qu’il y a pas mal de contenu en bêta parmi les membres de ZdS qui sont en pauses, délaissés.

C’est le fonctionnement d’un wiki, quoi. Les différents contenus de ZdS ne fonctionnent pas ainsi. Après, c’est vrai qu’un wiki ça peut être pratique. Mais ce n’est plus la même chose, du coup.

C’est le fonctionnement d’un wiki, quoi. Les différents contenus de ZdS ne fonctionnent pas ainsi. Après, c’est vrai qu’un wiki ça peut être pratique.

C’est en tout cas un bon format pour les tutos collaboratif comme celui proposé par Nohar pour Python.

Le truc, d’une manière générale, c’est qu’il faut tenir compte de la variété de licences que nous avons ici (et donc pas tripatouiller du contenu réservé à l’auteur), etc.

L’idée de la documentation à la Stack Overflow permettrait de régler le problème de motivation des auteurs lors de la rédaction de tutos collaboratifs: chacun peut écrire un court article qui explique quelque chose de précis, ce qui facilite la validation, puis on les organise.

En quoi est-ce impossible actuellement ? Et, plus important, en quoi ça résout le problème de la bêta ? Tu as un tuto, plusieurs auteurs qui s’organisent pour rédiger les différentes sections (= articles) et les différents chapitres.

Oui, c’est plus ouvert car le moindre inconnu peut participer, mais ça ne corrigera pas le manque de visibilité et de collaboration communautaire du contenu en bêta et de la recherche d’aide (peu de gens consultent la page d’aide). Il sera toujours noyé dans la masse. La seule différence sera que n’importe qui peut éditer et écrire n’importe quoi (petit pépin avec les licences visible à 30km) mais ça n’apporte pas une réelle solution aux contenus en retard en bêta. Ouvrir plus la rédaction n’est pas la clé qui permettra la correction du problème.

J’aime bien l’idée des jupyter notebooks dans l’idée de l’interactivité.

Oui, c’est vrai que ça complique pas mal les choses sans résoudre le problème de la beta.

Sinon, je suis partant pour publier un petit tuto sur les jupyter notebooks avec graphiques interatifs pour voir si l’export en markdown avec les graphiques marche bien et pourquoi pas inciter à publier des notebooks.

Mais on est pas obligé d’ouvrir à tout le monde, ça peut être des membres ayant tant de badges, d’ancienneté, ou quoi que ce soit d’autres ?

J’aime bien l’idée des jupyter notebooks dans l’idée de l’interactivité.

+1 =)

Pour les notebooks c’est techniquement faisable amha. Ça prendrait probablement la même forme que l’intégration jsfiddle je pense.

Après faut voir.