Author: alejandroayuso
Date: Tue Jul 31 19:44:26 2007
New Revision: 867
Log:
more of ch03... 80%
Modified:
trunk/es/ch03.xml
Modified: trunk/es/ch03.xml
==============================================================================
--- trunk/es/ch03.xml (original)
+++ trunk/es/ch03.xml Tue Jul 31 19:44:26 2007
@@ -574,6 +574,7 @@
<para>Otras son opcionales, aunque de cierta manera estándar. Por ejemplo,
no es estrictamente requerido que un correo electrónico tenga la cabecera
+</para>
<screen>
Reply-to: [EMAIL PROTECTED]
@@ -701,6 +702,7 @@
remitente en este campo (o si ni siquiera lo establecen) para
cuando los suscriptores a la lista vean el mensaje, éste contendra
la dirección de la lista en la cabecera:
+</para>
<screen>
Reply-to: [EMAIL PROTECTED]
@@ -948,6 +950,7 @@
finas, porque permiten a quien busca, específicar que los
resultados sean mostrados, por ejemplo, según el asunto y no
según el cuerpo del mensaje.
+ </para>
</listitem>
</varlistentry>
@@ -1056,7 +1059,7 @@
seriamente si no se utiliza este sistema con un mínimo de competencia.</para>
<para>La razón por la cual el control de versiones es universal es porque
-ayuda virtualmente en todos los aspectos de dirigir un proyecto: comunicación
+ayuda virtualmente en todos los aspectos al dirigir un proyecto: comunicación
entre los desarrolladores, manejo de los lanzamientos, administración de
fallos,
estabilidad entre el código y los esfuerzos de desarrollo experimental y
atribución y autorización en los cambios de los desarrolladores. El sistema
@@ -1085,7 +1088,7 @@
la colaboración en red y serán utilizados a lo largo del libro. Incluso
si no existiera ningún sistema de control de versiones, el problema del
control de los cambios aun existiria y estas palabras nos dan un lenguaje
-para hablar acerca de este problema consistentemente.</para>
+para hablar acerca de este problema consistentemente.
<variablelist>
@@ -1100,7 +1103,7 @@
sinonimo de "cambio". Por ejemplo: "He commited una reparación
para un fallo reportado en Mac OS X que hacia que el servidor
se colgara. Jóse ¿podrias por favor revisarlo y verificar que
- no estoy utilizando mal el ALLOCATOR?"
+ no estoy haciendo mal la asignación?"
</para></listitem>
</varlistentry>
@@ -1200,89 +1203,78 @@
o conjunto de cambios (changeset) para referirse a un conjunto
de cambios enviados juntos como una únidad conceptual.</para>
-<para>Estos conceptos pueden tener distintos significados tecnicos
-en cada sistema de control de versiones, pero en general, la ídea es
-siempre la misma: dar un sistema para comunicar de manera precisa la
-historia de cambios en un fichero o conjunto de ficheros (inmediatamente
-antes y despues de que se ha corregido un fallo). Por ejemplo: "Eso
-se ha resuelto en la revisión 10" o "Se ha corregido eso en la revisión
-10 del fichero foo.c."</para>
-
-<para>Cuando se habla sobre ficheros o una colección de ficheros sin
-específicar una revisión en particular, por lo general se asume que
-nos referimos a la revisión disponible más reciente.</para></listitem>
+ <para>Estos conceptos pueden tener distintos significados tecnicos
+ en cada sistema de control de versiones, pero en general, la ídea es
+ siempre la misma: dar un sistema para comunicar de manera precisa la
+ historia de cambios en un fichero o conjunto de ficheros (inmediatamente
+ antes y despues de que se ha corregido un fallo). Por ejemplo: "Eso
+ se ha resuelto en la revisión 10" o "Se ha corregido eso en la revisión
+ 10 del fichero foo.c."</para>
+
+ <para>Cuando se habla sobre ficheros o una colección de ficheros sin
+ específicar una revisión en particular, por lo general se asume que
+ nos referimos a la revisión disponible más reciente.</para></listitem>
</varlistentry>
<sidebar id="version-vs-revision">
<title>"Versión" Versus "Revisión"</title>
-<para>El termino <firstterm>versión</firstterm> es a veces utilizado
-como un sinonimo para "revisión", pero aquí no voy a utilizarla de esta
-forma, ya que se puede confundir facilmente con "versión" en el sentido
-de una versión de un programa—así que, el número de lanzamiento
-o edición como en "Versión 1.0". Y aunque la frase "control de versiones"
-es un estándar, continuare utilizandolo como sinonimo para "control
-de revisiones" y para "control de cambios".</para>
+ <para>El termino <firstterm>versión</firstterm> es a veces utilizado
+ como un sinonimo para "revisión", pero aquí no voy a utilizarla de esta
+ forma, ya que se puede confundir facilmente con "versión" en el sentido
+ de una versión de un programa—así que, el número de lanzamiento
+ o edición como en "Versión 1.0". Y aunque la frase "control de
versiones"
+ es un estándar, continuare utilizandolo como sinonimo para "control
+ de revisiones" y para "control de cambios".</para>
</sidebar>
<varlistentry id="vc-vocabulary-diff">
<term><firstterm>diff</firstterm></term>
<listitem><para>
-Una representación contextual de un cambio. Un diff muestra las lineas
-que han sido modíficadas, como y además, algunas lineas contextuales
-rodeandolas a cada lado. Un desarrollador familiarizado con el código
-puede, con leer un diff de ese código, entender lo que hace el cambio
-e incluso detectar fallos.</para></listitem>
+ Una representación contextual de un cambio. Un diff muestra las lineas
+ que han sido modíficadas, como y además, algunas lineas contextuales
+ rodeandolas a cada lado. Un desarrollador familiarizado con el código
+ puede, con leer un diff de ese código, entender lo que hace el cambio
+ e incluso detectar fallos.</para></listitem>
</varlistentry>
<varlistentry id="vc-vocabulary-tag">
<term><firstterm>etiqueta (tag)</firstterm></term>
<listitem><para>
-Una etiqueta para una colección particular de ficheros en una revisión
-especfífica. Los tags son utilizados para preservar capturas interesantes
-del proyecto. Por ejemplo, un tag es hecho para cada lanzamiento público,
-de forma que cada persona pueda obtener, directamente desde el sistema
-de control de versiones, el conjunto exacto de ficheros/revisiones
-que componen el lanzamiento. Algunos tags comunes son como
-<literal>Release_1_0</literal>, <literal>Delivery_00456</literal>,
-etc.</para></listitem>
+ Una etiqueta para una colección particular de ficheros en una revisión
+ especfífica. Los tags son utilizados para preservar capturas
interesantes
+ del proyecto. Por ejemplo, un tag es hecho para cada lanzamiento
público,
+ de forma que cada persona pueda obtener, directamente desde el sistema
+ de control de versiones, el conjunto exacto de ficheros/revisiones
+ que componen el lanzamiento. Algunos tags comunes son como
+ <literal>Release_1_0</literal>, <literal>Delivery_00456</literal>,
+ etc.</para></listitem>
</varlistentry>
<varlistentry id="vc-vocabulary-branch">
<term><firstterm>rama (branch)</firstterm></term>
<listitem><para>
-Es una copia del proyecto, bajo el control de versiones, pero aislado,
-de forma que los cambios realizados en esta rama no afecten al resto
-del proyecto y vice versa, excepto cuando los cambios sean
-deliberadamente "unidos" de un lado al otro. Las ramas tambien son
-conocidas como "lineas de desarrollo". Incluso cuando un proyeto
-no tiene ramas específicas se considera que el desarrollo se esta
-produciendo en la rama principal, tambien conocida como "línea
-primaria" o "<firstterm>trunk</firstterm>".</para>
-
- <para>Branches offer a way to isolate different lines of development
- from each other. For example, a branch can be used for experimental
- development that would be too destabilizing for the main trunk. Or
- conversely, a branch can be used as a place to stabilize a new
- release. During the release process, regular development would
- continue uninterrupted in the main branch of the repository;
- meanwhile, on the release branch, no changes are allowed except
- those approved by the release managers. This way, making a release
- needn't interfere with ongoing development work. See <xref
- linkend="branches"/><phrase output="printed"> later in this
-
-<para>Las ramas o branches, permiten aislar diferentes lineas de
-desarrollo de si mismas. Por ejemplo, una rama puede ser utilizada
-para un desarrollo experimental que sería demasiado inestable para
-la rama principal. O al contrario, una rama puede ser utilizada
-como sitio para estabilizar una versión para lanzamiento. Durante
-el proceso de lanzamiento, el desarrollo regular se mantendria ininterrumpida
-en la rama principal. Mientras tanto, en la rama de lanzamiento,
-ningún cambio es aceptado excepto aquellos aprobados por el
-responsable del lanzamiento. De esta manera, realizar un lanzamiento
-no tiene porque interferir con el trabajo de desarrollo que se está
-realizando. Para más información <xref linkend="branches"/><phrase
output="printed">
-más adelante en el capítulo</phrase> para una discusión más
-detallada sobre las ramas.</para></listitem>
+ Es una copia del proyecto, bajo el control de versiones, pero aislado,
+ de forma que los cambios realizados en esta rama no afecten al resto
+ del proyecto y vice versa, excepto cuando los cambios sean
+ deliberadamente "unidos" de un lado al otro. Las ramas tambien son
+ conocidas como "lineas de desarrollo". Incluso cuando un proyeto
+ no tiene ramas específicas se considera que el desarrollo se esta
+ produciendo en la rama principal, tambien conocida como "línea
+ primaria" o "<firstterm>trunk</firstterm>".</para>
+
+ <para>Las ramas o branches, permiten aislar diferentes lineas de
+ desarrollo de si mismas. Por ejemplo, una rama puede ser utilizada
+ para un desarrollo experimental que sería demasiado inestable para
+ la rama principal. O al contrario, una rama puede ser utilizada
+ como sitio para estabilizar una versión para lanzamiento. Durante
+ el proceso de lanzamiento, el desarrollo regular se mantendria
ininterrumpida
+ en la rama principal. Mientras tanto, en la rama de lanzamiento,
+ ningún cambio es aceptado excepto aquellos aprobados por el
+ responsable del lanzamiento. De esta manera, realizar un lanzamiento
+ no tiene porque interferir con el trabajo de desarrollo que se está
+ realizando. Para más información <xref linkend="branches"/><phrase
output="printed">
+ más adelante en el capítulo</phrase> para una discusión más
+ detallada sobre las ramas.</para></listitem>
</varlistentry>
<varlistentry id="vc-vocabulary-merge">
@@ -1295,15 +1287,15 @@
información sobre los merge <xref linkend="vc-singularity"/>.
</para>
-<para>"Merge" tiene otro significado: es lo que hace el sistema de control
-de versiones cuando se encuentra con que dos personas han realizado
-cambios en un mismo fichero sin relación alguna. Ya que estos cambios
-no interfieren entre ellos, cuando alguna de estas personas actualizan
-su copia del fichero (el cual ya contiene los cambios) los cambios
-de la otra persona serán unidos automaticamente. Esto sucede muy a
-menudo, especialmente en proyectos con multiples personas realizando
-cambios en el mismo código. Cuando dos cambios diferentes estan
-relacionados, el resultado es un "conflicto".</para>
+ <para>"Merge" tiene otro significado: es lo que hace el sistema de
control
+ de versiones cuando se encuentra con que dos personas han realizado
+ cambios en un mismo fichero sin relación alguna. Ya que estos cambios
+ no interfieren entre ellos, cuando alguna de estas personas actualizan
+ su copia del fichero (el cual ya contiene los cambios) los cambios
+ de la otra persona serán unidos automaticamente. Esto sucede muy a
+ menudo, especialmente en proyectos con multiples personas realizando
+ cambios en el mismo código. Cuando dos cambios diferentes estan
+ relacionados, el resultado es un "conflicto".</para>
</listitem>
</varlistentry>
@@ -1345,7 +1337,7 @@
de versiones discutidos en este libro soportan este modelo.
</para></listitem>
- </varlistentry>
+</varlistentry>
</variablelist>
@@ -1628,7 +1620,7 @@
real. Aunque es una utilidad menos técnica que los correos electrónicos,
ya que los observadores puede que esten o no conectados cuando las alertas
sobre nuevos cambios llegan al canal, esta técnica tiene una inmensa
-utiidad <emphasis>social</emphasis>. La gente tiene la sensación de
+utilidad <emphasis>social</emphasis>. La gente tiene la sensación de
pertenecer a algo vivo y activo, y siente que pueden ver el progreso
que se está haciendo ante sus propios ojos.</para>
@@ -1678,9 +1670,9 @@
el sistema de control de versiones mueva ("merge") el puente levadiso
de la rama del castillo a la rama principal del castillo.</para>
-<para>Es fácil ver como esta habilidad ayuda al desarollo colaborativo,
+<para>Es fácil ver como esta habilidad ayuda al desarrollo colaborativo,
ya que la gente necesita de cierta libertad para probar cosas nuevas
-sin sentirse que estan interfiriendo con el trabajo de otros. Igual
+sin sentir que estan interfiriendo con el trabajo de otros. Igual
de importante es cuando el código debe ser aislado del CHURN usual
de desarrollo de manera que un fallo sea reparado o un lanzamiento
sea estabilizado (más en <xref linkend="stabilizing-a-release"/> y
@@ -1859,16 +1851,14 @@
tenga una razón en específico. Usualmente esto no trae beneficios
tangibles y confiar en el control humano tiene sus ventajas.</para>
-<para>None of this should be taken to mean that the restrictions
-themselves are unimportant, of course. It would be bad for a project
-to encourage people to commit in areas where they're not qualified.
-Furthermore, in many projects, full (unrestricted) commit access has a
-special status: it implies voting rights on project-wide questions.
-This political aspect of commit access is discussed more in <xref
-linkend="electorate"/><phrase output="printed"> in
-<xref linkend="social-infrastructure"/></phrase>.</para>
-
-<para>Nada de debe ser tomado como
+<para>Por supuesto que nada de esto significa que las restricciones mismas son
poco
+importantes. Sería malo para un proyecto el animar a las personas
+a realizar cambios en areas para las cuales no estan cualificadas. Incluso
+en algunos proyectos, el acceso ilimitado tiene un status especial:
+implica derecho de voto en cuestiones que atañen al proyecto por
+completo. Este aspecto político del acceso es discutido en mayor
+profundidad en <xref linkend="electorate"/><phrase output="printed">
+en <xref linkend="social-infrastructure"/></phrase>.</para>
</sect3>
@@ -1879,239 +1869,252 @@
<!-- ========================== SECTION =========================== -->
<sect1 id="bug-tracker">
-<title>Bug Tracker</title>
-
-<para>Bug tracking is a broad topic; various aspects of it are
-discussed throughout this book. Here I'll try to concentrate mainly
-on setup and technical considerations, but to get to those, we have to
-start with a policy question: exactly what kind of information should
-be kept in a bug tracker?</para>
-
-<para>The term <firstterm>bug tracker</firstterm> is misleading. Bug
-tracking systems are also frequently used to track new feature
-requests, one-time tasks, unsolicited patches—really anything
-that has distinct beginning and end states, with optional transition
-states in between, and that accrues information over its lifetime.
-For this reason, bug trackers are also called <firstterm>issue
-trackers</firstterm>, <firstterm>defect trackers</firstterm>,
-<firstterm>artifact trackers</firstterm>, <firstterm>request
-trackers</firstterm>, <firstterm>trouble ticket systems</firstterm>,
-etc. See <xref linkend="bug-trackers"/> for a list of software.
-</para>
+<title>Seguimiento de errores</title>
-<para>In this book, I'll continue to use "bug tracker" for the
-software that does the tracking, because that's what most people call
-it, but will use <firstterm>issue</firstterm> to refer to a single
-item in the bug tracker's database. This allows us to distinguish
-between the behavior or misbehavior that the user encountered (that is,
-the bug itself), and the tracker's <emphasis>record</emphasis> of the
-bug's discovery, diagnosis, and eventual resolution. Keep in mind
-that although most issues are about actual bugs, issues can be used to
-track other kinds of tasks too.</para>
+<para>El seguimiento de errores es un tema muy amplio y varios
+aspectos de este son discutidos a lo largo de este libro. Aquí
+intentare concetrarme principalmente en las consideraciones técnicas
+y en la instalación, pero para llegar a esto, debemos empezar con
+una política de preguntas: exactamente ¿qué tipo de información
+va a ser mantenida en el sistema de seguimiento?.</para>
+
+<para>El término <firstterm>seguimiento de errores</firstterm> puede
+generar confusión ya que estos sistemas se utilizan frecuentemente
+para seguir solicitudes para nuevas caracteristicas, tareas que se
+efectuan sólo una vez, parches no solicitados—en realidad se
+utilizan para cualquier cosa que pueda tener estados distinguibles
+de comienzo y final, con estados opcionales de transición entre
+estos y que acumulan información a lo largo de su existencia. Por
+esta razón, los sistemas de seguimiento de fallos tambien son
+llamados <firstterm>de seguimiento de temas</firstterm>,
+<firstterm>de defectos</firstterm>,
+<firstterm>de solicitudes</firstterm>, <firstterm>trouble ticket
+system</firstterm>, etc. Más información en <xref linkend="bug-trackers"/>
+donde hay una lista de programas.</para>
+
+<para>En este libro continuare utlizando "gestor de fallos" para la
+aplicación que hace el seguimiento, porque es así como la mayoria
+de la gente lo llama y utilizare <firstterm>issue</firstterm> al
+referirme a un punto en particular en la base de datos del gestor
+de fallos. Esto nos permitira distinguir entre los buenos y malos
+comportamientos que el usuario se puede encontrar (el fallo en si
+mismo) y el <emphasis>registro</emphasis> en el gestor del
+descubrimiento, diagnostico y eventual resolución del fallo. Hay
+que recordar que aunque la mayoria de las entradas sean fallos,
+tambien pueden ser otras tareas.</para>
-<para>The classic issue life cycle looks like this:
+<para>El clásico ciclo de vida se parece al siguiente:
<orderedlist>
- <listitem><para>Someone files the issue. They provide a summary, an
- initial description (including a reproduction recipe, if
- applicable; see
- <xref
- linkend="users-to-volunteers"/><phrase
- output="printed"> in
- <xref linkend="managing-volunteers"/></phrase> for
- how to encourage good bug reports), and whatever other
- information the tracker asks for. The person who files
- the issue may be totally unknown to the project—bug
- reports and feature requests are as likely to come from
- the user community as from the developers.</para>
-
- <para>Once filed, the issue is in what's called an
- <firstterm>open</firstterm> state. Because no action has
- been taken yet, some trackers also label it as
- <firstterm>unverified</firstterm> and/or
- <firstterm>unstarted</firstterm>. It is not assigned to
- anyone; or, in some systems, it is assigned to a fake
- user to represent the lack of real assignation. At this
- point, it is in a holding area: the issue has been
- recorded, but not yet integrated into the project's
- consciousness.</para>
+ <listitem><para>
+ Alguien crea una entrada. Ofrecen un resumen, una descripción
+ inicial (incluyendo como reproducir el fallo si es posible. En
+ <xref linkend="users-to-volunteers"/><phrase output="printed">
+ en <xref linkend="managing-volunteers"/></phrase> hay ejemplos
+ de como se puede animar la correcta creación de reportes de fallos)
+ y cualquier otra información que el gestor solicite. Quien crea
+ la entrada puede ser un desconocido al proyecto—los reportes
+ de fallos y las solicitudes de caracteristicas provienen tanto
+ de los usuarios como de los desarrolladores.</para>
+
+ <para>Una vez enviada, la entrada entra en un estado llamado
+ <firstterm>abierto</firstterm> porque ninguna acción ha sido
+ tomada aun. Algunos gestores etiquetan las nuevas entradas
+ como <firstterm>sin veríficar</firstterm> o como
+ <firstterm>sin iniciar</firstterm>. No está asignada a nadie,
+ o en algunos sistemas, es asignada a un usuario fantasma que
+ representa la falta de una asignación real. Llegado a este
+ punto, la entrada se encuentra en el area de espera: ha sido
+ registrada, pero aun no ha sido integrada en la conciencia
+ del proyecto.</para>
</listitem>
- <listitem><para>Others read the issue, add comments to it, and
- perhaps ask the original filer for clarification on some
- points.</para>
+ <listitem><para>
+ Otros leen la entrada, añaden comentarios y quizas soliciten
+ el esclarecimiento de algunos puntos a quien realizo la entrada.</para>
</listitem>
- <listitem><para>The bug gets <firstterm>reproduced</firstterm>.
- This may be the most important moment in its
- life cycle. Although the bug is not actually fixed yet,
- the fact that someone besides the original filer was able
- to make it happen proves that it is genuine, and, no less
- importantly, confirms to the original filer that they've
- contributed to the project by reporting a real bug.</para>
+ <listitem><para>
+ El fallo es <firstterm>reproducido</firstterm>. Este puede que
+ sea el momento más importante en su ciclo vital, ya que incluso
+ que el fallo aun no ha sido resuelto, el hecho de que alguien
+ haya podido reproducirlo además de quien creo la entrada prueba
+ que es genuino y, no menos importante, confirma al creador
+ de la entrada que ha contribuido al proyecto reportando un
+ fallo real.</para>
</listitem>
- <listitem><para>The bug gets <firstterm>diagnosed</firstterm>: its
- cause is identified, and if possible, the effort required
- to fix it is estimated. Make sure these things get
- recorded in the issue; if the person who diagnosed the
- bug suddenly has to step away from the project for a
- while (as can often happen with volunteer developers),
- someone else should be able to pick up where she left
- off.</para>
-
- <para>In this stage, or sometimes the previous one, a
- developer may "take ownership" of the issue and
- <firstterm>assign</firstterm> it to herself (<xref
- linkend="delegation-assignment"/><phrase
- output="printed"> in
- <xref linkend="managing-volunteers"/></phrase>
- examines the assignment process in more detail). The issue's
- <firstterm>priority</firstterm> may also be set at this
- stage. For example, if it is so severe that it should
- delay the next release, that fact needs to be identified
- early, and the tracker should have some way of noting
- it.</para>
+ <listitem><para>
+ El fallo es <firstterm>diagnosticado</firstterm>: su causa
+ es identificada, y si es posible, es estimado el esfuerzo
+ requerido para repararlo. Hay que asegurarse de que todo esto
+ es registrado en la entrada, ya que en el case en que quien
+ haya hecho el diagnostico abandona el proyecto (lo cual
+ sucede a menudo con desarrolladores voluntarios), alguien más
+ debe ser capaz de continuar con su trabajo.</para>
+
+ <para>Llegados a este punto, o a veces en uno de los anteriores,
+ puede que algún programador ya se haya "adueñado" de la entrada y se
+ lo <firstterm>asigne</firstterm> a si mismo (el proceso es examinado
+ en mayor detalle en <xref linkend="delegation-assignment"/><phrase
+ output="printed"> en <xref linkend="managing-volunteers"/></phrase>).
+ La <firstterm>prioridad</firstterm> de la entrada puede que tambien
+ sea fijada en esta etapa. Por ejemplo, si el fallo es tan severo
+ que debería retrasar el próximo lanzamiento, debe ser identificado
+ desde el principio y el gestor debe proporcionar un mecanismo
+ para hacer esto.</para>
+
</listitem>
- <listitem><para>The issue gets scheduled for resolution.
- Scheduling doesn't necessarily mean naming a date by which
- it will be fixed. Sometimes it just means deciding which
- future release (not necessarily the next one) the bug
- should be fixed by, or deciding that it need not block any
- particular release. Scheduling may also be dispensed
- with, if the bug is quick to fix.</para>
+ <listitem><para>
+ La entrada es programada para su resolución. Esto no implica
+ necesariamente fijar una fecha para cuando debe ser resuelta.
+ A veces sólo significa decidir para cual próximo lanzamiento (no
+ necesariamente la siguiente) el fallo debe estar corregido o
+ decidir si debe o no bloquear un lanzamiento en particular.
+ Incluso nos podemos olvidar de planificar la reparación del
+ fallo si es algo que se puede hacer rapidamente.</para>
</listitem>
- <listitem><para>The bug gets fixed (or the task completed, or
- the patch applied, or whatever). The change or set of
- changes that fixed it should be recorded in a comment in
- the issue, after which the issue is
- <firstterm>closed</firstterm> and/or marked as
- <firstterm>resolved</firstterm>.</para>
+ <listitem><para>
+ El fallo es reparado (o la tarea es completada, o el
+ parche es aplicado o lo que sea). El cambio o conjunto de
+ cambios que arreglan el fallo deben ser registrados en un
+ comentario en la entrada, despues de lo cual ésta es
+ <firstterm>cerrada</firstterm> o marcada como
+ <firstterm>resuelta</firstterm>.</para>
</listitem>
</orderedlist>
</para>
-<para>There are some common variations on this life cycle. Sometimes
-an issue is closed very soon after being filed, because it turns out
-not to be a bug at all, but rather a misunderstanding on the part of
-the user. As a project acquires more users, more and more such
-invalid issues will come in, and developers will close them with
-increasingly short-tempered responses. Try to guard against the
-latter tendency. It does no one any good, as the individual user in
-each case is not responsible for all the previous invalid issues; the
-statistical trend is visible only from the developers' point of view,
-not the user's. (In
-<xref linkend="bug-filtering"/><phrase output="printed"> later
-in this chapter,</phrase> we'll look at
-techniques for reducing the number of invalid issues.) Also, if
-different users are experiencing the same misunderstanding over and
-over, it might mean that that aspect of the software needs to be
-redesigned. This sort of pattern is easiest to notice when there is
-an issue manager monitoring the bug database; see
-<xref linkend="issue-manager"/><phrase output="printed"> in
-<xref linkend="managing-volunteers"/></phrase>.</para>
-
-<para>Another common life cycle variation is for the issue to be closed
-as a <firstterm>duplicate</firstterm> soon after Step 1. A duplicate
-is when someone files an issue that's already known to the project.
-Duplicates are not confined to open issues: it's possible for a bug to
-come back after having been fixed (this is known as a
-<firstterm>regression</firstterm>), in which case the preferred course
-is usually to reopen the original issue and close any new reports as
-duplicates of the original one. The bug tracking system should keep
-track of this relationship bidirectionally, so that reproduction
-information in the duplicates is available to the original issue, and
-vice versa.</para>
-
-<para>A third variation is for the developers to close the issue,
-thinking they have fixed it, only to have the original reporter reject
-the fix and reopen it. This is usually because the developers simply
-don't have access to the environment necessary to reproduce the bug,
-or because they didn't test the fix using the exact same reproduction
-recipe as the reporter.</para>
-
-<para>Aside from these variations, there may be other small details of
-the life cycle that vary depending on the tracking software. But the
-basic shape is the same, and while the life cycle itself is not
-specific to open source software, it has implications for how open
-source projects use their bug trackers.</para>
-
-<para>As Step 1 implies, the tracker is as much a public face of the
-project as the mailing lists or web pages. Anyone may file an issue,
-anyone may look at an issue, and anyone may browse the list of currently
-open issues. It follows that you never know how many people are
-waiting to see progress on a given issue. While the size and skill of
-the development community constrains the rate at which issues can be
-resolved, the project should at least try to acknowledge each issue the
-moment it appears. Even if the issue lingers for a while, a response
-encourages the reporter to stay involved, because she feels that a
-human has registered what she has done (remember that filing an
-issue usually involves more effort than, say, posting an email).
-Furthermore, once an issue is seen by a developer, it enters the
-project's consciousness, in the sense that that developer can be on
-the lookout for other instances of the issue, can talk about it with
-other developers, etc.</para>
+<para>Existen variaciones en este ciclo. A veces el problema es cerrado
+seguidamente despues de ser archivado, porque resulta que no es un fallo,
+sino que es un malentendido por parte del usuario. Mientras el proyecto
+vaya ganando usuarios, más y más de estas entradas invalidas apareceran,
+y los desarrolladores las cerraran con respuestas cada vez menos
+respetuosas. Hay que intentar protegerse de ésta tendencia, pues no le
+hace ningún bien a nadie, porque el usuario en cada caso no es responsable
+de las entradas invalidas previas. Esta tendencia estadísticas sólo es
+divisada por los desarrolladores, no por los usuarios. (En
+<xref linkend="bug-filtering"/><phrase output="printed"> más adelante
+en este capítulo,</phrase> examinaremos algunas tecnicas para reducir
+el número de entradas invalidas.) Tambien puede suceder que varios
+usuarios esten experimentando el mismo malentendido una y otra vez,
+lo cual significa que algún aspecto de la aplicación necesita volver
+a ser diseñada. Este tipo de patrones son los más sencillos de ver
+cuando se utiliza un gestor de entradas que monitorice la base de
+datos de fallos. Más en <xref linkend="issue-manager"/><phrase
output="printed">
+en <xref linkend="managing-volunteers"/></phrase>.</para>
+
+<para>Otra variación muy común de este ciclo de vida es cuando la entrada
+es cerrada al ser un <firstterm>duplicado</firstterm> poco despues
+del paso 1. Un duplicado aparece cuando alguien crea una entrada para
+un problema ya conocido por el proyecto. Los duplicados no estan
+limitados a entradas abiertas: es posible que un fallo haya reaparecido
+despues de haberlo reparado (esto es conocido como
<firstterm>regresión</firstterm>),
+por lo cual, la via preferida es usualmente reabrir la entrada original y
+cerrar cualquier nuevo reporte como duplicado de este. El sistema
+de gestión de fallo debe mantener un seguimiento de esta relación
+bidimensional, de forma que la información en los duplicados este
+disponible en la entrada original y vice versa.</para>
+
+<para>Una tercera variación es cuando los desarrolladores cierran la
+entrada pensando que ya ha sido resuelta y el usuario que la ha
+reportado rechaza esa reparación y es reabierta. Por lo general esto
+es porque el desarrollador no tiene la capacidad de reproducir
+el fallo o porque no han probado su reparación siguiendo
+la misma receta para la reproducción descrita por el usuario.</para>
+
+<para>A parte de estas variaciones existen pequeños detalles de
+este ciclo de vida que pueden variar dependiendo de la aplicación
+de seguimiento. Pero la forma básica es la misma e incluso cuando
+el ciclo de vida no es sólo para el software open source, tiene
+implicaciones acerca de cómo los proyectos utilizan sus
+sistemas de control de fallos.</para>
+
+<para>Implicito en el paso 1, el sistema es una cara tan publica
+del proyecto, como lo pueden ser las listas de correo o las paginas
+web. Cualquiera puede crear una entrada, cualquiera puede ver
+una entrada y cualquiera puede navegar la lista de entradas
+abiertas. De tal manera que nunca se sabe cuantas personas estan
+interesadas en ver el progreso en una entrada en particular. Aunque
+el tamaño y la capacidad de la comunidad de desarrolladores constriñe
+la frecuencia con la que los problemas son atacados, el proyecto
+debe al menos intentar reconocer cada entrada mientras vayan
+llegando. Incluso si el problema persiste por un tiempo, una
+repuesta anima al usuario a mantenerse involucrado porque siente
+que un humano ha visto lo que ha hecho (recordad que rellenar
+una entrada requiere mucho más tiempo que un correo electrónico).
+Incluso mejor, una vez que una entrada es vista por un desarrollador,
+entra en la conciencia del proyecto, en el sentido en que este
+puede mantenerse al acecho de otras instancias del mismo problema,
+puede comentarlo con otros desarrolladores, etc.</para>
-<para>The need for timely reactions implies two things:
+<para>La necesidad de reacciones oportunas implica dos cosas:
<itemizedlist>
<listitem>
- <para>The tracker must be connected to a mailing list, such that
- every change to an issue, including its initial filing, causes a
- mail to go out describing what happened. This mailing list
- is usually different from the regular development list, since not
- all developers may want to receive automated bug mails, but (just
- as with commit mails) the Reply-to header should be set to the
- development mailing list.</para>
+ <para>
+ El sistema de seguimiento debe conectarse a la lista de correos
+ de manera que cada cambio a una entrada, incluyendo su redacción
+ inicial, genere un correo describiendo lo sucedido. Esta lista
+ de correos es, a veces, diferente de la lista de desarrollo ya
+ que quizas, no todos los desarrolladores quieran recibir correos
+ automaticos con fallos, pero (al igual que con los correos con
+ cambios) la cabecera Reply-to debe ser fijada a la lista
+ de desarrollo.</para>
</listitem>
<listitem>
- <para>The form for filing issues should capture the reporter's
- email address, so she can be contacted for more information.
- (However, it should not <emphasis>require</emphasis> the
- reporter's email address, as some people prefer to report issues
- anonymously. See
- <xref linkend="anonymity"/><phrase output="printed"> later
- in this chapter</phrase> for more on the importance of
- anonymity.)</para>
+ <para>
+ El formulario donde se rellena la entrada debe almacenar la
+ dirección de correo electrónico de quien la reporta, de forma
+ que pueda ser contactada para solicitar más información.
+ (No obstante, no debe <emphasis>requerir</emphasis> la
+ dirección ya que algunas personas prefieren realizar el
+ reporte anonimamente. Más información sobre el anonimato
+ en <xref linkend="anonymity"/><phrase output="printed">
+ a continuación en este capítulo</phrase>.</para>
</listitem>
</itemizedlist>
</para>
<sect2 id="bug-tracker-mailing-list-interaction">
-<title>Interaction with Mailing Lists</title>
+<title>Interacción con las Lista de Correo</title>
-<para>Make sure the bug tracker doesn't turn into a discussion forum.
-Although it is important to maintain a human presence in the bug
-tracker, it is not fundamentally suited to real-time discussion.
-Think of it rather as an archiver, a way to organize facts and
-references to other discussions, primarily those that take place on
-mailing lists.</para>
-
-<para>There are two reasons to make this distinction. First, the bug
-tracker is more cumbersome to use than the mailing lists (or than
-real-time chat forums, for that matter). This is not because bug
-trackers have bad user interface design, it's just that their
-interfaces were designed for capturing and presenting discrete states,
-not free-flowing discussions. Second, not everyone who should be
-involved in discussing a given issue is necessarily watching the bug
-tracker. Part of good issue management (see
-<xref linkend="share-management"/><phrase output="printed"> in
-<xref linkend="managing-volunteers"/></phrase>) is to make sure
-each issue is brought to the right peoples' attention, rather than
-requiring every developer to monitor all issues. In
-<xref linkend="bug-tracker-usage"/><phrase output="printed"> in <xref
linkend="communications"/>,</phrase> we'll look at ways to make
-sure people don't accidentally siphon discussions out of appropriate
-forums and into the bug tracker.</para>
-
-<para>Some bug trackers can monitor mailing lists and automatically
-log all emails that are about a known issue. Typically they do this
-by recognizing the issue's identifying number in the subject line of
-the mail, as part of a special string; developers learn to include
-these strings in their mails to attract the tracker's notice. The bug
-tracker may either save the entire email, or (even better) just record
-a link to the mail in the regular mailing list archive. Either way,
-this is a very useful feature; if your tracker has it, make sure
-both to turn it on and to remind people to take advantage of
-it.</para>
+<para>Hay que asegurarse de que el gestor de fallos no se convierte
+en un foro de discusiones. Aunque es importante mantener una presencia
+humana en el gestor, no está preparado para discusiones en tiempo
+real. Hay que pensar en éste como un archivador, una forma de
+organizar hechos y referencias a otras discusiones, principalmente
+aquellas que suceden en las listas de correo.</para>
+
+<para>Hay dos razones por las cuales es importante hacer esta distinción.
+Primero, el gestor de fallos es un sistema más engorroso que las
+lista de correo (o que salas de chat). Esto no es porque esten mal
+diseñados, es sólo que sus interfaces han sido diseñadas para capturar
+y presentar estados discretos, no discusiones. Segundo, no todo el
+mundo que este involucrado en una discusión sobre una entrada en
+particular, esta revisando el gestor de fallos frecuentemente. Parte
+de una buena gestión de fallos (más en
+<xref linkend="share-management"/><phrase output="printed"> en
+<xref linkend="managing-volunteers"/></phrase>) está en asegurarse
+de que cada problema es llevado a la atención de las personas
+indicadas en lugar de requerir que todos los desarrolladores
+monitoricen todos los problemas. En
+<xref linkend="bug-tracker-usage"/><phrase output="printed"> en
+<xref linkend="communications"/>,</phrase>
+veremos como asegurarnos de que la gente no desvie accidentalmente
+las discusiones de los foros apropiados hacia el sistema
+de gestion de fallos.</para>
+
+<para>Algunos gestores pueden monitorizar listas de correos y
+automaticamente registrar todos los correos que son acerca de un
+problema conocido. Por lo general, hacen esto reconociendo el
+número de identificación de la entrada en el asunto de los
+correos, como parte de una línea especial, así los desarrolladores
+pueden aprender a incluir estas lineas en sus correos para atraer
+la atención del gestor. El sistema puede guardar el correo completo
+o (incluso mejor) registrar un enlace al correo en el archivo regular
+de la lista de correos. De cualquier forma, ésta es una habilidad
+muy útil, así que si el sistema utilizado la aporta hay que utilizarla
+y hay que recordarle a la gente que la utilice.</para>
</sect2>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
