Author: alejandroayuso Date: Tue Aug 7 20:00:51 2007 New Revision: 896 Log: more of ch03... 90%
Modified: trunk/es/ch03.xml Modified: trunk/es/ch03.xml ============================================================================== --- trunk/es/ch03.xml (original) +++ trunk/es/ch03.xml Tue Aug 7 20:00:51 2007 @@ -2119,110 +2119,123 @@ </sect2> <sect2 id="bug-filtering"> -<title>Pre-Filtering the Bug Tracker</title> +<title>Pre-filtrado del gestor de fallos</title> -<para>Most issue databases eventually suffer from the same problem: a -crushing load of duplicate or invalid issues filed by well-meaning but -inexperienced or ill-informed users. The first step in combatting -this trend is usually to put a prominent notice on the front page of -the bug tracker, explaining how to tell if a bug is really a bug, how -to search to see if it's already been filed, and finally, how to -effectively report it if one still thinks it's a new bug.</para> - -<para>This will reduce the noise level for a while, but as the number -of users increases, the problem will eventually come back. No -individual user can be blamed for it. Each one is just trying to -contribute to the project's well-being, and even if their first bug -report isn't helpful, you still want to encourage them to stay -involved and file better issues in the future. In the meantime, -though, the project needs to keep the issue database as free of junk -as possible.</para> - -<para>The two things that will do the most to prevent this problem -are: making sure there are people watching the bug tracker who have -enough knowledge to close issues as invalid or duplicates the moment -they come in, and requiring (or strongly encouraging) users to confirm -their bugs with other people before filing them in the tracker.</para> - -<para>The first technique seems to be used universally. Even projects -with huge issue databases (say, the Debian bug tracker at -<ulink url="http://bugs.debian.org/"/>, which contained 315,929 issues -as of this writing) still arrange things so that -<emphasis>someone</emphasis> sees each issue that comes in. It may be -a different person depending on the category of the issue. For -example, the Debian project is a collection of software packages, so -Debian automatically routes each issue to the appropriate package -maintainers. Of course, users can sometimes misidentify an issue's -category, with the result that the issue is sent to the wrong person -initially, who may then have to reroute it. However, the important -thing is that the burden is still shared—whether the user -guesses right or wrong when filing, issue watching is still -distributed more or less evenly among the developers, so each issue is -able to receive a timely response.</para> - -<para>The second technique is less widespread, probably because it's -harder to automate. The essential idea is that every new issue gets -"buddied" into the database. When a user thinks he's found a problem, -he is asked to describe it on one of the mailing lists, or in an IRC -channel, and get confirmation from someone that it is indeed a bug. -Bringing in that second pair of eyes early can prevent a lot of -spurious reports. Sometimes the second party is able to identify that -the behavior is not a bug, or is fixed in recent releases. Or she may -be familiar with the symptoms from a previous issue, and can prevent a -duplicate filing by pointing the user to the older issue. Often it's -enough just to ask the user "Did you search the bug tracker to see if -it's already been reported?" Many people simply don't think of that, -yet are happy to do the search once they know someone's -<emphasis>expecting</emphasis> them to.</para> - -<para>The buddy system can really keep the issue database clean, but -it has some disadvantages too. Many people will file solo anyway, -either through not seeing, or through disregarding, the instructions -to find a buddy for new issues. Thus it is still necessary for -volunteers to watch the issue database. Furthermore, because most new -reporters don't understand how difficult the task of maintaining the -issue database is, it's not fair to chide them too harshly for -ignoring the guidelines. Thus the volunteers must be vigilant, and -yet exercise restraint in how they bounce unbuddied issues back to -their reporters. The goal is to train each reporter to use the -buddying system in the future, so that there is an ever-growing pool -of people who understand the issue-filtering system. On seeing an -unbuddied issue, the ideal steps are:</para> +<para>Muchas de las bases de datos de fallos sufren eventualmente del mismo +problema: una cantidad devastadora de fallos duplicados o invalidos hechos +por usuarios bien intencionados pero sin experiencia o poco informados. El +primer paso para combatir esta tendencia es, por lo general, colocar un vistoso +aviso en la página principal del gestor de fallos, explicando como saber si +un bug es realmente un bug, como buscar si el bug ya está incluido y finalmente, +como reportar efectivamente si aun se cree que es un nuevo fallo.</para> + +<para>Esto reducira el nivel de ruido por un tiempo, pero mientras el +número de usuarios vaya creciendo, el problema regresara eventualmente. +Ningún individuo puede ser culpado de esto, ya que cada uno está +intentando contribuir en beneficio del proyecto e incluso cuando +su primer reporte no sea de verdadera utilidad, se desea animarlos +para que continuen involucrandose y para que puedan hacer mejores +reportes en el futuro. Mientras tanto, el proyecto necesita mantener +en lo posible la base de datos libre de basura.</para> + +<para>Las dos cosas que tendrán el máximo efecto a la hora de prevenir +este problema son: aseguranos de que hay gente vigilando el gestor de fallos +quienes tienen el conocimiento suficiente para cerrar problemas como +invalidos o duplicados mientras vayan llegando y requiriendo (o fomentando +duramente) a los usuarios que confirme su reporte con otras personas antes +de reportarlos en el gestor.</para> + +<para>La primera técnica parece ser utilizada universalmente. Incluso +proyectos con gigantescas bases de datos de fallos (digamos, el gestor +de Debian en +<ulink url="http://bugs.debian.org/"/>, el cual contenia 315,929 reportes +al momento de escribir este libro) siguen ordenando todo de tal manera +que <emphasis>todos</emphasis> puedan ver los reportes mientras llegan. +Puede que sea una persona diferente dependiendo de la categoria del +problema. Por ejemplo, el proyecto Debian es una colección de páquetes +de software, de manera que el proyecto automaticamente enruta cada +reporte a la persona que mantiene el páquete específico. Por supuesto, +a veces los usuarios no identifican bien la categoria a la que pertenece +el problema, con el resultado de que el reporte es enviado a la persona +equivocada, quien entonces deberá redireccionarlo. No obstante, lo +importante es que la carga sigue siendo distribuida—cada vez que +un usuario crea correcta o incorrectamente al reportar, la vigilancia +de las entradas sigue siendo distribuida más o menos uniformemente entre los +desarrolladores, de manera que cada reporte es respondido en un tiempo +justo.</para> + +<para>La segunda técnica esta menos extendida, probablemente sea porque +es más difícil de automatizar. La ídea escencial es que cada nuevo +reporte es apadrinado hacia la base de datos. Cuando un usuario cree +haber encontrado un bug, se le pide que lo describa en una de las +listas de correo o en algún canal de IRC para que reciba confirmación +de alguien de que en realidad es un fallo. Al introducir este segundo +par de ojos puede prevenir muchos reportes falsos. A veces esta segunda +persona puede identificar que este comportamiento no es un fallo o que +ha sido resuelto recientemente. O puede que este familiarizado con los +sintomas gracias a problemas anteriores, evitando un duplicado +al señalar al usuario el viejo reporte. A veces es tan sencillo como +preguntar al usuario "¿Has revisado el gestor de fallos para asegurarte +de que no ha sido reportado ya?" Muchas personas no piensan en esto, +pero se contentan con hacer la búsqueda sabiendo que hay alguien +a la <emphasis>expectativa</emphasis> de que lo hagan.</para> + +<para>El sistema de apadrinamiento puede mantener la limpieza de +los reportes en la base de datos, pero tambien tiene algunas +desventajas. Muchas personas harán los reportes sin consultar, +al no buscar o despreocupandose de las instrucciones de buscar a un +padrino para el nuevo reporte. Aun así, es necesario que los +voluntarios sigan vigilando las bases de datos y dado que la +mayoria de los nuevos usuarios que reportan fallos no entienden +la dificultad de mantenerlas, no es justo +reprenderlos duramente por ignorar las directrices. Aun así, los +voluntarios deben ser vigilantes y ejercitar destricciones en como +se rechazan reportes sin apadrinar de vuelta a quien lo haya hecho. +El objetivo es entrenar a cada reportero para que utilice el sistema +de apadrinamiento en el futuro, de tal manera que haya una siempre +creciente fondo de gente quienes entienden el sistema de filtrado +de fallos. Al encontrarnos con un reporte sin padrino, los pasos +ideales a tomar son:</para> <orderedlist> <listitem> - <para>Immediately respond to the issue, politely thanking the user - for filing, but pointing them to the buddying guidelines - (which should, of course, be prominently posted on the web - site).</para> + <para> + Inmediatamente responder el reporte, agradeciendo al usuario + por hacerlo, pero dirigiendolo a las directrices de apadronamiento + (las cuales deberian, por supuesto, estar publicadas en un lugar + promiente del sitio web.) + </para> </listitem> <listitem> - <para>If the issue is clearly valid and not a duplicate, approve it - anyway, and start it down the normal life cycle. After all, - the reporter's now been informed about buddying, so there's - no point wasting the work done so far by closing a valid - issue.</para> + <para> + Si el reportes es claramente valido y no un duplicado, hay que + aprobarlo de todas formas y de esta manera que inicie su + ciclo de vida normal. Despues de todo, quien ha realizado el + reporte ya ha sido informado sobre el apadrinamiento, asi que + no tiene sentido perder el trabajo ya hecho al cerrarlo como + invalido.</para> </listitem> <listitem> - <para>Otherwise, if the issue is not clearly valid, close it, but - ask the reporter to reopen it if they get confirmation from - a buddy. When they do, they should put a reference to the - confirmation thread (e.g., a URL into the mailing list - archives).</para> + <para> + Si el problema no es claramente valido, hay que cerrarlo, pero + solicitando que sea reabierto si reciben la confirmación por + parte de un padrino. Cuando lo hagan, deberan colocar una + referencia al hilo de confirmación (por ejemplo, una URL en + el archivo de la listas de correo).</para> </listitem> </orderedlist> -<para>Remember that although this system will improve the signal/noise -ratio in the issue database over time, it will never completely stop -the misfilings. The only way to prevent misfilings entirely is to -close off the bug tracker to everyone but developers—a cure that -is almost always worse than the disease. It's better to accept that -cleaning out invalid issues will always be part of the project's -routine maintenance, and to try to get as many people as possible to -help.</para> +<para>Hay que recordar que a pesar de que este sistema mejorara la proporción +señal/ruido en la base de datos de problemas a lo largo del tiempo, nunca +pondrá fin a los reportes invalidos. La única manera de evitar esto +por completo es cerrar el gestor de fallos a todos quienes no sean +desarrolladores—una cura que casí siempre es peor que la +enfermedad. Es mejor aceptar que la limpieza de reportes invalidos siempre +será una parte de la rutina de mantenimiento del proyecto e intentar obtener +la mayor cantidad de ayuda para hacerlo.</para> -<para>See also -<xref linkend="issue-manager"/><phrase output="printed"> in +<para>Más en +<xref linkend="issue-manager"/><phrase output="printed"> en el <xref linkend="managing-volunteers"/></phrase>.</para> </sect2> @@ -2231,114 +2244,113 @@ <!-- ========================== SECTION =========================== --> <sect1 id="irc"> -<title>IRC / Real-Time Chat Systems</title> +<title>IRC / Sistemas de Chat en Tiempo Real</title> -<para>Many projects offer real-time chat rooms using <firstterm>Internet -Relay Chat</firstterm> (<firstterm>IRC</firstterm>), forums where users -and developers can ask each other questions and get instant responses. -While you <emphasis>can</emphasis> run an IRC server from your own -web site, it is generally not worth the hassle. Instead, do what -everyone else does: run your IRC channels at Freenode -(<ulink url="http://freenode.net/"/>). Freenode gives you the control -you need to administer your project's IRC -channels,<footnote><para>There is no requirement or expectation that -you donate to Freenode, but if you or your project can afford it, -please consider a contribution. They are a tax-exempt charity in the -U.S., and they perform a valuable service.</para></footnote> while -sparing you the not-insignificant trouble of maintaining an IRC server -yourself.</para> - -<para>The first thing to do is choose a channel name. The most -obvious choice is the name of your project—if that's available -at Freenode, then use it. If not, try to choose something as close to -your project's name, and as easy to remember, as possible. Advertise -the channel's availabity from your project's web site, so a visitor -with a quick question will see it right away. For example, this -appears in a prominently placed box at the top of Subversion's home -page:</para> +<para>Muchos proyectos ofrecen salas de chat utilizando <firstterm>Internet +Relay Chat</firstterm> (<firstterm>IRC</firstterm>), foros donde los +usuarios y desarrolladores pueden hacerse preguntas y obtener respuestas +instantaneas. Mientras que se <emphasis>puede</emphasis> llevar un +servidor de IRC para nuestro sitio web, por lo general no vale la pena. En +cambio podemos hacer lo que todo el mundo: crear canales de IRC en +Freenode (<ulink url="http://freenode.net/"/>). Freenode proporcina +el control necesario para administrar los canales IRC del proyecto, +<footnote><para>No es un requerimiento ni tampoco se espera ninguna donación +a Freenode, pero si usted o el proyecto se lo pueden permitir, por favor +considerelo. Son una caridad exenta de impuestos en EE.UU. y proveen +de un servicio muy valioso.</para></footnote>mientras que nos evita +la molestia de tener que mantener un servidor de IRC.</para> + +<para>Lo primero que hay que hacer es decidir un nombre para el cánal. La +opción más obvia es utilizar el nombre del proyecto—si es que se +encuentra disponible en Freenode. Si no, se puede utilizar algo lo más +parecido al nombre del proyecto y que sea en lo posible, fácil de recordar. +Hay que publicitar la disponibilidad del cánal en el sitio web del proyecto, +de manera que un visitante con una duda pueda verlo rapidamente. Por ejemplo, +esto aparece en un contenedor promiente en la parte de arriba de la página +principal de Subversion:</para> <blockquote> - <para><emphasis>If you're using Subversion, we recommend that you - join the</emphasis> <literal>[EMAIL PROTECTED]</literal> - <emphasis>mailing list, and read the <ulink - url="http://svnbook.red-bean.com/";>Subversion Book</ulink> and - <ulink - url="http://subversion.tigris.org/faq.html";>FAQ</ulink>. - You can also ask questions on IRC at</emphasis> - <literal>irc.freenode.net</literal> - <emphasis>channel</emphasis> <literal>#svn</literal>.</para> + <para><emphasis>Si está utilizando Subversion, le recomendamos que se una + a la lista</emphasis> <literal>[EMAIL PROTECTED]</literal> + <emphasis> y lea el <ulink + url="http://svnbook.red-bean.com/";>Libro de Subversion</ulink> + y el + <ulink url="http://subversion.tigris.org/faq.html";>FAQ</ulink>. + Tambien puede comentar sus dudas en IRC en el cánal <literal>#svn</literal> en</emphasis> + <literal>irc.freenode.net</literal> + </para> </blockquote> -<para>Some projects have multiple channels, one per subtopic. For -example, one channel for installation problems, another for usage -questions, another for development chat, etc. (<xref -linkend="growth"/><phrase output="printed"> in -<xref linkend="communications"/></phrase> discusses and how to -divide into multiple channels). When your project is young, there -should only be one channel, with everyone talking together. Later, as -the user-to-developer ratio increases, separate channels may become -necessary.</para> - -<para>How will people know all the available channels, let alone which -channel to talk in? And when they talk, how will they know what the -local conventions are?</para> - -<para>The answer is to tell them by setting the <firstterm>channel -topic</firstterm>.<footnote><para>To set a channel topic, use the -<literal>/topic</literal> command. All commands in IRC start with -"<literal>/</literal>". See <ulink url="http://www.irchelp.org/"/> if -you're not familiar with IRC usage and administration; in particular, -<ulink url="http://www.irchelp.org/irchelp/irctutorial.html"/> is an -excellent tutorial.</para></footnote> The channel topic is a brief -message each user sees when they first enter the channel. It gives -quick guidance to newcomers, and pointers to further information. For -example:</para> +<para>Algunos proyectos tienen varios canales, uno para cada tema. Por +ejemplo, un cánal para problemas de instalación, otro para dudas sobre su +uso, otro para charlas sobre el desarrollo, etc. +(<xref linkend="growth"/><phrase output="printed"> en el +<xref linkend="communications"/></phrase> se discute como dividirse +en multiples canales). Cuando el proyecto es joven, sólo debe haber un cánal +en el que todos hablan juntos. Luego, mientras el proyecto vaya creciendo, la +separación de canales será necesaria.</para> + +<para>¿Cómo podrá la gente encontrar todos los canales disponibles y además, +en cuales entrar? ¿Y al entrar, cómo sabrán los críterios de la sala?</para> + +<para>La respuesta a todo esto es publicandolo en el <firstterm>tópico +del cánal</firstterm>.<footnote><para>Para establecer el tópico del +cánal se utiliza el comando "<literal>/topic</literal>. Todos los comandos +en IRC empiezan con el signo "<literal>/</literal>". Si no se está familiarizado +con la utilización y administración de IRC id a <ulink url="http://www.irchelp.org"/>. +Hay un excelente tutorial en +<ulink url="http://www.irchelp.org/irchelp/irctutorial.html"/>.</para></footnote> +El tópico del cánal es un breve mensaje que ven todos los usuarios cuando +entran en el cánal. Da una guia rápida para los recien llegados y apunta a información +necesaria. Por ejemplo:</para> + <screen> -You are now talking on #svn +Ha entrado en #svn + +El tema para #svn es Foro para usuarios de Subversion. Más información en +http://subversion.tigris.org/. || Las discuciones sobre el desarrollo +estan en #svn-dev. || Por favor, no pegue transcripciones muy largas, +para ello utilice un sitio como http://pastebin.ca/ || Noticias: +Subversion 1.1.0 ha salido, más en http://svn110.notlong.com/ -Topic for #svn is Forum for Subversion user questions, see also -http://subversion.tigris.org/. || Development discussion happens in -#svn-dev. || Please don't paste long transcripts here, instead use -a pastebin site like http://pastebin.ca/. || NEWS: Subversion 1.1.0 -is released, see http://svn110.notlong.com/ for details. </screen> -<para>That's terse, but it tells newcomers what they need to know. It -says exactly what the channel is for, gives the project home page (in -case someone wanders into the channel without having first been to the -project web site), mentions a related channel, and gives some guidance -about pasting.</para> +<para>Es algo tosco, pero informa a quienes entran al cánal lo que necesitan +saber. Dice exactamente para lo que es el cánal, muestra la página +web del proyecto (en caso de que alguien entre al cánal sin antes haber +visitado el sitio web del proyecto), menciona canales relacionados y +da algunas directivas sobre el pegado.</para> <sidebar id="paste-sites"> -<title>Paste Sites</title> +<title>Sitios de pegado</title> -<para>An IRC channel is a shared space: everyone can see what everyone -else is saying. Normally, this is a good thing, as it allows people -to jump into a conversation when they think they have something to -contribute, and allows spectators to learn by watching. But it -becomes problematic when someone has to provide a large quantity of -information at once, such as a debugging session transcript, because -pasting too many lines of output into the channel will disrupt other -conversations.</para> - -<para>The solution is to use one of the -<firstterm>pastebin</firstterm> or <firstterm>pastebot</firstterm> -sites. When requesting a large amount of data from someone, ask them -not to paste it into the channel, but instead to go to (for example) -<ulink url="http://pastebin.ca/"/>, paste their data into the form -there, and tell the resulting new URL to the IRC channel. Anyone can -then visit the URL and view the data.</para> +<para>Un cánal de IRC es un espacio compartido: todos pueden ver lo que +todos escriben. Normalmente esto es algo bueno, ya que permite que la +gente entre en una conversación cuando creen que tienen algo para +contribuir y permite a los espectadores aprender leyendo. Pero puede +tornarse problematico cuando alguien suministra una gran cantidad +de información a la vez, como la transcripción de una sesión de +debugging, porque al pegar muchas lineas de texto en el cánal +se interrumpen las conversaciones de otros.</para> + +<para>La solución a esto es el uso de los llamados sitios de pegado +<firstterm>pastebin</firstterm> o <firstterm>pastebot</firstterm>. +Al requerir una gran cantidad de datos de alguien, pida que no los pegue +en el cánal, sino que vayan a (por ejemplo) <ulink url="http://pastebin.ca"; />, +peguen la información necesaria allí y suministren el nuevo URL resultante +al cánal de IRC. Así cualquiera puede visitar la URL y revisar los +datos que allí se encuentran.</para> -<para>There are a number of free paste sites available now, too many -for a comprehensive list, but here are some of the ones I've seen used: +<para>Existen muchos sitios gratuitos de pegado disponibles, demasiados +para una lista comprensiva, pero aquí hay algunos que he utilizado: <ulink url="http://www.nomorepasting.com/"/>, <ulink url="http://pastebin.ca/"/>, <ulink url="http://nopaste.php.cd/"/> <ulink url="http://rafb.net/paste/"/> <ulink url="http://sourcepost.sytes.net/"/>, <ulink url="http://extraball.sunsite.dk/notepad.php"/>, -and +y <ulink url="http://www.pastebin.com/"/>.</para> </sidebar> @@ -2353,58 +2365,64 @@ channel, that is, the commands are delivered by "speaking to" the bot. For example:</para> +<para>Muchos canales tecnicos de IRC tienen un miembro no humano, un tal +llamado <firstterm>bot</firstterm>, el cual es capaz de almacenar y +regurgitar información en respuesta a comandos específicos. El bot +se parece a un miembro más del cánal, esto es, los comandos se hacen llegar +"hablandole" al bot. Por ejemplo:"</para> + <screen> <kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd <ayita> Thanks! </screen> -<para>That told the bot (who is logged into the channel as ayita) to -remember a certain URL as the answer to the query "diff-cmd". Now we -can address ayita, asking the bot to tell another user about -diff-cmd:</para> +<para>Esto le ha dicho al bot (el cual está en el cánal como ayita) +que recuerde cierto URL como la respuesta a la pregunta "diff-cmd". Ahora +podemos dirigirnos a ayita pidiendole al bot que le diga a otro usuario +acerca de diff-cmd:</para> <screen> <kfogel> ayita: tell jrandom about diff-cmd <ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd </screen> -<para>The same thing can be accomplished via a convenient shorthand:</para> +<para>Lo mismo puede ser logrado con un comando más corto:</para> <screen> <kfogel> !a jrandom diff-cmd <ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd </screen> -<para>The exact command set and behaviors differ from bot to bot. The -above example is with <literal>ayita</literal> -(<ulink url="http://hix.nu/svn-public/alexis/trunk/"/>), of which -there is usually an instance running in <literal>#svn</literal> at -freenode. Other bots include Dancer -(<ulink url="http://dancer.sourceforge.net/"/>) and Supybot -(<ulink url="http://supybot.com/"/>). Note that no special server -privileges are required to run a bot. A bot is a client program; -anyone can set one up and direct it to listen to a particular -server/channel.</para> - -<para>If your channel tends to get the same questions over and over, -I highly recommend setting up a bot. Only a small percentage of -channel users will acquire the expertise needed to manipulate the bot, -but those users will answer a disproportionately high percentage of -questions, because the bot enables them to respond so much more -efficiently.</para> +<para>El conjunto exacto de comandos y conductas difieren entre bots. El +ejemplo anterior utiliza <literal>ayita</literal> +(<ulink url="http://hix.nu/svn-public/alexis/trunk/"/>), del cual +existe una instancia en <literal>#svn</literal> en Freenode. Otros +bots son Dancer +(<ulink url="http://dancer.sourceforge.net/"/>) y Supybot +(<ulink url="http://supybot.com/"/>). No son necesarios privilegios +específicos en el servidor para ejecutar un bot. Un bot es un programa +cliente; cualquiera puede fijar y dirigirlo para que escuche en un +servidor/cánal en particular.</para> + +<para>Si el cánal del proyecto tiende a recibir las mismas preguntas +una y otra vez, recomiendo utilizar un bot. Sólo un pequeño porcentaje +de usuarios del cánal adquiriran la habilidad necesaria para manejar el +bot, pero serán los que sí lo hagan quienes responderán a una cantidad +desproporcionada de preguntas, porque el bot permite que sean respondidas +con mayor eficiencia.</para> </sect2> <sect2 id="irc-archiving"> -<title>Archiving IRC</title> +<title>Archivando IRC</title> -<para>Although it is possible to archive everything that happens in an -IRC channel, it's not necessarily expected. IRC conversations may be -nominally public, but many people think of them as informal, -semi-private conversations. Users may be careless with grammar, and -often express opinions (for example, about other software or other -programmers) that they wouldn't want preserved forever in an online -archive.</para> +<para>Aunque es posible archivar todo lo que sucede en los canales de +IRC, no es algo necesario. Las conversaciones en IRC pueden ser +públicas, por lo que muchas personas piensan en ellas como conversaciones +informales semi-privadas. Los usuarios puede que no cuiden la grámatica +y a veces expresen opiniones (por ejemplo, acerca del software o sobre +otros desarrolladores) que no querran que sean preservadas eternamente +en un archivo en línea.</para> <para>Of course, there will sometimes be <emphasis>excerpts</emphasis> that should be preserved, and that's fine. Most IRC clients can log a @@ -2415,6 +2433,14 @@ make sure you state so clearly in the channel topic, and give a URL to the archive.</para> +<para>Por supuesto que existen <emphasis>extractos</emphasis> que deberian +ser preservados. Muchos de los clientes de IRC pueden registrar conversaciones +a un fichero bajo demanda por el usuario, o si esto falla, se puede +copiar y pegar la conversación del IRC a otro foro permanente +(a menudo, el bug tracker). Pero el registro indiscriminado puede incomodar +a algunos usuarios. Si se archiva todo, hay que declarlo claramente en el +tópico del cánal y proporcionar una URL del archivo.</para> + </sect2> </sect1> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
