{"partition": "head_middle", "source_domain": "www.gentoo.org", "digest": "sha1:X22MEMUQYUYGVSPHUYBG3XZWW5XBCBIO", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00026.parquet"}
La politique concernant l'étiquette
[ Sommaire ]
[ >> ] 2. La politique concernant l'étiquette
Table des matières : Introduction et quelques suggestions simples
Ce que vous devez essayer d'éviter
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
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 »