Wiki Rédiger des dépêches noyau

Licence CC by-sa
Tags : aucun
1
11
fév.
2014

Sommaire

En complément du template-des-news-noyau et afin de participer à LinuxFr, quelques rédacteurs 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 :

Note : pour retrouver la synthèse publiée sur lwn facilement (stats, synthèse des changements majeurs), surveiller http://lwn.net/Kernel/ où la synthèse est généralement publiée quelques jours après la dernière rc (et le plus souvent avant la publication officielle du noyau). Ces articles sur lwn sont publiés sous licence CC-by-sa 4.0, ne pas oublier de citer Jonathan Courbet.

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

Questions / réponses

Q: Pourquoi la dépêche est-elle sous licence CC-by-SA 3.0 et non CC-by-SA 4.0 comme les autres contenus de LinuxFr.org ?
R: ?

le processus de rédaction

Suite aux remarques (pertinentes) de rogo< sur la dépêche du 4.4 vous êtes incités à éditer cette page wiki et ajouter vos questions/proposition directement dans la page ou initier des discussions en commentaires, il y aussi la ML rédaction mais autant ne pas se disperser même si cela rameutera encore d'autres personnes :p). Les points à améliorer : être moins générique et plus spécifique, donner des indications claires plutôt que génériques (par partie, a priori), noter les décisions antérieures et les bonnes pratiques identifiées en tribune (pour ne pas les perdre dans le temps et l'esprit collectif des rédacteurs de dépêche noyau). Tout le monde est acteur, pas seulement le responsable identifié de coordination de la dépêche (ça tombe bien, pour celle du 4.5, personne ne s'est encore mis en avant alors que cela serait utile…).

  • 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 des traductions classiques, car 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 mais permet la comparaison/correction jusqu'à la dernière minute par ceux qui seraient plus doués en anglais et effectuant une relecture attentive pour éviter les contre-sens).
  • 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 !)
    • indication : les remarques sur le contenu devraient être directement placées dans le texte de la dépêche, cela permet directement de l'enrichir (liens, paragraphes intéressants à traduire), dans la tribune ne devrait rester que de la coordination et des relances par rapport à une partie stable ou modification substantielle à relire
  • il est possible de faire appel à un ami ou des membres de LinuxFr.org 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 (oui : peu de monde comprend ce fonctionnement :/)
  • é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 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 : 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 les minuscules et les traductions respectent ça. Autant laisser 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) : sortie de Linux 3.15

  • # Explications sur me rôle des mainteneurs et contributeurs tirées de la dépêche du 3.14

    Posté par (page perso) . Évalué à 2 (+0/-0).

    2014-03-17 mupuf : 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.

    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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.