Visualiser une révision

Rédiger des dépêches noyau

BAud : révision n°11 (19 septembre 2014 21:58:01)

En complément du [[[template-des-news-noyau]]] et afin de [[[participer à LinuxFr]]], quelques [[[rédacteur]]]s se sont organisés.

## les sites à suivre

Vous les connaissez sans doute déjà ?
Dans les grandes lignes, suivre les sites suivants pour trouver les informations pour rédiger :

-    https://lkml.org/
-    https://lwn.net/
-    http://www.linuxfoundation.org/news-media/lwf
-    http://www.h-online.com/open/
-    http://www.remword.com/kps_result/

Voir le §Appel aux volontaires pour s'ajouter (selon son rôle, à définir).

## le processus de rédaction

- le sommaire n'apparaît qu'après modération (ou une fois dépassé les 10000 caractères), c'est normal
- durant la phase de rédaction, le texte des annonces de Linus est copié/collé pour avoir en référence l'anglais pour aider à la relecture de la traduction (Linus emploie quelques expressions idiomatiques voire fleuries, toute relecture / transposition est intéressante). Ce texte en anglais est enlevé à soumission de la dépêche.
- la tribune de la dépêche permet de se coordonner histoire de se répartir les paragraphes :
  - choisissez votre sujet de prédilection ! Essayez d'indiquer quand vous pourrez travailler dessus afin de ne pas forcément rester en attente, si vous avez un empêchement, signalez-le, ça arrive à tout le monde
  - les remarques sont les bienvenues dans la tribune, mais n'hésitez pas à éditer, c'est comme un wiki (et vous serez dans les remerciements !)
- il est possible de faire appel à un ami ou des membres de LinuxFr intervenant sur le noyau (pour la pile graphique, c'est recommandé, histoire de ne pas simplement relayer certains points évoqués par phoronix :D)
- si vous pensez être nul en orthographe ou abuser des anglicismes, n'hésitez pour autant pas à contribuer un paragraphe ou deux ! (bon, si vous écrivez en mode SMS, abstenez-vous, on va dire). La rédaction est justement là pour permettre la relecture et les corrections au fur et à mesure (aussi connu comme _release early, release often_ que la plupart des francophiles anglophobes (re-)connaissent dans le libre :D). Le fond est privilégié à la forme (il y a la relecture pour cela, qui vous bâchera peut-être au passage, c'est le jeu :p).


Pour ceux que le Markdown effraie, pas de souci, le fond est à privilégier sur la forme et sinon il y a [[[Aide-édition]]] et l'anti-sèche au bas de la rédaction pour aider. Quelques conventions tout de même :

- essayer d'identifier les termes anglais avec l'emphase `_` de part et d'autre (traduite par de l'italique par la plupart des CSS)
- pour les termes techniques, faisant partie du code ou assimilé (chemin dans l'arborescence),  "\`"  permet de le citer `tel quel`
- passer une ligne avant les listes permet d'avoir une liste à puces automatiquement générée
- éviter de mettre un lien hypertexte sur un seul mot (surtout `ici`), l'approche sémantique recommande d'inclure les termes représentatifs du lien (et les moteurs de recherche le prennent en compte)
- pour la première apparition d'un terme technique, mettre un lien vers wikipedia permettra d'approfondir, il suffit de l'`[[encadrer]]` de crochets, voire rajouter `en:` devant comme dans `[[en:computer]]` qui donne [[en:computer]] pour envoyer vers le wikipedia anglais (page souvent plus fournie :/)


## les termes utilisés
Voir [[[traductions classiques]]] pour une liste plus approfondie.
Dans la mesure du possible par ordre alphabétique ou de préférence ou par thème :

On ne peut échapper aux anglicismes sur des dépêches telles que celle du noyau Linux, notre cher _kernel_, pour autant quelques efforts peuvent être faits, dans la mesure du possible.

- _commit_ : c'est l'opération de soumettre du code, autant le garder tel quel...
- _log_ : journal
- _merge-window_ : fenêtre de fusion ou phase d'intégration
- _mise à jour_ ou _mise-à-jour_ : cela dépend si c'est le verbe de la phrase ou si c'est un nom (mineur), au pluriel cela donne _mises-à-jour_ (préféré)
- _patch_ : là c'est plus flou, le pluriel _patches_ est souvent préféré à patchs (ou pas)
- _pilote_ : est préféré à _driver_ (qu'il faut pour autant conserver si c'est dans une phrase en anglais qui aurait été conservée ou dans un chemin de fichier, restons intelligent).
- _prendre en charge_ / _gérer_ : préférable à supporter (qui insupporte quelques-uns), _prise en charge_ et _gestion_ au lieu de support p : voir les [[[traductions classiques]]].

Q :  palm123< les RC sont soit en majuscule, soit en minuscule, on les passe tous en majuscule ?
R : Jiehong< en y regardant de plus près, Linus utilise toujours la même raison (si vous effectuez des corrections, n'oubliez pas les accords au féminin !). _Supporter_ est tout de même toléré lorsqu'il s'agit d'apporter des minuscules et les traductions respectent ça. Autant l'aide (par une distribution et ses équipes par exemple)
- _random noise_ : correctifs éparses, cette traduction est préférable à _interférences_ et surtout à _bruit aléatoire_ (traduction mot à mot)sser les titres en majuscules, mais le laisser en minuscule dans le texte.


## Notes
Discussion lors de la rédaction collaborative de la dépêche pour le noyau 3.14 publié le 23 ou 24 mars 2014 (c'est une tribune, la discussion a commencé tout en bas) :

2014-03-22 20:42:37 baud 2014-03-22 19:58:04 ok, cela a effectivement un volet motivation et implication qui me semblent à moi aussi importants pour chacun, histoire de faire de son mieux (et c'est déjà bien) 2014-03-22 20:18:22 oui, le remerciement c'est bien trouvé, on finit facilement par y passer 4h à 15h pour 4000 signes :-) rendre positif cette expérience me semble important à moi aussi

2014-03-22 20:18:22 rperier Je suis d'accord avec mupuf, c'est une chose de sain, juste et ça motive tout le monde de mettre une section contributions à la fin de cette dépêche. Je suis pas complètement d'accord pour que tout les oeufs soient mis dans le même panier si c'est tout le temps les même qui font le taff. Prenons ça pour un remerciement

2014-03-22 19:58:04 mupuf 2014-03-21 20:26:59 : Je ne suis pas d'accord. Quand il y a édition collaborative de livre, les contributions sont notées par chapitres. Je trouve ça très sain et je pense que ça motive tout le monde à faire de son mieux. 

2014-03-21 20:26:59 baud 2014-03-21 08:55:58 cette partie a vocation a disparaître de la dépêche et ne sert que de « repère » lors de la rédaction, à la fin nous serons tout auteurs / contributeurs, ce qui est le propre d'un travail collaboratif :-) Si tu le souhaites, je lance la discussion sur la ML rédaction (+ une relance pour finir cette dépêche, Linus ayant annoncé que c'était la dernière rc) 

2014-03-21 20:17:42 baud 2014-03-21 08:55:58 c'est la même notion que pour le packaging dans les distros, cela n'induit pas de notion de hiérarchie àmha (même si la distinction pourrait, a priori, le faire croire) 

2014-03-21 08:55:58 ffourcot (mais je pense être contre à titre personnel pour cette distinction mainteneur/contributeur. Un mainteneur c'est un type qu'on verra régulièrement, c'est tout) 

2014-03-20 14:08:18 rperier Fin bon après j'accepterai l'avis de la majorité hein, ce n'était qu'une proposition

2014-03-20 14:06:55 rperier A nouveau d'attribuer le status contributeur de relecture aux gens qui s'investissent vraiment et qui ont vraiment été utiles

2014-03-20 14:05:58 rperier La plupart du temps les relecteurs corrigent certaines choses, donc ils sont implicitement écrivains. C'est certe moins utile que le contenu lui même mais utile quand même et une contribution comme une autre ;)

2014-03-20 13:56:01 maboiteaspam muè, franchement honneur aux mainteneurs et écrivains selon moi. C'est moche mais je suis d'accord avec mupuf, la trad n'est pas suffisante et mal aisé au regard de l'anglais courant manipulé.

2014-03-20 13:02:38 rperier Dans la partie contributions à la fin de l'article, il serait peut être bien d'ajouter une section "Relecture" qu'en pensez vous ? histoire de créditer les personnes qui ont contribués à l'amélioration de la dépeche (orthographe, tournures de phrases etc)

2014-03-19 12:31:20 andrianarivony Désolé je n'ai vraiment pas pu être présent. Je vais essayer de faire une grosdse relecture / unification cet après midi quand même.

2014-03-17 20:31:55 illwieckz j’ai contribué la rc7 et proposé une traduction (j’ai laissé quelques termes techniques entre 4 points d’interrogation comme ceci: ??both core??, libre à qui veut d’améliorer :)

2014-03-17 11:57:42 mupuf Le but du mainteneur, c'est de forcer une personne à s'investir et suivre les mises à jour pour avoir une vision plus globale du développement. Sans mainteneur, on est à la merci des traductions bêtes et méchantes des commit logs. Parfois, on a même droit à des contre sens complets.

2014-03-17 11:56:13 mupuf 2014-03-14 19:11:47 : Un mainteneur est quelqu'un qui a accepté d'être responsable de la partie sur le long terme. Si il y a déjà un mainteneur sur la partie, tu ne peux t'ajouter que dans la catégorie contributeur. Si tu penses pouvoir faire un meilleur travail sur le long terme, tu peux demander au mainteneur de te laisser la place 

2014-03-14 19:11:47 ffourcot 2014-03-13 22:04:04 Je ne trouve pas la réponse très éclairante :-) 

2014-03-13 22:04:04 claudex 2014-03-10 15:50:10 si j'ai bien compris, le mainteneurs est celui qui est responsable de la partie (mise en forme, contenu...), le contributeur vient "juste" mettre du texte

2014-03-10 15:50:10 ffourcot Je suis pas certain de comprendre la notion de contributeur/mainteneur (surtout mainteneur en fait...). Cela a-t-il du sens que je me change celui de la partie réseau par moi-même ? Ou je me met contributeur ? 




Un peu de vocabulaire:

* Le _mainteneur_ d'une section de la dépêche est responsable de l'organisation et du contenu de sa partie. Il s'engage également à l'être dans le temps jusqu’à ce qu'il accepte de se faire remplacer.
* Un _contributeur_ est une personne qui a participé à la rédaction d'une partie d'une section de la dépêche. Il n'y a aucune forme d'engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n'ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez l'évolution technique du noyau dans une partie, veuillez contribuer votre expertise au reste de la communauté. C'est un travail important et très gratifiant qui permet aussi de s'améliorer. Essayons d'augmenter la couverture sur les modifications du noyau !


=== propositions

envoyer un mail systématiquement

%erci de votre participation c'est tous les 3 mois qu'il faut le faire !

Ce mois-ci (il n'est pas trop tard) : https://linuxfr.org/redaction/news/sortie-de-linux-3-15