Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 45596 Details for
Bug 73654
[fr] new translation for devrel HB
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
hb-policy-etiquette.xml
devrel-hb-policy-etiquette.xml (text/plain), 11.64 KB, created by
Clément VARALDI
on 2004-12-09 04:18:42 UTC
(
hide
)
Description:
hb-policy-etiquette.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2004-12-09 04:18:42 UTC
Size:
11.64 KB
patch
obsolete
><?xml version='1.0' encoding="UTF-8"?> ><!DOCTYPE sections SYSTEM "/dtd/book.dtd"> > ><!-- Le contenu de ce document est sous licence CC-BY-SA --> ><!-- Voir http://creativecommons.org/licenses/by-sa/1.0 --> > ><!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-policy-etiquette.xml,v 1.7 2004/11/21 14:34:41 plasmaroo Exp $ --> > ><sections> ><section> ><title>Introduction et quelques suggestions simples</title> ><body> > ><p> >Ces suggestions sont faites pour servir de guide simplifié à ce que les <uri >link="/proj/en/devrel">Developer Relations</uri> voient comme étant une bonne >étiquette pour les développeurs. Elles devraient couvrir l'ensemble du domaine >et devraient être appliquées autant que possible ></p> > ><p> >Cela ne veut pas dire que nous voulons de vous que vous suiviez ce guide à la >lettre : Cela ne veut pas non plus dire que nous 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. ></p> > ><p> >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 pour les développeurs que pour les utilisateurs, >quelque soit les opinions de chacun -même si vous pensez qu'ils ont tort. ></p> > ><p> >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 vous faire voir par les autres, et que tout le monde passe une bonne >journée. 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 diminué 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. ></p> > ></body> ></section> > ><section> ><title>Ce que vous devez essayer d'éviter</title> ><body> > ><p> >Vous devez essayer de ne pas être brutal, rude, abusif ou impoli, quelques >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 <e>vraiment</e> besoin de le dire, assurez-vous que les gens >comprennent que vous n'essayez pas d'être offensif. ></p> > ><p> >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 fans votre vie de tous les jours face aux autres développeurs >et aux utilisateurs. ></p> > ></body> ></section> > ><section> ><title>Trucs et astuces</title> > ><subsection> ><title>ChangeLogs</title> ><body> > ><ul> > <li> > 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. > </li> > <li> > 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. > </li> ></ul> ><ul> > <li> > Tout nom de fonction doit être encapsulé dans dans des signes de > ponctuation. > </li> > <li> > Ãcrivez : "version bump." c'est bien, "Version bump; see bug #..." > c'est beaucoup mieux. Cela n'aide pas seulement l'utilisateur, mais aussi > les autres développeurs. > </li> > <li> > 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. > </li> > <li> > Quand vous faites une référence à des sections d'un ebuild, comme par > exemple la variable <e>homepage</e>, utilisez "HOMEPAGE" en n'oubliant pas > de mettre des guillemets et d'utiliser la bonne casse (majuscule ou non). > Cela rend les choses plus précises, en précisant au lecteur que vous avez > effectivement changé la variable, au lieu, par exemple, du <e>homepage</e> > où votre paquet ira quand il démarrera. > </li> > <li> > Quand vous utilisez des acronymes, merci d'utiliser la bonne casse. Par > exemple, "ALSA" et non "alsa", "Win4Lin" et non "win4lin". > </li> ></ul> > ></body> ></subsection> > ><subsection> ><title>Ebuilds</title> ><body> > ><ul> > <li> > Essayez de ne pas faire de mises à jour continuelles sauf si c'est > <i>réellement</i> 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 à jours intempestives à éviter : > <ul> > <li> > 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. > </li> > <li> > Vous modifiez un ebuild non relatif au noyau pour qu'il supporte une > nouvelle version de noyau (ou une nouvelle version d'une librairie), > pour permettre à plus d'utilisateurs d'installer votre ebuild, mais sans > rien changer pour les utilisateurs de la version courante. > </li> > </ul> > 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. > </li> > <li> > Essayez de faire en sorte que vos ebuilds ne fassent pas de taches inutiles. > Créer un paquet pour des correctifs non supportés pour apporter un "plus" > n'est pas une bonne idée sauf si ils ont été profondément testés par vous, > qu'il a été largement utilisé, et qu'il a été audité contre les > vulnérabilités liées à la sécurité. > </li> > <li> > Les ebuilds doivent être le mieux commentés possible si il intègre un bout > de code non standard ou que de gros morceaux de codes sont utilisés. De tels > ebuilds doivent également maintenir l'utilisateur informé. En d'autres > termes, ne créez pas de longues opérations "silencieuses" sans qu'aucune > notification ne soit faite à l'utilisateur. N'en profitez pas non plus pour > innonder l'utilisateur sous une montagne d'informations. > </li> > <li> > 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. > </li> ></ul> > ></body> ></subsection> > ><subsection> ><title>IRC</title> ><body> > ><ul> > <li> > Soyez courtois et respectez tout le monde -même s'ils vous submergent de > messages. > </li> > <li> > N'abusez pas de votre position et ne discriminez pas d'utilisateurs -que ce > soit pour une blague ou par pur sarcasme. > </li> > <li> > 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. > </li> > <li> > Si vous êtes un développeur ayant un statut d'opérateur, vous <b>ne devez > pas</b> 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 kicker ou même les bannir, sauf si la situqtion est vraiment > sans issue et que les autres développeurs approuvent l'usage de ce type de > mesure. > </li> > <li> > #gentoo et #gentoo-dev sont des canaux de discussion sont des canaux où le > langage est poli et courtois : Les autres canaux de type #gentoo- > suivent les règles établies par leurs propriétaires respectifs. Parce 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. > </li> ></ul> > ></body> ></subsection> > ><subsection> ><title>Forums</title> ><body> > ><ul> > <li> > Soyez courtois et respectez tout le monde -même s'il y en a qui posent des > questions inimaginables. Ou bien vous répondez de manière courtoise, ou > vous ne donnez pas votre opinion. > </li> > <li> > Suivez les règles du forum et essayez de rester dans le fil du sujet au lieu > d'en sortir. > </li> > <li> > 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. > </li> ></ul> > ></body> ></subsection> > ><subsection> ><title>Courrier électronique</title> ><body> > ><ul> > <li> > N'envoyez pas de courrier électronique en HTML -cela peut énerver- et il est > recommandé d'utiliser un client mail qui formatte 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. > </li> > <li> > Si vous utilisez un logiciel pour filtrer vos mails contre le spam, vérifiez > régulièrement le courrier qui a été rejeté comme spam pour le cas où un mail > d'un développeur ou d'un utilisateur soit passé à la trappe. > </li> > <li> > 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 rapporte votre > courrier à <c><insérer un nom ici></c> dans la mesure où > <c><personne></c> est désormais le mainteneur de ce paquet. Toutes > questions se rapportant à ce sujet doivent désormais être adressées à > <c><person></c>. Veuillez nous excuser du dérangement que cela peut > vous occasionner." > </li> ></ul> > ></body> ></subsection> > ></section> > ></sections>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 73654
:
45425
|
45432
|
45439
|
45441
|
45453
|
45595
|
45596
|
45893
|
45894
|
45895
|
45897
|
45961
|
47829
|
47830
|
47831
|
54040
|
54041
|
54042
|
54043
|
55255
|
55256
|
55257
|
55258
|
55259
|
55261
|
55487
|
55958
|
56147
|
56557