[fedora-fr-doc] tuto ntfs-3g et tuto services sous Fedora

Hervé Riboulot herve.riboulot at wanadoo.fr
Dim 11 Mar 08:52:20 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour,

Je ne reviens sur le point concernant ntfs-3g: l'essentiel est d'avancer
et émettre l'idée ne confère aucun droit particulier quant à la
production de l'ébauche. Eu égard au cadre dans lequel nous travaillons,
tout reposant sur la bonne volonté, il importe d'amorcer le travail, le
reste est littérature. Le Wiki est là pour offrir le moyen d'un travail
collaboratif sur un document publié (à défaut de document de base, les
volontés se dissipent ...).

Sur la méthode proposée par Thierry:

> - proposition sur la ML

C'est le départ; maintenant, quelles règles appliquer pour amorcer
effectivement le travail?

Je suggère quelques points, hérité d'une expérience longue en matière de
doc. de spécifs et normalisation:

1- on ne publie pas seulement l'idée mais surtout un plan indicatif avec
quelques arguments rédigés pour indiquer ce que l'on vise (sinon, on
reste dans l'intention générale et se positionner est bien dificile)
2- a minima, 3 personnes s'engagent sur le sujet et le plan, y compris
en apportant des propositions de modification

> - rédaction ( pendant que la rédaction est en cours prévenir le
> rédacteur avant toute modificiation )

Oui et non. Le Wiki permet de relire les modifs et on peut ouvrir une
page discussion en parallèle (page qui sera supprimée après publication
du document final). On ne doit avoir recours à la ML que dans le cas de
pb de fond, qui, pour être traités, supposeraient une plus large
contribution. Sinon, la ML deviendra illisible.

> - annonce sur la ML de la fin de la doc

Oui.

> - correction
> - validation
> - relecture
> - passage en prod

Là, je ne comprends pas vraiment. Si le doc. a été rédigé au sein de la
communauté des rédacteurs, lu et relu en son sein, on doit entrer dans
un schéma plus direct:

* relecture du naïf pour corriger les fautes, le jargon et tutti quanti
* appel à commentaires finals (oui / non on publie et si "non"
pourquoi?). Il n'y a plus de modif à ce stade, l'essentiel ayant été
acquis antérieurement, sous l'égide des personnes qui se sont impliquées
dans la rédaction. Si nous n'optons pour cette forme d'action, nous
risquons d'entrer dans un consensus mou et ne pas aboutir. D'expérience
(les tutos Grub, dual boot, ipw2200bg, ...), l'avis des quelques experts
impliqués suffit largement pour stabiliser le document et il n'est nul
besoin de jouer les prolongations au-delà d'un certain seuil (le rapport
signal/bruit devient cata ... et on perd du temps).


Nota: à la réflexion, en lisant notamment les remarques de Patrick, je
me dis que la traduction des tutos en anglais est une connerie (encore
une idée que nous n'arriverons pas à porter sauf acte d'autorité). Ne
dispersons pas nos quelques capacités ...

A plus

Herrib
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF87UydA3nEeKgQToRAhjVAKCB8rB7u9QwUkUDJenmwzUP1Fsb0wCeKI9t
ZORCUYgyVQ9Ezu3Ubbr90pE=
=8aJS
-----END PGP SIGNATURE-----




Plus d'informations sur la liste de diffusion fedora-fr-doc