Author: bertrand
Date: Wed Aug 1 07:14:07 2007
New Revision: 869
Log:
Ch02 review 2
Modified:
trunk/fr/ch02.xml
Modified: trunk/fr/ch02.xml
==============================================================================
--- trunk/fr/ch02.xml (original)
+++ trunk/fr/ch02.xml Wed Aug 1 07:14:07 2007
@@ -630,18 +630,19 @@
pour simplement installer et utiliser le logiciel, mais n'est pas
suffisant pour déboguer ou ajouter de nouvelles fonctionnalités.
Les extractions de sources journalières sont utiles, mais pas
- d'une granularité adéquate pour développer une communauté de
- développeurs. Les gens ont besoin d'accéder en temps-réel aux
- sources dans leur état courant et le moyen de leur offrir ce
- service est d'utiliser un système de Gestion de Configuration
- Logicielle (GCL). Le fait de fournir un accès anonyme aux sources
- en GCL est un signe -à la fois dirigé vers les utilisateurs et
- vers les développeurs- que ce projet fait un effort particulier
- pour fournir aux gens ce dont ils ont besoin pour participer. Même
- si vous ne pouvez proposer la GCL tout de suite, laissez une
- indication que vous allez le faire sous peu. L'infrastructure de
- gestion de configuration logicielle est développée en détail dans
- <xref linkend="vc" /><phrase output="printed"> du <xref
+ d'une fréquence adéquate pour favoriser l'émergence d'une
+ communauté de développeurs. Les gens ont besoin d'accéder en
+ temps-réel aux sources dans leur état courant et le moyen de leur
+ offrir ce service est d'utiliser un système de Gestion de
+ Configuration Logicielle (GCL). Le fait de fournir un accès
+ anonyme aux sources en GCL est un signe -à la fois dirigé vers les
+ utilisateurs et vers les développeurs- que ce projet fait un
+ effort particulier pour fournir aux gens ce dont ils ont besoin
+ pour participer. Même si vous ne pouvez proposer la GCL tout de
+ suite, laissez une indication que vous allez le faire sous peu.
+ L'infrastructure de gestion de configuration logicielle est
+ développée en détail dans <xref linkend="vc" /><phrase
+ output="printed"> du <xref
linkend="technical-infrastructure" /></phrase>.</para>
<para>Il en va de même de la gestion de tickets. Son importance ne
@@ -651,7 +652,7 @@
indicateurs les plus forts du sérieux d'un projet. D'ailleurs, la
qualité apparente d'un projet est directement proportionnelle au
nombre de tickets saisis. Ceci peut semble contradictoire mais
- gardez à l'esprit que le nombre de bogues dépend de trois choses:
+ gardez à l'esprit que le nombre de bogues dépend de trois choses :
le nombre absolu de bogues inclus dans le logiciel, le nombre
d'utilisateurs du logiciel, et la facilité avec laquelle les
utilisateurs peuvent reporter leurs incidents. Sur ces trois
@@ -669,16 +670,15 @@
bogues, et il n'y a pas à s'en inquiéter. Si la page de statut met
l'accent sur la jeunesse du projet et que les gens observant la
base de bogues constatent que la plupart des incidents sont
- récents, ils pourront extrapoler le fait que le projet possède un
- bon niveau d'enregistrement de tickets et ne seront pas
- excessivement alarmés par le faible nombre absolu de tickets
- enregistrés.</para>
+ récents, ils pourront en conclure que le projet possède un bon
+ niveau d'enregistrement de tickets et ne seront pas excessivement
+ alarmés par le faible nombre absolu de tickets enregistrés.</para>
<para>Notez que les outils de gestion de ticket ne sont pas
seulement utilisés pour suivre les incidents mais également les
demandes de fonctionnalités, les évolutions de la documentation et
- bien d'autres choses. Nous ne détaillons pas plus en avant la
- gestion de ticket car ce point est développée dans <xref
+ bien d'autres choses encore. Nous ne détaillons pas davantage la
+ gestion de ticket car ce point est développé dans <xref
linkend="bug-tracker" /><phrase output="printed"> du <xref
linkend="technical-infrastructure" /></phrase>. Du point de vue de
la présentation du projet, l'important est de posséder un outil de
@@ -792,7 +792,7 @@
<para>La documentation est essentielle. Il doit exister
<emphasis>quelque chose</emphasis> même si c'est rudimentaire et
- incomplet. Encore une tâche à classer dans la catégorie
+ incomplet. C'est encore une tâche à classer dans la catégorie
"déplaisant" déjà évoquée plus tôt et qui est souvent le premier
écueil pour les projets libres. Définir des finalités et une liste
de fonctionnalités, choisir une licence, synthétiser un statut
@@ -818,11 +818,11 @@
Quelqu'un doit simplement s'asseoir et démarrer quelque chose,
puis de le faire lire par des utilisateurs lambda pour tester sa
qualité. Utilisez un format simple, facile à éditer comme le HTML,
- le texte brute, Textinfo ou des variantes de XML : quelque chose
- de léger et permettant des mises à jours rapides et au fil de
- l'eau. Ce critère ne concerne pas seulement la productivité de
- l'auteur original mais également à long terme de ceux qui
- joindront le projet plus tard et qui désireront maintenir cette
+ le texte brut, Textinfo ou des variantes de XML : quelque chose de
+ léger et permettant des mises à jours rapides et au fil de l'eau.
+ Ce critère ne concerne pas seulement la productivité de l'auteur
+ original mais également à long terme de ceux qui joindront le
+ projet plus tard et qui désireront maintenir cette
documentation.</para>
<para>Une façon simple de s'assurer que la documentation initiale
@@ -854,13 +854,13 @@
<listitem>
<para>Donner un style tutoriel à la description des tâches
courantes. Bien entendu, plusieurs exemples pour plusieurs
- taches serait préférable, mais le temps est limité.
- Sélectionnez une tache et décrivez là de façon exhaustive. Une
- fois que quelque le logiciel peut être utilisé pour une tâche,
- les utilisateurs commenceront à explorer les autres de façon
- autonome, et - si vous êtes chanceux - commenceront à
- alimenter la documentation par eux-même. Ce qui nous conduit
- au point suivant...</para>
+ taches serait préférable, mais votre temps est probablement
+ limité. Sélectionnez une tache et décrivez là de façon
+ exhaustive. Une fois que quelque le logiciel peut être utilisé
+ pour une tâche, les utilisateurs commenceront à explorer les
+ autres de façon autonome, et - si vous êtes chanceux -
+ commenceront à alimenter la documentation par eux-même. Ce qui
+ nous conduit au point suivant...</para>
</listitem>
<listitem>
@@ -898,7 +898,7 @@
domaine de la documentation. Les FAQs reflètent les questions
que les utilisateurs et développeurs se posent réellement - à
l'opposé des questions que vous pouvez
- <emphasis>supposer</emphasis> qu'il se posent - et ainsi, une
+ <emphasis>supposer</emphasis> qu'ils se posent - et ainsi, une
FAQ correctement gérée tend à fournir à ceux qui la consulte
l'information exacte qu'ils recherchent. Une FAQ est en général
le premier endroit consulté en cas de problème, avant même le
@@ -907,11 +907,11 @@
<para>Malheureusement, il est impossible de produire une FAQ au
début d'un projet. Les bonnes FAQ ne s'écrivent pas, elles
- grandissent. Elles sont par définition des documents réactifs,
- évoluant en réponse à l'usage au jour le jour du logiciel. Comme
- il est impossible d'anticiper correctement les questions des
- utilisateurs, il est également impossible de s'assoir et
- d'écrire une FAQ de zéro.</para>
+ croissent naturellement. Elles sont par définition des documents
+ réactifs, évoluant en réponse à l'usage au jour le jour du
+ logiciel. Comme il est impossible d'anticiper correctement les
+ questions des utilisateurs, il est également impossible de
+ s'assoir et d'écrire une FAQ de zéro.</para>
<para>Pour cette raison, ne gaspillez pas votre temps à tenter
de le faire. Vous pouvez néanmoins trouver utile de mettre en
@@ -1007,7 +1007,7 @@
documentation initiale, voire leur documentation principale.
Selon mon expérience, ceci ne fonctionne vraiment que si le wiki
est activement édité par un groupe restreint de personnes qui
- s'accorde sur la façon d'organiser la documentation et sur un
+ s'accordent sur la façon d'organiser la documentation et sur un
sorte de "ton" qu'elle doit avoir. Voir <xref
linkend="wikis" /><phrase output="printed"> du <xref
linkend="technical-infrastructure" /></phrase> pour plus
@@ -1065,7 +1065,7 @@
<para>Certains sites proposent un hébergement gratuit et une
infrastructure pour les projets libres : une zone Web, un outil de
gestion de configuration logiciel, un outil de gestion de ticket,
- une zone de téléchargement, des forums de discussion, des
+ des référentiels de téléchargement, des forums de discussion, des
sauvegardes automatiques, etc. Les détails varient d'un site à
l'autre, mais les mêmes services de base sont offerts par tous. En
utilisant l'un de ces sites, vous obtiendrez beaucoup
@@ -1087,18 +1087,18 @@
<sect1 id="license-quickstart">
<title>Choisir une licence et la mettre en oeuvre</title>
- <para>Ce paragraphe est un guide très court et très basique sur le
- choix d'une licence. Consultez <xref linkend="legal" /> pour saisir
- les implications légales des différentes licences, et l'impact
- qu'une licence peut avoir pour fusionner votre logiciel avec du code
- issue d'autres projets.</para>
+ <para>Ce paragraphe est un guide très court et basique sur le choix
+ d'une licence. Consultez <xref linkend="legal" /> pour saisir les
+ implications légales des différentes licences et l'impact qu'une
+ licence peut avoir pour fusionner votre logiciel avec du code issue
+ d'autres projets.</para>
<para>Il existe de nombreuses licences pouvant être choisies. La
- plupart, que nous omettrons, ne seraient probablement pas appropriée
- à votre projet, étant des besoins spécifiques de sociétés ou
- individus. Nous nous restreindrons simplement aux licences les plus
- courantes; étant fort probable qu'une d'entre elle vous
- conviendra.</para>
+ plupart, que nous omettrons, ne seraient probablement pas
+ appropriées à votre projet, couvrant des besoins spécifiques de
+ sociétés ou individus . Nous nous restreindrons simplement aux
+ licences les plus courantes, étant fort probable que l'une d'entre
+ elle vous conviendra.</para>
<!-- ======================== subsection ============================== -->
@@ -1187,8 +1187,8 @@
permanente, ce qui peut être n'importe où sur votre site Web. En
général, la notice que vous utilisez n'aura pas exactement le
contenu de l'exemple plus haut. L'important est d'y faire figurer
- les données obligatoires: détenteur du copyright, date, nom de la
- licence et moyen d'accès au texte de cette licence.</para>
+ les données obligatoires : détenteur du copyright, date, nom de la
+ licence et moyen d'accès au texte de la licence.</para>
</sect2>
</sect1>
@@ -1197,11 +1197,11 @@
<sect1 id="setting-tone">
<title>Donner le LA</title>
- <para>Jusque là, nous avons décrit des tâches réalisées à un moment
+ <para>Jusqu'ici, nous avons décrit des tâches réalisées à un moment
précis de la mise en place du projet : choisir une licence,
concevoir le site Web initial, etc. Mais les aspects les plus
importants dans le démarrage d'un projet sont dynamiques. Choisir
- une adresse de liste de diffusion est facile; s'assurer que les
+ une adresse de liste de diffusion est facile ; s'assurer que les
conversations sur cette liste ne dérivent pas et restent productives
est une problématique complètement différente. Si le projet est
ouvert au monde après des années de développement propriétaire
@@ -1209,8 +1209,8 @@
préparer les développeurs actuels à ce changement.</para>
<para>Les premiers pas sont les plus difficiles, car le projet
- manque de décisions et de reflexes. La stabilité d'un projet ne
- vient pas seulement de régles formalisées, mais d'une atmosphère
+ manque de décisions prises et de reflexes. La stabilité d'un projet
+ ne vient pas seulement de régles formalisées, mais d'une atmosphère
collective difficile à saisir et qui se développe au cours du temps.
On trouve souvent des régles écrites, mais elles se bornent souvent
à une distillation de régles tacites, évoluant régulièrement et
@@ -1244,8 +1244,8 @@
commune, les gens recherchent instinctivement des comportements qui
leur permettrait de se voir identifiés comme membre du groupe. Le
but des guides est d'amorcer des comportements de groupe utiles au
- projet. Une fois mis en place, ils se perpétrerons tous seuls le
- plus souvent.</para>
+ projet. Une fois mis en place, ils se perpétuerons seuls le plus
+ souvent.</para>
<!-- todo: maybe say this:
@@ -1286,19 +1286,19 @@
importantes à prendre et, en général, si peu de volontaires
qualifiés pour les prendre. Tous les inconvénients évidents des
listes de discussion publiques vont alors apparaître de façon très
- palpable : le délai inhérent aux conversations par e-mail, le
+ palpable : le délai inhérent aux conversations par courriel, le
besoin de réserver suffisamment de temps pour qu'un consensus se
forme, l'embarras à devoir répondre aux volontaires naïfs qui
pense comprendre tous les problèmes mais qui ne les comprennent
pas (tous les projets ont ce genre de personnes ; quelques fois
elles sont les contributeurs stars de l'année d'après, quelque
- fois ils restent toujours naïfs ); ceux qui ne comprennent pas que
- vous désirez seulement résoudre le problème X alors qu'il leur
- semble évident que ce problème est un sous-ensemble d'un problème
- Y, et ainsi de suite. La tentation de prendre des décisions toutes
+ fois ils restent naïfs ); ceux qui ne comprennent pas que vous
+ désirez seulement résoudre le problème X alors qu'il leur semble
+ évident que ce problème est un sous-ensemble d'un problème Y, et
+ ainsi de suite. La tentation de prendre des décisions toutes
portes fermées et de les présenter comme faits accomplis, ou au
- moins comme de fermes recommandations d'un groupe de votants unis
- et influents, est en effet très grande.</para>
+ moins comme de fermes recommandations d'un groupe de votants uni
+ et influent, est en effet très grande.</para>
<para>Ne le faites pas.</para>
@@ -1315,7 +1315,7 @@
<itemizedlist>
<listitem>
<para>La discussion aide à former les nouveaux développeurs.
- Vous ne savez jamais combien de yeux suivent la conversation
+ Vous ne savez jamais combien d'yeux suivent la conversation
; même si la plupart des gens n'y participent pas, beaucoup
peuvent la suivre silencieusement, glanant des informations
sur le logiciel.</para>
@@ -1350,18 +1350,16 @@
plus probable qu'on peut le penser intuitivement. Sur le projet
Subversion, nous (les fondateurs) étions en face de ce que nous
croyions être un ensemble de problèmes complexes et profonds, sur
- lesquels nous avions réfléchis dur depuis des mois, et nous
+ lesquels nous avions réfléchi dur depuis des mois, et nous
doutions franchement que quelqu'un sur la nouvelle liste de
diffusion puisse apporter une contribution utile à la discussion.
Alors, nous avons emprunté la voie de la facilité et nous avons
- commencé à batailler sur des idées techniques via des e-mails
- privés, jusqu'à ce qu'un observateur du projet</para>
-
- <para><footnote>
+ commencé à batailler sur des idées techniques via des courriels
+ privés, jusqu'à ce qu'un observateur du projet <footnote>
<para>Nous n'avons pas encore abordé le sujet des crédits,
- mais simplement pour mettre en oeuvre ce que je prêche plus
- tard : le nom de l'observateur était Brian Behlendorf, et ce
- fut lui qui pointa l'importance général de conserver toutes
+ mais simplement pour appliquer à moi-même ce que je prêche
+ plus tard : le nom de l'observateur était Brian Behlendorf, et
+ ce fut lui qui pointa l'importance général de conserver toutes
les discussions publiques à moins qu'il y ait un besoin
explicite de confidentialité.</para>
</footnote> présenti ce qui ce passait et demanda que la
@@ -1370,9 +1368,9 @@
de commentaires pertinents et par les suggestions qui en ont
résultées. Dans de nombreux cas, les gens apportèrent des idées
qui ne nous étaient jamais venues à l'esprit. Il apparut qu'il y
- avait des gens <emphasis>très</emphasis> pointus sur cette liste;
+ avait des gens <emphasis>très</emphasis> pointus sur cette liste ;
ils étaient simplement à attendre le bon appât. Il est vrai que
- les discussions qui ont suivi prirent plus de temps que si la
+ les discussions qui ont suivies prirent plus de temps que si la
conversation était restée privée, mais elles furent tellement plus
productives que cela justifiait largement cette rallonge.</para>
@@ -1380,9 +1378,9 @@
toujours meilleur que l'individu" (nous avons tous rencontré
suffisamment de groupes pour le savoir), nous pouvons mettre
l'accent sur le fait que les groupes excellent vraiment dans
- certaines activités. La revue par pair massive est l'un d'eux ;
- générer un grand nombre d'idées en est un autre. La qualité des
- idées dépend de la qualité intellectuelle des contributeurs, bien
+ certaines activités. La revue par pair massive est une ; générer
+ un grand nombre d'idées en est une autre. La qualité des idées
+ dépend de la qualité intellectuelle des contributeurs, bien
entendu, mais vous ne connaissez pas le type de penseurs auquel
vous vous adressez avant de les avoir stimulés avec un problème
coriace.</para>
@@ -1419,7 +1417,7 @@
quand il attaque un autre contributeur, ou de lui enlever le droit
de commit parce qu'il a tenu des propos déplacés (en théorie, vous
pouvez éventuellement en arriver là, mais seulement après que tous
- les autres moyens aient échoués - ce qui n'est pas le cas, par
+ les autres moyens aient échoués -ce qui n'est pas le cas, par
définition, lorsque le projet démarre). La tolérance zéro signifie
simplement qu'aucun mauvais comportement ne demeurera sans
réponse. Par exemple, si quelqu'un envoi un message mélangeant un
@@ -1431,7 +1429,7 @@
<para>Il est malheureusement très facile, et régulier, que les
discussions constructives dérivent en de véritables pugilats. Les
- gens ont tendance à dire par e-mail ce qu'il ne diraient jamais en
+ gens ont tendance à dire par courriel ce qu'il ne diraient jamais
face à face. Le sujet de discussion amplifie seulement cet effet :
dans un débat technique, les gens pensent souvent qu'il n'y a
qu'une bonne réponse à une question donnée, et que tout désaccord
@@ -1439,10 +1437,10 @@
la stupidité de celui qui l'exprime. Il n'y a qu'un pas entre
qualifier de stupide la proposition technique de quelqu'un et le
qualifier de stupide lui-même. Il est en fait souvent difficile de
- dire ou fini le débat et ou commence l'attaque personnelle; c'est
- la raison pour laquelle les réponses drastiques ou les punitions
- ne sont pas une bonne idée. Lorsque vous pensez que le débat
- s'envenime, envoyez plutôt un message mettant l'accent sur
+ déterminer ou fini le débat et ou commence l'attaque personnelle ;
+ c'est la raison pour laquelle les réponses drastiques ou les
+ punitions ne sont pas une bonne idée. Lorsque vous pensez que le
+ débat s'envenime, envoyez plutôt un message mettant l'accent sur
l'importance de conserver la discussion amicale, sans accuser
quiconque d'être délibérément agressif. De tels messages de "bonne
conduite" ont néanmoins tendance à sonner comme une leçon de
@@ -1484,7 +1482,7 @@
pouvez soit ne pas répondre (si vous pensez qu'il s'agissait
simplement d'un accès d'humeur), soit dire que vous êtes désolé si
vous avez réagit trop vivement et qu'il est difficile de percevoir
- toutes les nuances dans un e-mail, puis revenez au sujet
+ toutes les nuances dans un courriel, puis revenez au sujet
principal. N'insistez <emphasis>jamais</emphasis> pour exiger des
excuses, que ce soit de façon publique ou privée, de quelqu'un qui
s'est mal comporté. C'est une bonne chose s'il décide de son
@@ -1514,14 +1512,14 @@
développement d'une communauté productive est de permettre aux
gens d'observer leur code les uns les autres. Un peu
d'infrastructure technique est requise pour y arriver, en
- particulier il faut activer l'envoi d'e-mails sur commit (voir
+ particulier il faut activer l'envoi de courriels sur commit (voir
<xref linkend="commit-emails" /> pour plus de détails). Le but est
- d'émettre un e-mail contenant le message de commit et les
- changements (diff) à chaque commit dans le code (voir <xref
+ d'émettre un courriel contenant les annotations et les changements
+ (diff) de chaque commit de code (voir <xref
linkend="vc-vocabulary-diff" /> du <xref
linkend="vc-vocabulary" />). <firstterm>La revue de
code</firstterm> est la pratique consistant à consulter ces
- e-mails au fil de l'eau en y recherchant des bogues ou de
+ courriels au fil de l'eau en y recherchant des bogues ou de
possibles améliorations.<footnote>
<para>C'est en général de cette façon qu'est réalisée la revue
de code dans les projets libres. Dans des projets plus
@@ -1535,7 +1533,7 @@
Il s'agit de l'exemple le plus évident de revue par pairs dans le
monde du libre, et elle aide à assurer un bon niveau de qualité au
logiciel. Chaque bogue incorporé dans la version finale l'a été
- parce qu'il n'a pas été détecté à temps; ainsi, plus d'yeux
+ parce qu'il n'a pas été détecté à temps ; ainsi, plus d'yeux
observent les commits, plus le nombre de bogues sera limité. Mais
ce processus sert aussi un autre but plus indirect : il conforte
les gens dans l'idée que ce qu'ils font a de l'importance,
@@ -1563,7 +1561,7 @@
connaissait la valeur de la revue par pair d'un ancien travail,
décida qu'il allait montrer l'exemple en faisant la revue de
<emphasis>chaque commit</emphasis> arrivant dans le référentiel.
- Chaque modification était rapidement suivie d'un e-mail de Greg
+ Chaque modification était rapidement suivie d'un courriel de Greg
envoyé à la liste développeur dans lequel il disséquait le commit,
analysait les problèmes potentiels, et proposait quelque fois un
peu de code bien tourné. Instantanément, il attrapa des bogues et
@@ -1571,7 +1569,7 @@
glissées sans que personne ne s'en rende compte. Il est à noter
qu'il ne s'est jamais plaint d'être le seul à faire ces revues,
même s'il y consacrait une quantité de temps importante. Il en
- chantait simplement les louanges, dès qu'il le pouvait. Assez
+ chantait simplement les louanges dès qu'il le pouvait. Assez
rapidement, d'autres personnes, moi compris, commencèrent à
l'imiter. Quelle était notre motivation ? Non pas que Greg avait
jeté l'opprobre sur nous, mais il avait prouvé que la revue de
@@ -1603,8 +1601,8 @@
<para>Ne vous inquiétez pas si vous ne trouver rien à commenter,
ou si vous de maîtrisez pas assez toutes les parties du code. Il y
- aura souvent quelque chose à dire sur tout commit; même si vous ne
- trouvez rien à redire, quelque chose peut faire l'objet d'un
+ aura souvent quelque chose à dire sur tout commit ; même si vous
+ ne trouvez rien à redire, quelque chose peut faire l'objet d'un
commentaire admiratif. L'important est de rendre clair le fait que
chaque développeur sache que ce qu'il fait est vu et compris. Bien
entendu, la revue du code n'absout pas les programmeurs de leur
@@ -1630,12 +1628,12 @@
tout le code et les décisions sur la conception sont faites par un
groupe de développeurs qui connaissent tous plus ou moins autant
le logiciel, qui reçoivent la même pression du même management, et
- qui connaissent leurs forces et faiblesses respectives.
- Soudainement, vous leur demandez d'exposer leur code pour qu'il
- soit scruté par des étrangers ne formant leur jugement que sur le
- code final, et sans prendre en compte la pression de la hiérarchie
- qui a pu forcer certaines décisions. Ces étrangers posent de
- nombreuses questions, des questions qui secouent des développeurs
+ qui connaissent leurs forces et faiblesses respectives. Vous leur
+ demandez soudain d'exposer leur code pour qu'il soit scruté par
+ des étrangers ne formant leur jugement que sur le résultat final,
+ et sans prendre en compte la pression de la hiérarchie qui a pu
+ forcer certaines décisions. Ces étrangers posent de nombreuses
+ questions, des questions qui déstabilisent les développeurs
lorsqu'ils réalisent que la documentation sur laquelle il avait
tant travaillé est <emphasis>toujours</emphasis> inadéquate (c'est
inévitable). Ajoutez le fait que tous ces arrivants sont inconnus
@@ -1645,7 +1643,7 @@
code, et pire, devant ses collègues. A moins de disposer d'une
équipe de développeurs parfaits, c'est inévitable, en fait cela se
produira probablement pour tous. Non pas qu'ils soient de mauvais
- programmeurs; c'est simplement qu'au dessus d'une certaine taille,
+ programmeurs, c'est simplement qu'au dessus d'une certaine taille
un projet a des bogues et la revue par pairs permettra de les
détecter (voir <xref linkend="code-review" /><phrase
output="printed"> précédemment dans ce chapitre</phrase>). Dans le
@@ -1653,35 +1651,34 @@
à la revue par pairs puisqu'ils ne peuvent produire de code tant
qu'ils ne sont pas suffisamment familiers du projet. Pour vos
développeurs, cela peut être pris comme une situation de critique
- dans un seul sens. Il y a donc danger de voir apparaître une
- mentalité d'assiégés parmis les vétérans.</para>
+ unilatérale. Il y a donc danger de voir apparaître une mentalité
+ d'assiégés parmis les vétérans.</para>
<para>La meilleure façon de l'éviter est de prévenir le groupe de
- ce qui va arriver. Expliquer leur que l'inconfort initial est
- parfaitement normal, et rassurez les en leur assurant que les
- choses iront en s'améliorant. Certains de ces messages peuvent
- rester privés, avant que le projet ne soit ouvert. Mais vous
- pouvez également trouver utile d'informer sur la liste publique
- qu'une nouvelle méthode de développement pour le projet se met en
- place, et qu'un temps d'adaptation sera nécessaire. La meilleur
- chose que vous puissiez faire est de manager par l'exemple. Si
- vous constatez que vos développeurs ne répondent pas suffisamment
- aux questions des débutants, leur demander simplement d'y répondre
- plus ne fera pas avancer les choses. Ils peuvent manquer de
- discernement entre ce qui nécessite une réponse ou pas, ou ne pas
- savoir comment prioriser le travail de développement face à la
- nouvelle charge amenée par cette communication externe. Le moyen
- de les faire participer est de participer vous mêmes. Soyez sur la
- mailing liste publique, et répondez y à des questions. Si vous
- n'avez pas l'expertise pour répondre à une question, désignez
- clairement un développeur qui la possède, et vérifiez qu'il
- fournira une solution ou au moins une réponse. Il peut être
- naturellement tentant sur le long terme de glisser vers des
- discussion privées, ce qui constituait après tout la situation
- antérieure. Assurez vous de vous inscrire sur les mailing listes
- internes sur lesquelles cela peut se produire pour être en mesure
- de demander à déplacer ces discussions vers la mailing liste
- publique.</para>
+ ce qui va arriver. Expliquer lui que l'inconfort initial est
+ parfaitement normal, et rassurez en assurant que les choses iront
+ en s'améliorant. Certains de ces messages peuvent rester privés,
+ avant que le projet ne soit ouvert. Mais vous pouvez également
+ trouver utile d'informer sur la liste publique qu'une nouvelle
+ méthode de développement pour le projet se met en place, et qu'un
+ temps d'adaptation sera nécessaire. La meilleur chose que vous
+ puissiez faire est de piloter par l'exemple. Si vous constatez que
+ vos développeurs ne répondent pas suffisamment aux questions des
+ débutants, leur demander simplement d'y répondre plus ne fera pas
+ avancer les choses. Ils peuvent manquer de discernement entre ce
+ qui nécessite une réponse ou pas, ou ne pas savoir comment
+ prioriser le travail de développement face à la nouvelle charge
+ amenée par cette communication externe. Le moyen de les faire
+ participer est de participer vous mêmes. Soyez sur la mailing
+ liste publique, et répondez y à des questions. Si vous n'avez pas
+ l'expertise pour répondre à une question, désignez clairement un
+ développeur qui la possède, et vérifiez qu'il fournira une
+ solution ou au moins une réponse. Il peut être naturellement
+ tentant sur le long terme de glisser vers des discussion privées,
+ ce qui constituait après tout la situation antérieure. Assurez
+ vous de vous inscrire sur les mailing listes internes sur
+ lesquelles cela peut se produire pour être en mesure de demander à
+ déplacer ces discussions vers la mailing liste publique.</para>
<para>Il existe d'autres considérations de long terme à prendre en
compte lorsqu'on ouvre un projet propriétaire. <xref
@@ -1722,9 +1719,9 @@
Subject: [ANN] Projet Scanley d'indexeur textuel
Reply-to: [EMAIL PROTECTED]
-Ceci est un message unique n'annonce de création du projet Scanley,
+Ceci est un message unique d'annonce de création du projet Scanley,
un indexeur textuel libre et un moteur de recherche doté d'une
-riche API, à destination des programmeurs désirant proposer des
+riche API à destination des programmeurs désirant proposer des
services de recherche pour de grandes collections de fichiers texte.
Scanley fonctionne, est toujours en développement actif, et
recherche des développeurs et des testeurs.
@@ -1735,13 +1732,13 @@
- Recherches texte, HTML et XML
- Recherche de mots ou de phrases entières
- (prévu) Recherches approchantes
- - (prévu) Mise à jour incrémentales des indexes
+ - (prévu) Mise à jour incrémentales des index
- (prévu) Indexation de sites Web distants
Pré-requis :
- Python 2.2 ou supérieur
- - Suffisamment d'espace disque pour les indexes (approximativement 2 x
-la taille des données indexées)
+ - Suffisamment d'espace disque pour les index (approximativement 2 x
+la taille des données traitées)
Pour davantage d'informations, veillez consulter scanley.org.
@@ -1759,7 +1756,7 @@
un projet peut bénéficier du fait d'être encore en conception. J'ai
longtemps pensé que démarrer avec un code fonctionnel était le plus
important facteur de réussite d'un projet, étant ce qui différencie
- les vrais projets des jouets, et que des développeurs sérieux ne
+ les vrais projets des gadgets, et que des développeurs sérieux ne
seraient attirés que car quelque chose de suffisamment
concret.</para>
@@ -1796,13 +1793,13 @@
l'annonce est seulement planter la graine : il peut falloir un temps
considérable pour que la nouvelle croissent et se répande. Si le
projet donne constamment en retour à ceux qui s'y investissent, la
- nouvelle se répandra néanmoins, car les gens aiment partager
- lorsqu'ils trouvent quelque chose de valable. Si les choses se
- passent bien, les dynamiques de réseau de type exponentielles
- transformeront lentement le projet en une communauté complexe, où
- vous ne connaîtrez pas nécessairement le nom de tous et où vous ne
- pourrez plus suivre chaque conversation. Le chapitre suivant
- concerne la façon de travailler dans cet environnement.</para>
+ nouvelle se répandra car les gens aiment partager lorsqu'ils
+ trouvent quelque chose de valable. Si les choses se passent bien,
+ les dynamiques de réseau de type exponentielles transformeront
+ lentement le projet en une communauté complexe, où vous ne
+ connaîtrez pas nécessairement le nom de tous et où vous ne pourrez
+ plus suivre chaque conversation. Le chapitre suivant concerne la
+ façon de travailler dans cet environnement.</para>
</sect1>
</chapter>
<!--
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
