Il est temps de faire le deuil de la forme du projet initial. J’ai commencé à écrire un livre technique sur les temps de réponses des sites web il y a maintenant quelques années.
Un livre ça prend du temps
Suite à des changements professionnels et personnels successifs j’ai eu de moins en moins de temps à y accorder et la rédaction plafonne irrémédiablement à 50%. Ces derniers temps je considère même que ce taux de 50% est en chute libre car le contenu vieillit en regard des capacités actuelles des navigateurs et en regard de l’état de l’art. Voir mourir ce contenu dans lequel j’ai tant investit me semble trop difficile.
J’ai tenté d’y investir un peu plus de temps, de me faire accompagner par un auteur secondaire, de co-écrire, ou même de donner ce contenu à un auteur qui pourrait prendre la suite mais à chaque fois il est évident que le travail est énorme et que peu de gens sont à la fois suffisamment experts et avec assez de temps libre.
Un projet communautaire ce n’est pas magique
Je crois pas vraiment à l’idée qu’il suffise de relâcher le contenu dans la communauté pour qu’il soit magiquement mis à jour et enrichi. Cela peut fonctionner le premier mois mais ensuite cela demande un réel investissement avec des relecteurs, des gens pour animer, pour coordonner, et surtout de vraies bonnes volontés pour contribuer plusieurs heures.
« L’effet Wikipedia » n’est pas si courant. On compte plus de projets délaissés que de projets maintenus activement et même côté webperf il y a eu des expériences malheureuses en anglais. Relâcher son bébé dans la nature est toujours difficile mais si c’est pour le voir mourir en public c’est encore plus frustrant.
Essayons, le travail à faire
Ceci étant dit, ça vaut le coup d’essayer. L’objectif à court terme c’est extraire et convertir le contenu provenant d’un traitement de texte vers un format adapté pour un travail à plusieurs, probablement du Markdown ou équivalent, avec des fichiers par chapitre ou sous-chapitre. Les images doivent être extraites, taillées, et organisées de façon cohérente. Ensuite, une fois sous github, on pourra voir qui se sent de travailler.
Un autre billet suivra sur la question des droits d’auteurs et de la licence, ça mérite plus qu’un paragraphe. Entre temps je cherche des gens que ça intéresse suffisamment pour envisager d’aider à cette première étape d’extraction et conversion. Il s’agit d’un vrai travail, qui prendra du temps et qui nécessitera des traitements manuels. Ne vous proposez pas si c’est juste pour penser « ouais c’est génial » sans arriver à dégager des heures de temps libre sur le sujet.
13 réponses à “Livre webperf, appel aux bonnes volontés”
Salut,
Pour éviter les frustrations, je pense que donner un volume horaire minimum en terme d’engagement, permettra à chacun de voir si il peut s’engager la dedans,
Est ce que passer 2-3 heures dessus par semaine n’est pas pareil qu’y passer 10-15 heures.
Lionel
Pour la première phase, c’est à dire l’extraction du contenu, ça ne durera pas des mois. Pas besoin d’y passer 10 heures par semaines.
Salut,
Je suis du même avis que Lionel: pas évident de se représenter la charge de travail.
Quelques infos supplémentaires pourraient sans doute aider à se faire une idée. Par exemple:
– Combien de pages/mots sont déjà rédigées?
– Combien de chapitres/sections?
– Combien d’images à traiter?
Pas besoin d’être très précis, une estimation « à la louche » c’est déjà un bon indicateur ;)
Olivier
Il y a 150 pages A4 sous Open Office, en corps 11 ou 12 (il faudrait que je vérifie). Il y a je pense un schéma ou une immustration toutes les 5 pages (à la louche).
Par contre ce n’est pas que du paragraphe : il y a des titres, sous titres, sous-sous titre, il y a des tableaux, il y a du code dans les paragraphes, il y a des blocs de citations, il y a quelques (rares) notes en bas de page, il y a des renvois vers des titres ou paragraphes (à voir s’il faut les refaire ou pas), et il y a des blocs de code.
La mise en forme est globalement inexistante en dehors des styles par défaut par contre, donc ce n’est pas ça qui posera problème.
Je suis toujours autant déçu de ne pas avoir eu le temps de m’investi plus dans ce livre, et bien décidé à aider à la préservation/mise à jour/enrichissement de ces 50% déjà si riches.
Je connais déjà le contenu, je connais Markdown et Github, cela devrait m’éviter de perdre du temps sur la mise en œuvre !
Je veux bien aider à filer un coup de main sur une partie du contenu.
Je connais sphinx (et son format reStructuredText – .rst). On peut faire de belles choses avec (cf. la doc de symfony par exemple : https://github.com/symfony/symfony-docs/).
C’est une très bonne alternative à Markdown.
Je ne connais pas Markdown ni aucun autre format mais je suis partant pour aider ce projet et mettre la main à la pâte.
Le kick-off c’est pour quand à peu près ?
Temps disponible avant Paris Web = 0h par semaine.
Et pourquoi ne pas le sortir justement par petits morceaux programmés, plutôt qu’un gros pavé décourageant.
1. Une petite unité de contenu, pas plus de quelques pages.
2. Accompagné d’une période d’ouverture d’issues (pendant une semaine)
3. Rédaction et réponse à ces issues pendant la 2eme semaine.
4. Clôture de cette unité.
5. Unité suivante.
Il sera toujours temps une fois l’ensemble étoffé de refaire une revue complète.
[…] Livre webperf, appel aux bonnes volontés […]
[…] La suite du livre webperf : appel aux contributeurs : : via @edasfr //Eric cherche des contributeurs pour poursuivre son livre sur les webperfs, de manière numérique (wiki, ebook…) […]
Je vais dire p-e une connerie, mais tu n’as jamais songé à Openweb pour des articles sur la performance ? J’imagine que tes données et recherches pourraient inspirer de très bons articles.
[…] c’est fait. J’ai commencé la retranscription de mon livre sur la performance des sites web vers github pour en faire un projet […]