[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]

2. La politique concernant l'étiquette

• Introduction et quelques suggestions simples
• Ce que vous devez essayer d'éviter
• Trucs et astuces

2.a. Introduction et quelques suggestions simples

Ces suggestions sont faites pour servir de guide simplifié à ce que les Relations entre Développeurs voient comme étant une bonne étiquette pour les développeurs. Elles devraient couvrir l'ensemble du sujet et devraient être appliquées autant que possible.

Cela ne veut pas dire que nous voulons que vous suiviez ce guide à la lettre : cela ne veut pas non plus dire que vous devez être d'accord sur tous ses points. En revanche on espère que tous les développeurs gardent une sorte de standard dans le comportement vis-à-vis de la communauté. Cela dit, vous pourriez être sanctionné ou suspendu si un tel standard n'est pas atteint.

Par standards raisonnables, nous n'entendons pas que vous agissiez d'une manière la plus formelle possible ou que vous parliez comme un CEO. Nous voulons juste que vous ayez du respect autant envers les développeurs qu'envers les utilisateurs, quelles que soient les opinions de chacun (même si vous pensez qu'ils ont tort).

Vous devez faire votre possible pour écrire avec le moins de fautes d'orthographe et de grammaire, où que vous soyez : que ce soit dans les messages de soumission CVS, dans un ChangeLog ou même sur IRC si vous voulez être bien vu par les autres. Mais ne vous inquiétez pas. Ce n'est pas dramatique si vous n'y arrivez pas. Vous ne le remarquez peut-être pas, mais en essayant de corriger tout ça, le temps passé à essayer de lire vos phrases est largement augmenté si vous ne faites pas un effort. D'un autre côté il ne faut pas non plus perdre trop de temps à essayer d'être d'une éloquence extrême qui sera longue à déchiffrer.

2.b. Ce que vous devez essayer d'éviter

Vous devez essayer de ne pas être brutal, rude, abusif ou impoli, quelles que soient les circonstances. Parfois, un simple commentaire sarcastique peut changer le regard que porte le lecteur vis-à-vis de ce que vous écrivez. Si vous pensez devoir dire quelque chose de désagréable au point de déranger et que vous avez vraiment besoin de le dire, assurez-vous que les gens comprennent que vous n'essayez pas d'être offensant.

Souvenez-vous que vous êtes un représentant officiel de Gentoo. Cette fonction doit vous rappeler que vous devez garder un certain niveau de professionalisme et de courtoisie dans votre vie de tous les jours face aux autres développeurs et aux utilisateurs.

2.c. Trucs et astuces

ChangeLogs

• Rendez vos ChangeLogs lisibles par un utilisateur moyen : essayez de garder les choses simples et courtes autant que possible, mais n'oubliez pas de donner toutes les informations critiques nécessaires. Souvenez-vous que les ChangeLogs doivent être écrits dans un bon anglais, même s'ils sont courts. La ponctuation est, par exemple, essentielle.
• Merci d'éviter de parler dans un langage « gentooifié », sauf pour des termes acceptés classiquement comme « ebuild », « eclass »ou « Portage ». Si vous commencez à écrire beaucoup, utilisez une ponctuation juste et bien placée.

• Tout nom de fonction doit être encapsulé dans des signes de ponctuation.
• Écrire : « version bump. » c'est bien ; écrire « Version bump; see bug #... » c'est beaucoup mieux. Cela n'aide pas seulement l'utilisateur, mais aussi les autres développeurs.
• N'utilisez pas de phrases du genre « Tested for months, should work. », ou « I think this should fix the problems. » pour quelque chose qui fait ou non son boulot. C'est mieux de signaler aux utilisateurs de tester le paquet en profondeur et vous rapporter tous les bogues rencontrés.
• Quand vous faites une référence à des sections d'un ebuild, comme par exemple la variable homepage, utilisez « HOMEPAGE » en n'oubliant pas de mettre des guillemets anglais et d'utiliser la bonne casse (majuscule ou non). Cela rend les choses plus précises et indique au lecteur que vous avez effectivement changé la variable, au lieu par exemple du homepage où votre paquet ira quand il démarrera.
• Quand vous utilisez des acronymes, merci d'utiliser la bonne casse. Par exemple, « ALSA » et non « alsa », « Win4Lin » et non « win4lin ».

Ebuilds

• Essayez de ne pas faire de mises à jour continuelles sauf si c'est réellement une nécessité, par exemple si la mise à jour apporte un plus ou si c'est une correction de sécurité importante. Voici des exemples de mises à jour intempestives à éviter :
  • Vous changez des erreurs d'orthographe dans les commentaires d'un fichier de script, vous modifiez l'indentation du code ou toute autre modification du même ordre ;
  • Vous modifiez un ebuild non lié au noyau pour qu'il supporte une nouvelle version de noyau (ou une nouvelle version d'une bibliothèque) pour permettre à plus d'utilisateurs d'installer votre ebuild, mais sans rien changer pour les utilisateurs de la version courante.
  En règle générale, des corrections qui apportent des changements non triviaux sur un quelconque fichier d'un ebuild justifient une révision. Autrement dit, si votre correctif modifie un comportement pour les utilisateurs courants, vous devez faire votre révision en faisant en sorte qu'ils puissent savoir qu'ils peuvent faire une mise à jour. Veuillez consulter les règles à propos des ebuilds.
• Respectez les préférences des développeurs en matière de code. Modifier de manière inutile la syntaxe d'un ebuild augmente la charge du serveur CVS et peut causer des complications pour les autres. Les modifications de syntaxe doivent toujours être appliquées si elles apportent un réel plus, comme par exemple une compilation plus rapide, des informations supplémentaires pour l'utilisateur ou une conformité aux politiques du projet Gentoo.

IRC

• Soyez courtois et respectez tout le monde, même s'ils vous submergent de messages.
• N'abusez pas de votre position et ne discriminez pas d'utilisateurs, que ce soit pour une blague ou par pur sarcasme.
• Répondez aux questions en utilisant vos connaissances étendues. Il est toujours mieux de ne pas répondre aux questions pour lesquelles vous ne sauriez répondre sans éviter la moindre confusion. Il n'y a pas de politique sur les dommages collatéraux que peuvent causer les développeurs aux utilisateurs, mais si un développeur peut apporter de l'aide et qu'il lui est proposé par exemple un accès SSH sur la machine en panne, le développeur sera tenu responsable de ce qu'il effectuera sur la machine de l'utilisateur. De ce fait, nous ne recommandons clairement pas ce genre de manipulations.
• Si vous êtes un développeur ayant un statut d'opérateur, vous ne devez pas en abuser. Si vous êtes en désaccord avec un utilisateur, vous devez résoudre le problème de la manière la plus pacifique possible et ne pas en venir à les renvoyer ou même les bannir, sauf si la situation est vraiment sans issue et que les autres développeurs approuvent l'usage de ce type de mesure.
• #gentoo et #gentoo-dev sont des canaux de discussion où le langage est poli et courtois. Les autres canaux de type #gentoo- suivent les règles établies par leurs propriétaires respectifs. Puis que la majorité du traffic sur #gentoo-dev est générée par des développeurs Gentoo, les gens perçoivent ce canal comme celui qui représente officiellement Gentoo. Afin de présenter Gentoo de manière la plus professionnelle possible nous demandons que les développeurs gardent #gentoo-dev de manière la plus professionnelle possible.

Forums

• Soyez courtois et respectez tout le monde, même s'il y en a qui posent des questions inimaginables. Soit vous répondez de manière courtoise, soit vous ne donnez pas votre opinion.
• Suivez les règles du forum et essayez de rester dans le fil du sujet au lieu d'en sortir.
• Essayez d'être actif. Si des utilisateurs demandent pourquoi quelque chose a été ajouté, merci de l'expliquer. Si les utilisateurs demandent pourquoi un élément est manquant, expliquez-le. Utilisez vos connaissances et aidez dans la mesure du possible. Cela dit, si vous ne savez pas, ne répondez pas, pour éviter toute confusion.

Courrier électronique

• N'envoyez pas de courrier électronique en HTML (cela peut énerver) et il est recommandé d'utiliser un client mail qui formate le texte (80 caractères par lignes, etc.) avant l'envoi. Certaines personnes bloquent les mails contenant du code HTML, ce qui peut occasionner quelques problèmes dans les correspondances.
• Quand vous répondez à des utilisateurs ou développeurs par mail, soyez courtois et ne renvoyez pas un utilisateur à un autre développeur. Essayez d'expliquer pourquoi les choses sont ce qu'elles sont, dans la mesure du possible. Un exemple à suivre par exemple, serait : « Je transmets votre courrier à <insérer un nom ici> dans la mesure où <personne> est désormais le mainteneur de ce paquet. Toute question se rapportant à ce sujet doit désormais être adressée à <personne>. Veuillez nous excuser du dérangement que cela peut vous occasionner. »

[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.