Author: francisco
Date: Sun Aug 19 19:27:32 2007
New Revision: 1035
Log:
Segundo párrafo del la sección "praise-and-criticism" y algunas correciones en
el capítulo 8.
Modified:
trunk/es/ch08.xml
Modified: trunk/es/ch08.xml
==============================================================================
--- trunk/es/ch08.xml (original)
+++ trunk/es/ch08.xml Sun Aug 19 19:27:32 2007
@@ -107,8 +107,8 @@
<para>Esas normas no aparecen por sí solas. Por ejemplo, en algunos proyectos
(desarrolladores con experiencia en código abierto podrían mencionar varias de
memoria) la gente piensa que se gana prestigio por enviar largos mensajes
-frencuentemente. No llegan a esta conclusión por casualidad, llegan a ella
-porque son recompesados con respeto por crear largos e intrincados argumentos,
+frecuentemente. No llegan a esta conclusión por casualidad, llegan a ella
+porque son recompensados con respeto por crear largos e intrincados argumentos,
independientemente de que estos ayuden al proyecto. A continuación se explican
algunas técnicas para crear una atmósfera en la que se pueda adquirir prestigio
a través de acciones constructivas.</para>
@@ -161,8 +161,8 @@
donde no está nada claro que puedas esperar que alguien haga cargo. La
persona podría hacer lo que le pides, o quizá no. Como a nadie le gusta que
se dé por hecho que va a obedecer, has de ser consciente en todo momento de
-cual de estas dos situacioness estás tratando y, en función de la misma,
-medir tus palabras a la hora de soliciar una tarea.
+cual de estas dos situaciones estás tratando y, en función de la misma,
+medir tus palabras a la hora de solicitar una tarea.
<para>Algo que casi siempre sienta mal es que te pidan hacer algo como si
fuera tu responsabilidad cuanto tu piensas que no es así. Por ejemplo,
@@ -187,13 +187,13 @@
quieres que puede arreglar el problema más rápidamente haga el trabajo.
Dado que no puedes permitirte establecer un diálogo para todas y cada
una de las tareas que se han de asignar ("¿Te importaría echarle un vistazo
-a este error?" "Sí." "Vale, entonces te asigno la tarea a tí." "Vale."),
+a este error?" "Sí." "Vale, entonces te asigno la tarea a ti." "Vale."),
deberías siempre asignar tareas en forma de petición, sin ejercer presión
alguna. Casi todos los gestores de errores permiten asociar comentarios
a la tarea asignada. En dicho comentario podrías decir algo así:</para>
<blockquote>
- <para>Tarea asignada a tí, jaleatorio, porque tu eres la persona
+ <para>Tarea asignada a ti, jaleatorio, porque tu eres la persona
más familiarizada con este código. No te preocupes si no puedes
hacerte cargo de la tarea por el motivo que sea. (En cualquier
caso hazme saber si preferirías no recibir más tareas en el futuro.)</para>
@@ -214,7 +214,7 @@
y supervisa con él la tarea pase lo que pase. La mayoría de peticiones
se hace en foros públicos más o menos de la siguiente manera "¿Podrías
encargarte de X? Dinos algo en cualquier caso. En caso de que no puedas
-no pasa nada, pero haznoslo saber." Pueden responder, o no, a tu petición,
+no pasa nada, pero háznoslo saber." Pueden responder, o no, a tu petición,
pero si te responden, y la respuesta es negativa, el proceso se cierra y
tendrás que buscar alternativas para llevar a cabo la tarea X. Si la
respuesta es positiva entonces vigila como progresa el trabajo y haz
@@ -255,7 +255,7 @@
interés por tener una versión 1.0 era compartido por todos. Las comunicaciones
electrónicas pueden ser muy engañosos; puedes pensar que hay un ambiente de
propósito
común cuando, en realidad, dicho propósito sólo es compartido por la gente con
-la que tú has estado hablando, mientras otras personas tienen prioridades
complentamente
+la que tú has estado hablando, mientras otras personas tienen prioridades
completamente
distintas</para>
<para>Cuanto más consciente seas de lo que la gente quiere sacar del proyecto,
más
@@ -275,28 +275,27 @@
muy similares. Ambas son muestras de atención, y son más efectivas cuando
son específicas que cuando son genéricas. Ambas deben hacerse con metas
específicas en mente. Ambas pueden diluirse por el abuso; halaga mucho o
-demasiado y tus halagos perderán valor, y lo mismo sirver para las críticas
+demasiado y tus halagos perderán valor, y lo mismo sirve para las críticas
aunque, en la práctica, las críticas provocan reacciones que las hacen
mucho más resistentes a la devaluación.</para>
-<para>An important feature of technical culture is that detailed,
-dispassionate criticism is often taken as a kind of praise (as
-discussed in <xref linkend="rudeness"/><phrase output="printed">
-in <xref linkend="communications"/></phrase>), because of the
-implication that the recipient's work is worth the time required to
-analyze it. However, both of those
-conditions—<emphasis>detailed</emphasis> and
-<emphasis>dispassionate</emphasis>—must be met for this to be
-true. For example, if someone makes a sloppy change to the code, it
-is useless (and actually harmful) to follow up saying simply "That was
-sloppy." Sloppiness is ultimately a characteristic of a
-<emphasis>person</emphasis>, not of their work, and it's important to
-keep your reactions focused on the work. It's much more effective to
-describe all the things wrong with the change, tactfully and without
-malice. If this is the third or fourth careless change in a row by
-the same person, it's appropriate to say that—again without
-anger—at the end of your critique, to make it clear that the
-pattern has been noticed.</para>
+<para> Un importante aspecto de la cultura tecnológica es que la detallada y
+desapasionada crítica amenudo se toma como una especia de alago (como se
+vio en <xref linkend="rudeness"/><phrase output="printed">
+en <xref linkend="communications"/></phrase>), esto se debe a la implicación
+de que el trabajo en cuestión vale la pena ser analizado. En cualquier caso,
+ambos aspectos; <emphasis>detallada</emphasis> y
<emphasis>desapasionada</emphasis>
+han de cumplirse para que esto se cumpla. Por ejemplo, si alguien hace
+algún cambio chapucero en el código, es inútil (y de hecho perjudicial)
+comentar el asunto simplemente diciendo "Eso es una chapuza". El ser un
+chapuzas es, al final, una característica de la <emphasis>persona</emphasis>,
+no de su trabajo, y es importante mantener tu atención enfocada en el
+trabajo hecho. Es mucho más eficiente describir todas las cosas equivocadas
+que se han introducido al realizar el cambio, y hay que hacerlo con
+tacto y sin malicia. Si fuera el tercer o cuarto cambio descuidado de la
+misma persona, entonces lo más apropiado mencionar el hecho, después de la
+crítica sobre el trabajo realizado, y de nuevo sin ningún signo de enfado,
+para así dejar claro que dicho patrón de comportamiento es evidente.
<para>If someone does not improve in response to criticism, the
solution is not more or stronger criticism. The solution is for the
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
