Copyright © 2001,2006 Eric S. Raymond, Rick Moen
Thyrsus Enterprises<
esr@thyrsus.com>
Rick Moen
<
respond-auto@linuxmafia.com>
Copyright de la traducción © 2009 por Luis E. Amaya González
<
xattack@lycosmail.com>
| Historial de revisiones |
|---|
| Revisión 3.6 | 19 de Marzo 2008 | esr |
| Actualizaciones menores y nuevos enlaces |
| Revisión 3.5 | 2 de Enero 2008 | esr |
| Correción tipográfica y algunos enlaces de traducciones |
| Revisión 3.4 | 24 de Marzo 2007 | esr |
| Nueva Sección,Cuando preguntan acerca de código |
| Revisión 3.3 | 29 de Septiembre 2006 | esr |
| Introduciendo buenas sugerencias de Kai Niggem Ann |
| Revisión 3.2 | 10 de Enero 2006 | esr |
| Introduciendo ediciones de Rick Moen |
| Revisión 3.1 | 28 de Octubre 2004 | esr |
| Documento 'Google es tu amigo!' |
| Revisión 3.0 | 2 de Febrero 2004 | esr |
| Agregados importantes acerca de la etiqueta apropiada en los foros Web |
Tabla de Contenidos
Traducciones.Avisos.IntroducciónAntes de preguntar.Cuando preguntas.Escoge tu foro cuidadosamente.Los foros Web y los canales IRC dirigidos a los novatos comúnmente dan las respuestas más rápidas.Como un segundo paso, usa las listas de correo de los proyectos.Usa encabezados de asunto claros y específicos.Hagalo fácil de responder.Escriba en lenguaje claro, gramaticalmente correcto y con buena dicción.Envie preguntas en formatos accesibles y estandarizados.Sea preciso e informativo acerca de su pregunta.Volumen no es precisión.No corra a declarar que ha encontrado un bug.Arrastrarse no es un substituto de hacer su tarea.Describe los sintomas de tu problema, no tus suposiciones.Describe los sintomas de tu problema en orden cronológico.Describe el objetivo, no los pasos.No le pidas a la gente que te responda con su correo particular.Se explícito con tus preguntas.Cuando preguntes acerca del código.No publiques preguntas de tu tarea.Evita preguntas injustificadas.No titules tus preguntas como "urgente", incluso si lo es para ti.La cortesía no daña, y algunas veces ayuda.Seguimiento de la solución con una nota breve.Cómo interpretar las respuestas.RTFM y STFW: Cómo decirte que la has cagado de verdad ...Si no entiendes ...Tratando con la descortesía.Sobre cómo no reaccionar como un perdedor.Preguntas que no deben hacerse.Buenas y malas preguntas.Si no puedes obtener una respuesta.Cómo responder preguntas de manera útil.Recursos relacionados.Agradecimientos.Traducciones
Traducciones Indonesio Portugués-Br Chino Checo Danés Holandés Estonio Finés Francés Georgiano Alemán Griego Hebreo Húngaro Italiano Japonés Mongol Polaco Portugués Rumano Ruso Serbio Español-Es Sueco Tailandés Turco Sí tu quieres copiar, duplicar, traducir o tomar un fragmento de este documento, por favor lee política de copiado.
Avisos
Muchos sitios de proyectos hacen un enlace a este documento en sus secciones de como obtener ayuda. Eso esta bien, es el uso que planeamos, pero si tu eres un webmaster creando tal enlace para tu página de proyecto , por favor exhibe claramente cerca de tu enlace un aviso que diga no somos un servicio soporte técnico para tu proyecto!
Hemos aprendido por el camino duro que sin tal aviso, seremos molestados repetidamente por idiotas que piensan que por haber publicado este documento nos hace responsables de resolver todos los problemas técnicos de todo el mundo.
Si estas leyendo este documento porque necesitas ayuda, y te vas con la impresión de que puedes obtener ayuda directa de los autores de este documento, tú eres uno de los idiotas a los que nos referimos. No nos formules preguntas. Te vamos a ignorar. Estamos aquí para mostrarte como obtener ayuda de gente que sabe del software y hardware con el que te estas relacionando, pero el 99.9% del tiempo no seremos nosotros. A menos de que sepas certeramente que uno de los autores es un experto con lo que estas lidiando, dejanos en paz y todos estaremos contentos.
Introducción
En el mundo de los hackers, el tipo de respuestas que obtienes a tus preguntas técnicas dependerá mucho en la forma en que hagas tus preguntas así como en la dificultad para desarrollar la respuesta. Esta guía te enseñará cómo formular preguntas de tal manera que se puedan obtener respuestas satisfactorias.
Ahora que el uso del software abierto se ha generalizado, podrás obtener usualmente buenas respuestas de usuarios más experimentados como de los hackers. Esto es bueno;los usuarios tienden a ser un poco más tolerantes con el tipo de problemas que los novatos suelen tener. Aún así, tratar a los usuarios experimentados como a los hackers, en la forma que recomendamos aquí será generalmente la vía más efectiva para obtener respuestas útiles de ellos también.
La primer cosa que hay que entender es que a los hackers les gustan los problemas realmente complejos y las buenas preguntas que les provoquen pensar en esos problemas. Si no fuera así, no estaríamos aquí. Si nos dan preguntas interesantes para trabajar en ellas te los agradeceremos; las buenas preguntas son un estímulo y un obsequio. Las buenas preguntas nos ayudan a desarrollar nuestro entendimiento,y comúnmente exhiben problemas que no hubiéramos notado o pensado de otra manera. Entre los hackers, una expresión como “Buena pregunta!” es un sincero y claro cumplido.
A pesar de esto, los hackers tienen la reputación de reaccionar a las preguntas sencillas con algo que parece hostilidad y arrogancia. Algunas veces parece como si fuéramos hóstiles con los novatos y los ignorantes. Pero esto no es necesariamente cierto.
Lo que somos, sin disculparme por ello es ser hóstiles con las personas que parecen negarse a pensar o hacer su propio trabajo antes de hacer preguntas. Gente como esa son gastadores de tiempo —toman sin dar nada a cambio, y desperdician tiempo que pudimos haber empleado en otra pregunta más interesante y con otra persona más merecedora de una respuesta. Llamamos a gente como esta “perdedores” [losers](y por razones históricas a veces lo decimos “lusers” *juego de palabras que se forma con las palabras loser=perdedor y user=usuario **nota del trad. ).
Somos concientes que mucha gente solo quiere usar el software que escribimos, y que no tiene interés algunos en aprender los detalles técnicos. Para la mayoría de la gente, la computadora es únicamente una herramienta, un medio para un fín, ellos tienen cosas más interesantes que hacer y vidas que vivir. Reconocemos eso, y no esperamos que todos tengan interés en las cosas técnicas que nos fascinan. De cualquier manera, nuestro estilo de responder preguntas se modela por las personas que sí tienen tal interés y que quieren ser participantes activos en la solución de problemas. Eso no va a cambiar. No debería, si lo hiciera, nos volveríamos menos efectivos en las cosas que hacemos mejor.
Hemos sido (por mucho tiempo) voluntarios. Tomamos tiempo de nuestras atareadas vidas para responder preguntas, y a veces nos vemos sobrepasados por ellas. Así que las filtramos sin piedad. Particularmente desechamos esas preguntas de personas que parecen ser perdedores, para emplear nuestro tiempo de preguntas-respuestas más eficientemente en ganadores.
Si encuentras esta actitud desagradable, condescendiente o arrogante, revisa tus presuposiciones. No te estamos pidiendo que nos trates con deferencia, de hecho, la mayoría de nosotros queremos más que otra cosa relacionarnos contigo en igualdad y de bienvenida en nuestra cultura. Pero simplemente no es eficiente para nosotros tratar de ayudar gente que no esta dispuesta a ayudarse a sí misma. Esta bien ser ignorante, no lo es jugarle al pendejo.
Así, mientras no es necesario ser técnicamente competente para obtener nuestra atención, es necesario demostrar el tipo de actitud que conduce a la competencia –estar alerta, atento, pensativo, deseoso de ser un participante activo en el desarrollo de una solución. Si no puedes vivir con este tipo de discriminación, te sugerimos que le pagues a alguien para que te de un contrato de soporte técnico en vez de preguntarle a hackers que personalmente te donen ayuda a ti.
Si tu decides acercarte a nosotros por ayuda, tu no querrás ser uno de los perdedores. Tu no querrás parecer uno de ellos tampoco. El mejor camino para obtener una rápida y coherente respuesta es preguntarle a personas con inteligencia, certidumbre y con pistas que acaben de pasar que se requieran para ayudarle en el problema de uno.
(Mejoras a esta guía son bienvenidas. Pueden enviar sugerencias por correo electrónico a esr@thyrsus.com o respond-auto@linuxmafia.com· Note que este documento no intenta ser una guía general de netiqueta, y que excluiremos sugerencias que no estén específicamente relacionadas para generar preguntas útiles en un foro técnico.)
Antes de preguntar
Antes de preguntar una duda técnica por correo electrónico, o en un grupo de noticias,o en un chat, haga lo siguiente:
- Trate de hallar una respuesta buscando en los archivos históricos del foro donde planee publicar.
- Trate de hallar una respuesta buscando en la Web.
- Trate de hallar una respuesta leyendo el manual.
- Trate de hallar una respuesta leyendo las FAQs.
- Trate de hallar una respuesta por inspección o por experimentación.
- Trate de hallar una respuesta preguntándole a un amigo más experimentado.
- Si eres un programador,trata de hallar la respuesta leyendo el código fuente.
Cuando formules tú pregunta, muestra que has realizado estas cosas; ayudará a establecer que no eres una esponja ociosa y que no estas desperdiciando el tiempo valioso de otros. Aún mejor, muestra lo que hayas aprendido haciendo esas cosas. Nos gustan las preguntas de gente que ha demostrado que puede aprender de las respuestas.
Use tácticas como realizar una búsqueda en Google en el texto o cualquier cosa que sea el mensaje de error que hayas obtenido ( búsquedas en los grupos de google así como en paginas web). Esto podría llevarte directamente a documentación de ayuda o entradas a listas de correo en donde se haya respondido tu pregunta. Incluso si no es así, digamos “busque la siguiente frase pero no encontré nada que fuera útil” es algo bueno que hacer en las solicitudes de ayuda de las listas de correo o grupos de noticias, si lo que buscamos en sus históricos no nos ayuda. Esto también ayudará a otras personas con problemas similares a los de tu entrada al vincular sus términos de búsqueda con lo que esperanzadoramente fue la entrada de problema original y su solución.
Tomate tu tiempo. No esperes ser capaz de resolver problemas complicados con solo un rato de búsqueda en Google. Lee y entiende las FAQs, sientate, relajate y piensa un rato en el problema antes de acercarte a los expertos. Confía en nosotros, serán capaces de decir desde tus preguntas que tanto has leído y pensado, y serán más capaces de ayudarte si llegas preparado. No dispares todo tu arsenal de preguntas solo porque tu primera búsqueda se mostró sin respuestas (o no muchas).
Prepara tus preguntas. Piensalas. Las preguntas precipitadas recibirán respuestas precipitadas, o ninguna en absoluto. Cuanto más que hagas para demostrar que has puesto empeño y esfuerzo en resolver tu problema antes de buscar ayuda , sera más probable que obtengas ayuda.
Cuidate de hacer la pregunta incorrecta. Si haces una que este basada en suposiciones equivocadas, J. Random Hacker la responderá con una respuesta literalmente inútil mientras piensa “estúpida pregunta ...”, y esperando que la experiencia de obtener lo que preguntaste en vez de lo que necesitas te enseñe una lección.
Nunca asuma que tienes derecho a una respuesta. No lo tienes, no estas , después de todo, pagando por un servicio. Te vas a ganar una respuesta, si te la ganas, al preguntar una substancial, interesante y pensadoramente provocadora pregunta ---una que implícitamente contribuya a la comunidad experimentada en vez de solamente demandar pasivamente conocimiento de otros.
De otra manera, hacer claro que eres capaz y tienes la voluntad de ayudar en el proceso de desarrollar la solución es un buen comienzo. “¿Podría alguien darme alguna pista?”, “¿Qué es lo que le falta a mi ejemplo?”, y “¿Qué sitios debería haber revisado?” son más probables de obtener una respuesta que “Por favor publiquen el procedimiento exacto que debería usar” porque estas claramente estableciendo que verdaderamente tienes la voluntad de completar el proceso si solo alguien te pone en la dirección correcta.
Cuando preguntesEscoge cuidadosamente tu foro
Se sensible al escoger donde formulas tu pregunta. Podrías ser ignorado, o señalado como un perdedor, si tú:
publicas tu pregunta en un foro que sea ajeno al tema
publicas una pregunta muy elemental en un foro se esperan preguntas técnicas avanzadas, o viceversa.
Haces publicaciones entrecruzadas a muchos grupos de noticias diferentes
envias un correo personal a alguien que es no es conocido tuyo ni es responsable personalmente de resolver tu problema.
Los hackers mandan a volar las preguntas que son inapropiadamente dirigidas en orden de proteger sus canales de comunicación de que sean inundados por mensajes irrelevantes. No quieres que esto te pase a ti.
El primer paso, es hallar el foro correcto. Nuevamente, Google y otros métodos de búsquedas web son tus amigos. Usalos para hallar la pagina web de proyecto más cercanamente asociado con el hardware o software que te está dando dificultades. Usualmente tendrá ligas a las listas de las FAQs (Frequently Asked Questions), y a las listas de correo del proyecto y a sus archivos. Estas listas de correo son los lugares finales para ir por ayuda, si tus propios esfuerzos (incluyendo leer esas FAQs que encontraste) no encuentran una solución . La página de proyecto también podría describir un procedimiento para reportar errores, o tener una liga a uno; si es así, sigalo.
Mandar un correo a un foro o una persona con la que no estés familiarizado es arriesgarse en el mejor de los casos. Por ejemplo, no asumas que el autor de una página informativa quiere ser tu asesor sin sueldo. No hagas pronósticos optimistas acerca de como será recibida tu pregunta — si no estas seguro, mandalo a cualquier otro lado o abstente de mandarlo del todo.
Cuando selecciones un foro web, grupo de noticias o lista de correo, no confíes en el nombre por sí mismo, busca las FAQs para verificar que tu pregunta esta dentro de sus temas. Lee algo del tráfico anterior antes de publicar así tendrás un sentimiento de como se hacen las cosas en ese lugar. De hecho, es una buena idea hacer una búsqueda de palabras clave relacionadas a tu problema en un los archivos de grupos de ayuda o de las listas de correo antes de publicar tu pregunta. Podrías hallar tu pregunta, y si no te ayudará a formular una mejor pregunta.
No dispares a todos los canales de ayuda de una vez, eso es como gritonear e irrita a las personas. Camina dentro de ellos suavemente.
¡Averigua de que se trata tu tema! Una de los errores clásicos es preguntar acerca de la programación de interfaces en Unix o Windows en un foro dedicado a un lenguaje de programación o una biblioteca de programación o de alguna herramienta portable entre ambos. Si no entiendes porque esto es una equivocación, sería mejor que no preguntes nada hasta que lo entiendas.
En general, las preguntas a un foro público bien seleccionado serán más propensas a recibir respuestas útiles que las preguntas equivalentes a un particular. Hay muchas razones para esto. Una es simplemente la cantidad de potenciales usuarios que respondan. Otra es la cantidad de audiencia; los hackers prefieren responder preguntas que eduquen a muchas personas que preguntas que sólo sirven a unos pocos.
Comprensiblemente, los hackers más hábiles y los autores de software popular están recibiendo más que solo su cuota de mensajes equívocos. Adicionalmente al flujo, en algunos casos extremos podrías ser la gota que derrame el vaso --- algunas veces, los contribuyentes de proyectos populares han cancelado su soporte por el daño colateral recibido en forma de tráfico de correos electrónicos inútiles a sus cuentas personales se hizo insoportable.
Los foros Web y los canales IRC dirigidos a los novatos comúnmente dan las respuestas más rápidas
Los grupos de usuarios locales, o las distribuciones Linux avisan de foros Web o canales IRC donde los novatos pueden obtener ayuda.(En la mayoría de los países los foros para novatos aún son del tipo de listas de correo. ) Estos son los mejores lugares para preguntar, especialmente si piensas que te estas enfrentando a un problema relativamente simple o común. Un canal de IRC anunciado es una invitación abierta a formular preguntas y usualmente obtener respuestas en tiempo real.
De hecho, si obtuviste un programa que te esta dando problemas en una distribución Linux (como es común hoy en día), lo mejor es preguntar en el foro/lista de correo del la distro en cuestión antes de intentar el foro/lista de correo del programa en sí. Los hackers del proyecto simplemente dirán, “usa nuestro ejecutable”.
Antes de publicar en cualquier foro Web, verifica si tiene implementado un motor de búsqueda. Si lo tiene, intenta un par de búsquedas con palabras clave con algo relacionado con tu problema; podría ayudarte. Si realizaste una búsqueda Web general antes (como deberías haberlo hecho), busca de todas maneras en el foro; tu motor de búsquedas preferido podría no tener todo lo de este foro indexado recientemente.
Hay una tendencia creciente en los proyectos de proveer soporte a los usuarios en foros Web o en un canal de IRC, con listas de correo más reservadas para el tráfico de los desarrolladores. Así que por principio busca esos canales cuando busques ayuda de un proyecto en específico.
Como un segundo paso, use las listas de correo de los proyectos
Cuando un proyecto tiene una lista de correo para los desarrolladores, escribe a la lista de correo, no a los desarrolladores individualmente, incluso si crees saber quien podría responder de mejor manera a tu pregunta. Lee la documentación del proyecto su página principal oficial para conocer la dirección de la lista de correo del proyecto, y usala. Hay muchas buenas razones para esta política:
Cualquier pregunta lo suficientemente buena para ser formulada a un desarrollador será también valiosa para todo el grupo. Es sentido contrario, si sospechas que tu pregunta es muy tonta para la lista de correo, no es excusa para hostigar a los desarrolladores individualmente.
Hacer preguntas en las listas de correo distribuye la carga de trabajo entre los desarrolladores. El desarrollador individual (especialmente si él es el líder del proyecto ) podría estar muy ocupado para responder a tus preguntas.
La mayoría de las listas de correo son archivadas y estos archivos son indexados por los motores de búsqueda Si formulas una pregunta en las listas y esta es respondida, un futuro solicitante podr&iacuet;a hallar tu pregunta y la respuesta en la Web en vez de volver a preguntar.
Ciertas preguntas son formuladas regularmente,los desarrolladores pueden usar la información para mejorar la documentación o el software en sí para ser menos confuso. Pero si esas preguntas se realizan de manera particular, nadie tendrá la visión completa de cuáles preguntas son formuladas comúnmente.
Sí el proyecto tienen ambas listas de correo , para “usuarios” y para “desarrolladores” (o “hackers”) o un foro Web, y tu no andas trabajando sobre el código, pregunta en la lista/foro para “usuarios”. No asumas que tendrás buena recepción el la lista de desarrolladores, donde ellos experimentarán tus preguntas como ruido interrumpiendo su tráfico de desarrolladores.
Aún así, si esta completamente seguro de que tu pregunta no es trivial, y no obtienes ninguna respuesta en las listas o el foro para usuarios por varios días, intentalo en las de los “desarrolladores”. Seras bien advertido de estar al acecho por algunos días antes de poder publicar para aprender los manejos locales (de hecho este es un buen consejo para cualquier lista privada o semi-privada).
Si no puedes hallar ninguna lista de correo, pero solo ves la dirección del encargado del proyecto, adelante, escribele a él. Pero aún en ese caso, no asumas que la lista de correo no existe. Menciona en tu correo electrónico que intentaste hallar la lista de correo adecuado pero que no la encontraste. También menciona que no objetarás el que tu correo sea redirigido a otra persona. (Mucha gente cree que la correspondencia particular debe permanecer privada, incluso si no hay nada de secreto en ella. Al permitir que la correspondencia pueda ser redirigida a terceros se le da al receptor la opción acerca de cómo manejar tu correo electrónico.)
Usa encabezados de asuntos claros y específicos.
En las listas de correo, los grupos de usuarios o los foros Web, los encabezados son tu oportunidad dorada para atraer la atención de expertos calificados en cerca de 50 caracteres o menos. No la desperdicies en balbuceos como “Por favor ayudenme” (deja en paz “POR FAVOR AYUDENME!!!!”; mensajes con encabezados como este son descartados por simple reflejo.) No trates de impresionarnos con lo profundo de tu angustia; en vez de eso usa el espacio para un descripción súper concisa.
Una buena convención para los temas de encabezado, usada por muchas organizaciones de soporte técnico, es la descripción en forma “objeto-desviación”. Donde la parte del “objeto” especifica que cosas o grupo de cosas esta teniendo problemas, y la parte de la “desviación” describe la desviación del comportamiento esperado o especificado.
Estúpido:
AYUDA! El vídeo no trabaja correctamente en mi laptop!
Inteligente:
X.org 6.8.1 desaparece el puntero del ratón esta jodido, chipset de vídeo Fooware MV1005
más inteligente:
El cursor del ratón en X.org 6.8.1 con el chipset de vídeo Fooware MV1005 -se jode
El proceso de escribir una descripción del tipo “objeto-desviación” te ayudará a organizar tu pensamiento acerca del problema de manera más detallada. ¿Qué es lo que se afecta, solo el cursor del ratón o también los gráficos?, ¿Es esto específico de la versión de X.org del servidor X?, ¿De la versión 6.8.1?, ¿Es específico del chipset de vídeo Foooware ?, ¿Del modelo MV1005?. Un hacker que observe el resultado puede inmediatamente entender qué es lo que te esta dando problemas y el problema que estas teniendo, de una sola mirada.
Imagínate buscando en el índice de los archivos de preguntas, con solo las líneas del encabezado de tema mostrándose. Haz que tu encabezado de tema refleje tu pregunta tan bien que el próximo que busque en el archivo con una pregunta similar a la tuya sea capaz de seguir la entrada a la respuesta en vez de publicar la pregunta nuevamente.
Si haces una pregunta en una respuesta de entrada anterior, asegurate de cambiar el título de encabezado para mostrar que estas haciendo una pregunta. Una línea de encabezado que se veo como “Re:test” o “Re:nuevo bug” es menos capaz de atraer atención útil. Además, evita la cita de mensajes anteriores al mínimo con la idea de enterar a los nuevos lectores de la entrada.
No te metas simplemente en un mensaje de respuesta de la lista para comenzar una nueva entrada. Eso limitar&aaacute; tu audiencia probable. Algunos clientes de correo, como mutt, permiten al usuario ordenar las entradas y entonces esconden los mensajes de una entrada al ordenarlos dentro de la entrada. La gente que hace eso nunca leerá tu mensaje.
Cambiar el tema del encabezado no es suficiente. Mutt, y probablemente otros clientes de correo, buscan otra información en los encabezados de correo electrónico para asignarlos a una entrada, no la línea de encabezado. En vez de eso comienza un nuevo correo electrónico.
En los foros Web las reglas de buenas prácticas son un poco diferentes, porque los mensajes son comúnmente muy cercanos a los límites de ciertas entradas de discusión específicas y usualmente son invisibles fuera de esas entradas. Cambiarle el tema de encabezado cuando preguntes dentro de una respuesta no es esencial. No todos los foros permiten separar las líneas de tema de las réplicas, y casi nadie las lee cuando lo hacen. Como sea, formular preguntas en una réplica es una práctica de dudosa &uacyte;tilidad por sí misma, porque solo será vista por aquellos que estén buscando esa entrada. Así, a menos que estés seguro que quieres preguntar solo a los participantes activos de esa entrada, empieza una nueva.
Hazlo fácil de responder.
Terminar tu solicitud de ayuda con "Por favor envíe su respuesta a ..." la hará incapaz de obtener una respuesta. Si no te tomas la molestia de tomarte unos pocos segundos para escribir una correcta línea de respuesta-a en el encabezado de tu cliente de correo, no nos tomaremos la molestia de tomarnos unos segundos para pensar en tu problema. Si tu programa de correo no permite esto, obtene un mejor programa de correo. Si tu sistema operativo no permite ningún programa de correo electrónico que permita esto, obten un mejor sistema operativo.
En los foros Web, preguntar por una respuesta anterior por correo es bastante rudo, a menos de que creas que la información es sensible (y que alguien podrá, por alguna desconocida razón, hacértelo saber pero no lo sabe el foro completo). Sí quieres una copia de un correo electrónico cuando alguien respondió en una entrada, solicita que el foro Web la envié; esta opción se permite casi en cualquier lugar bajo las opciones como “observar esta entrada”,”enviar correo de las respuestas”, etc.
Escriba en lenguaje claro, gramaticalmente correcto y con dicción correcta.
Hallamos por experiencia que la gente que escribe sin cuidado y torpemente son descuidados y torpes al pensar y programar ( o lo suficiente como para apostarle a eso,de cualquier manera). Dar respuestas a descuidados y torpes no es estimulante; preferimos emplear nuestro tiempo donde sea.
Expresar tus preguntas claramente y bien es importante. Si no te tomas la molestia de hacerlo, no podremos tomarnos la molestia de prestarte atención. Emplea un esfuerzo adicional para pulir tu lenguaje. No tiene que ser rigido o formal – de hecho, la cultura hacker valora el lenguaje informal, coloquial y humorístico usado con precisión. Pero tiene que ser preciso; tiene que haber indicios de que estas pensando y prestando atención.
Vocaliza, puntualiza y utiliza las mayúsculas correctamente. No confundas “que” con “q' ”, “haya ” con “ alla”, o “es que ” con “ s k”. No ESCRIBAS TODO EN MAYÚSCULAS; esto se interpreta como estar gritando y es considerado una rudeza. ( todo en minúsculas es levemente menos complicada, mientras que es difícil de leer.Alan Cox puede salirse con la suya tu no.)
Es más, si escribes como un tipo semi-letrado es muy posible que seas ignorado. No uses las contracciones de la mensajería instantánea. Escribir “que” como “k” te hará parecer semi-letrado y todo por ahorrarte unos golpes de teclado. Peor aún: escribir como un hax0r script kiddie de l33t será el total y absoluto beso de la muerte y te asegurará no recibir nada salvo un silencio pétreo (o , en el mejor de los casos, una ayuda sarcástica y punzante ) de vuelta.
Si haces preguntas en un foro donde no usan tu lenguaje materno/nativo, recibirás una cantidad limitada de mofas por tú incorrecta ortografía y errores gramaticales – pero no burlas por haraganería (y sí, podemos notar la diferencia). También, a menos que sepas que lenguaje es el de los usuarios que responden, escribe en inglés. Los hackers muy ocupados tienden a simplemente desechar las preguntas escritas en idiomas que no entienden, y el inglés es el lenguaje que sirve en la Internet. Escribiendo en inglés minimizas las oportunidades de que tu pregunta sea descartada sin leerla.
Envie preguntas en formatos accesibles y estandarizados.
Si haces tus preguntas artificialmente difíciles de leer, será mas sencillo que sea relegada en favor de otra que no lo sea:
Envia el correo en texto plano, no en HTML. (No es difícil desactivar el HTML.)
Los adjuntos MIME generalmente están bien, pero solamente si tienen contenido real (como un parche o un código fuente), y no simplemente basura generada por tu cliente de correo (tal como otra copia generada de tu propio mensaje).
No envíes correo electrónico en donde cada párrafo sean lineas individuales juntas. (Esto hace que sea muy difícil de responder solo a parte de ese mensaje.) Asuma que sus respondientes van a leer correo en un texto que se mostrará de 80 caracteres de ancho y configura tu cliente para que junte las líneas en eso , algo menos que 80.
De cualquier manera no pegues información (tal como salidas de bitácoras o transcripciones de sesiones) en cualquier ancho fijo de columna. La información debe ser incluida cómo esta, así los replicadores podrán tener la confianza de que están viendo lo que tú viste.
No envíes mensajes codificados como MIME Quoted-Printable a un foro que use idioma inglés nativamente. Esta codificación puede ser necesaria cuando estas publicando en un lenguaje que el ASCII no cubre, pero muchos clientes de correo no lo soportan. Cuando se corrompe, todos esos glifos =20 se esparcen a través del texto y son distractores horribles — o podría sabotear activamente la semántica de tú texto.
Nunca, jamás esperes que los hackers sean capaces de leer formatos de documentos cerrados propietarios como Microsoft Word o Excel. La mayoría de los hackers reacciona a estos así como si tuvieras una pila de desperdicio de cerdo apilado en tu puerta. Incluso si ellos tuvieran que hacerlo, se resentirán de tener que hacerlo.
- Si estas enviando correo electrónico desde una máquina Windows, desactiva la estúpida utilidad de Microsoft “Smart Quotes”. Esto es para que evites esparcir caracteres basura en tu correo electrónico.
En los foros Web, no abuses de los “emoticons” y de las utilidades “HTML” (cuando estén presentes). Un emoticon o dos est&aaacute;n bien generalmente, pero el texto coloreado hará que la gente piense que eres un idiota. Abusar del uso de los emoticons, del color y las tipografías hará que salgas como una adolescente risueña, lo que generalmente no será una buena idea a menos que estés más interesado/a en el sexo que en las respuestas.
Si estas usando un cliente de correo con interfaz gráfica tal como el Messenger de Netscape, MS Outlook, o cualquier clon parecido, ten cuidado, podrías estar violando estas reglas al usarlos con sus configuraciones por defecto. La mayoría de estos clientes tienen comandos basados en menús para “Ver el documento” . Usalo en algo en tu folder de correo enviado, verifica que envías texto plano sin agregados innecesarios.
Sé preciso e informativo acerca de tú problema.
Describe los síntomas de tu problema o error clara y cuidadosamente.
Describe el ambiente en el cuál ocurrió (máquina, SO, aplicación, etc). Provee al generador de la distribución y versión (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
Describe la investigación que realizaste para intentar entender el problema antes de formular la pregunta.
Describe los pasos que llevaste a cabo para intentar resolver el problema por ti mismo antes de formular la pregunta.
Describe cualquier cambio reciente relevante posible en tu computadora o configuración de software.
Si te es posible después de todo , provee una vía para reproducir el problema en una ambiente controlado.
Haz tu mejor esfuerzo para anticiparte a las preguntas que un hacker te hará , y respondelas de antemano en tu solicitud de ayuda.
Dándole a los hackers la posibilidad de reproducir tú problema en un ambiente controlado es especialmente importante si estás reportando algo que piensas que es un bug en el código. Cuando haces esto, tus posibilidades de obtener una respuesta útil y la velocidad con la que esperas obtener una respuesta se incrementan tremendamente.
Simón Tatham escribió un excelente ensayo intitulado Cómo Reportar Bugs Efectivamente. Realmente te recomiendo que lo leas.
Volumen no es precisión.
Necesitas ser preciso e informativo. Este fin no se cumple simplemente exhibiendo grandes cantidades de código o información en una solicitud de ayuda. Sí tienes un caso de estudio grande y complicado que está rompiendo un programa, trata de dividirlo y hacerlo tan pequeño como te sea posible.
Esto es útil al menos por tres razones. Primera: ser visto capaz de invertir esfuerzo en una cuestión hará que seas capaz o merecedor de obtener una respuesta, Segundo: simplificar la cuestión hará que seas capaz o merecedor de obtener una respuesta útil. Tercero: en el proceso de refinar tú reporte de error, podrías desarrollar una solución o un camino alterno al mismo.
No corras a declarar que has encontrado un bug.
Cuando estas teniendo problemas con una pieza de software, no declares que has encontrado un bug a menos que estés muy, muy seguro de tus bases. Consejo: a menos que puedas proveer un parche para el código fuente que solucione el problema, o una prueba contra una versión que demuestre un comportamiento erróneo, probablemente no estarás completamente seguro. Esto se aplica a las páginas Web y a la documentación, también; Sí has encontrado un “error” en la documentación, deberás proveer el texto de reemplazo y en cuales páginas este deberá ir.
Recuerda, hay muchos más usuarios que no estarán experimentando tú problema. De otra manera habrías aprendido de este problema cuando leíste la documentación y cuando buscaste en la Web (hiciste eso antes de quejarte, ¿verdad?). Esto significa que es muy probable que eres tú quien está haciendo algo mal, no el software.
La gente que escribió el software trabajó muy duro para hacerlo trabajar lo mejor posible. Si tú declaras haber encontrado un error, estarás impugnando su competencia, lo cuál podría ofender a alguno de ellos incluso si estas en lo correcto. Es especialmente falto de tacto gritar “bug” en la línea de encabezado.
Cuando formules tu pregunta, es mejor escribir pensando en que asumes que tú estas haciendo algo mal, incluso cuando estas en lo particular muy seguro de que has encontrado un error. Si realmente fuera un error, escucharas de él en la respuesta. Hacerlo de esta manera hará que los encargados quieran disculparse contigo si el error es real, en vez de que les debas una disculpa si la has batido.
Arrastrarse no es un substituto de hacer su tarea.
Algunas personas que entienden que no se deben comportar ruda o arrogantemente, al demandar una respuesta, se vuelcan al extremo opuesto, se arrastran. Cosas como “Se que soy simplemente un novato patético y perdedor, pero ...” es distractor y es inútil. Es especialmente molesto cuando va acompañado de vaguedades acerca del problema.
No pierdas tú tiempo, o el nuestro, con diplomacia tosca y primitiva. En vez de eso, presenta los hechos que antecedieron a tus preguntas tan claramente como puedas. Este es el mejor camino para posicionarte en vez de arrastrarse.
Algunas veces los foros Web tienen sitios separados para preguntas de novatos. Sí sientes que tienes una pregunta de novato, simplemente dirigete hacia allí. Pero tampoco te arrastres ahí.
Describe los sintomas de tu problema, no lo que te imagines.
No es útil decirle a los hackers que es lo que piensas que causa tu problema. (Si tus diagnósticos teóricos fueran tan esclarecedores, ¿Estarías consultando a otros para solicitar ayuda?) Entonces, asegurate de que estas mencionando los síntomas crudos de lo que esta mal, en vez de tus interpretaciones y teorías. Dejalos hacer las interpretaciones y los diagnósticos. Si crees que es importante mencionar lo que imaginas, nombralo claramente como eso y describe porque la respuesta no esta funcionando para ti.
Estúpido:
Estoy de vuelta a los errores en la compilació.n del kernel de la SIG11,y sospecho una fisura en las pistas de mi tarjeta madre.¿Cuál es el mejor camino para verificar esto?
Inteligente:
Mi máquina ensamblada K6/233 con una tarjeta madre FIC-PA2007 (chipset VIA Apollo VP2 ) con 256MB de memoria Corsair PC133 SDRAM comenzó a tener errores frecuentes SIG11 cerca de 20 minutos después de encenderla cuando se compilaba el kernel , pero nunca en los primeros 20 minutos. Rebootearla no reinicia el reloj, pero apagarla si lo hace . Intercambiarle la RAM tampoco ayuda. La información relevante de la bitácora de una típica sesión de compilación viene a continuación.
Desde el punto precedente se ve como uno para pensar para muchos, aquí hay una frase par recordarte: “Todos los técnicos son de Missouri”. La divisa oficial de los EUA es “Muestrame” (ganada en 1899, cuando el congresista Willard D. Vandiver dijo “Vengo de un país que cosecha algodón y maíz y cardos y demócratas, y la elocuencia espumosa ni me convence ni me satisface. Yo soy de Missouri. Tienen que mostrarme.”) En el caso de los técnicos, no es una cuestión de escepticismo, tanto como la necesidad funcional, literalmente hablando, de verificar lo que sea más cercano posible a la misma evidencia cruda que tú ves, en vez de tus resúmenes y conjeturas. Muestranos.
Describe los síntomas de tu problema en orden cronológico
Las claves más útiles para saber que algo que va mal comúnmente descansan en los eventos inmediatamente anteriores. Así que debes describir lo más preciso posible que hiciste, y que hizo la máquina y el software, de tal manera que nos conduzca al desastre. En el caso de los procesos de la línea de comandos, tener una bitácora de la sesión (e.g. usando utilidades de script) y mencionando las veinte líneas más relevantes es muy útil.
Si el programa en cuestión tiene opciones de diagnóstico (tales como -v para verboso), intenta seleccionar las opciones que agregaran información de ubicación y reporte de errores a la transcripción. Recuerda que es más no es necesariamente mejor; intenta seleccionar un nivel de reporte que debug informe en vez de llevar al lector al hastío.
Si tu caso expuesto termina siendo largo (más de cuatro párrafos), podría ser útil establecer de manera breve el problema al inicio, después con la historia cronológica. De esa manera, los hackers sabrán que mirar cuando lean de tú caso.
Describe el objetivo, no los pasos.
Si estas intentando averiguar como hacer algo (al contrario de reportar un error), empieza por describir el objetivo. Sólo después describe los pasos en particular acerca del mismo en los que estás bloqueado.
Comúnmente, la gente que necesita ayuda técnica tiene un objetivo alto en mente y se atora en lo que ellos creen es un camino particular acerca del objetivo. Vienen por ayuda con el paso realizado, pero no se dan cuenta de que la ruta es incorrecta. Puede tomar un considerable esfuerzo superar esto.
Estúpido:
¿Cómo obtengo el tomador de colores en el programa FooDraw para tomar un valor hexadecimal RGB?
Inteligente:
Estoy tratando de reemplazar la tabla de colores en una imagen con valores de mi elección. En este momento la única vía que contemplo para hacer esto es editar cada valor de la tabla, pero no puedo hacer que el tomador de colores de FooDraw tome valores hexadecimales RGB.
La segunda versión de la pregunta es inteligente. Permite una respuesta que sugiera una herramienta mejor preparada para la tarea.
No le pidas a la gente que responda con su correo particular.
Los hackers creen que resolver problemas debería ser un proceso público, transparente durante el cuál en un primer intento de una respuesta podría y debería ser corregida si alguien con más conocimiento nota que esta incompleta o incorrecta. Además, los auxiliares obtienen algo de su recompensa de ser contestatarios al ser vistos como competentes y conocedores por sus pares.
Cuando pides una respuesta privada, estas rompiendo con ambos hechos, el proceso y la recompensa. No lo hagas. Es la opción de quien responde como responder, en privado — y si lo hace, usualmente es porque piensa que la pregunta esta mal planteada o es obvia para ser del interés de los demás.
Hay una excepción limitada a esta regla. Si piensas que la pregunta es tal que obtendrás respuestas muy similares, entonces las palabras mágicas son “mandenme un correo y juntare las respuestas para el grupo”. Es cortes intentar y salvar a la lista de correos o al grupo de noticias de un flujo de publicaciones idénticas — pero deberás de sostener y cumplir la promesa de reunirlas.
Se explícito con tus preguntas.
Las preguntas que terminan muy abiertas tienden a ser percibidas como consumidoras de tiempo. Las personas que más probablemente te podrían auxiliar dándote una respuesta útil son también las más atareadas(porque son los que toman más trabajo para sí mismos). Gente como esa son alérgicas a los consumidores de tiempo, por lo tanto tienden a ser alérgicos a las preguntas que son muy abiertas.
Serás mas propenso a recibir respuestas útiles si eres explícito acerca de los que quieres que los contestatarios hagan (provee orientaciones, envía código, verifica tu parche, lo que sea). Esto centrara el esfuerzo e implícitamente agregará una ayuda en el tiempo y esfuerzo que los contestatarios deberán poner para ayudarte. Esto es bueno.
Para entender el mundo en que los expertos viven, piensa en la experiencia como un recurso abundante y el tiempo de respuesta como uno escaso. El menor tiempo de compromiso que solicites, será más probable que obtengas una respuesta de alguien verdaderamente bueno y realmente ocupado.
Así que es útil limitar tú pregunta para minimizar el tiempo de compromiso requerido para que trabaje en él un experto –pero usualmente no es lo mismo que simplificar la pregunta. Por ejemplo, “¿Podrías darme una orientación para una buena explicación de X?” es comúnmente una pregunta más inteligente que “¿Podrías explicar X?”. Si tienes código con errores, es usualmente más inteligente preguntarle a alguien que nos explique qué es lo que está mal con él que pedirle que lo arregle.
Cuando preguntes acerca de código.
No le pidas a otros que revisen tu código fallido sin dar ayudas acerca de que problema deberían estar buscando. Publicar unos cuantos cientos de líneas de código, para decir "no funciona", har´ que seas ignorado. Publicar una docena de líneas de código, diciendo “después de la línea 7 esperaba ver , pero ocurrió en vez de eso" es mucho m´s probable que logres una respuesta.
La vía más efectiva para ser preciso acerca de un problema de código es proveer un mínimo y demostrativo caso de prueba de error. ¿Qué es un caso mínimo de prueba? Es una ilustración del problema; justo el código suficiente para exhibir un comportamiento indeseable y no más. ¿Cómo haces un caso mínimo de prueba? Sí sabes cuál línea o sección de código está produciendo el comportamiento problemático, haz una copia de él solo agrega suficiente código para reproducir un ejemplo completo (i.e. Suficiente código fuente para que el compilador/interprete/cualquier aplicación que lo procese). Sí no lo puedes dirigir a una sección en particular,haz una copia del código fuente y empieza a remover partes que no afecten el comportamiento problemático. Lo más pequeño que sea tu caso de prueba será lo mejor (ver las sección llamada “Volumen no es precisión”).
Generar un caso realmente mínimo y pequeño no siempre será posible, pero intentarlo es una buena disciplina. Puede ayudarte a aprender que es lo que necesitas para resolver el problema por ti mismo — e incluso que es lo que no lo hace, los hackers gustan de ver que lo has intentado. Los hará más cooperativos.
Si simplemente quieres una revisión del código, dilo de frente,y asegurate de mencionar que áreas piensas que necesitan revisión en particular y por qué.
No publiques preguntas de tu tarea.
Los hackers son buenos para detectar preguntas de tareas; la mayoría de nosotros hemos hecho lo mismo. Esas preguntas son para que tu trabajes por fuera, de tal manera que aprendas de tu experiencia. Esta bien preguntar por orientaciones, pero no por la solución completa.
Si has pasado una pregunta de tarea, pero no la puedes resolver de todas maneras, intenta preguntar en un foro de grupo de usuarios o (como último recurso) en una lista/foro de “usuarios”de un proyecto. Mientras que los hackers la notarán, alguno de los usuarios avanzados podría al menos darte una orientación.
Evita preguntas injustificadas.
Resiste la tentación de finalizar tú solicitud de ayuda con preguntas sin sentido como “¿Podría alguien ayudarme ?” o “¿Existe alguna respuesta?” Primero: si has descrito tú problema medianamente competente, tales preguntas son en el mejor de los casos superfluas. Segundo: porque ellas son superfluas , los hackers las encuentran molestas — y son tentados a recurrir a la lógica formal e impecable pero desalentadora de dar respuestas del tipo “Sí , puedes ser ayudado” y “No, no hay ninguna ayuda para ti.”
En general, formular preguntas del tipo si-o-no es algo bueno de evitar a menos que tu requieras una respuesta del tipo si-o-no.
No titules tus preguntas como "Urgente", incluso si lo es para ti.
Ese es tu problema, no el nuestro. Pedir urgencia es como ser un checador de productividad: la mayoría de los hackers simplemente borrara tales mensajes como intentos egoístas y burdos de obtener atención especial e inmediata.
Existe una semi excepción. Se puede mencionar que estas usando el programa en algún lugar de alto perfil, uno al que los hackers excite; en tal caso, si estas bajo presión por tiempos, y lo dices amablemente, la gente puede verse interesada lo suficiente para contestar rápidamente.
Esto es algo muy riesgoso de hacer, porque la escala de estimaciones de los hackers acerca de que es excitante pueden ser diferentes de las tuyas. Publicar desde la estación espacial internacional podría calificar, por ejemplo, pero publicar acerca de una causa política o una organización caritativa para-sentirse-bien ciertamente no lo será. De hecho, publicar “Urgente: Ayudenme a salvar a los preciosos cachorros de foca !” inevitablemente te llevará a ser flameado o sacado incluso por los hackers que piensan que los cachorros de foca preciosos son importantes.
Si hallas que esto es misterioso, relee el resto de este how-to repetidamente hasta que lo entiendas antes de publicar absolutamente cualquier cosa.
La cortesía no daña, y algunas veces ayuda.
Sé cortes. Usa “Por favor” y “Gracias por tú atención” o “Gracias por tu consideración”. Haz claro que aprecias el tiempo que la gente emplea en ayudarte por nada.
Para ser honesto, esto no es tan importante como (y no puede ser sustituido por) ser gramaticalmente, claro, preciso y descriptivo, evitar los formatos propietarios etc.; los hackers en general preferirán tener reportes técnicos correctos aunque algo bruscos, que vaguedades amables. (Si esto te desconcierta, recuerda que valoramos las preguntas por lo que nos enseñan.)
Como sea, si tienes tus dudas técnicas claramente, la cortesía incrementará tus oportunidades de obtener una respuesta útil.
(Debemos mencionar que la única objeción seria que hemos tenido de hackers veteranos a este HOWTO es con respecto a nuestra recomendación previa de usar “De antemano gracias”. Algunos hackers sienten que esta connotación es para no agradecer a nadie después de haber recibido ayuda. Nuestra recomendación es de agregar también , primero “De antemano gracias” y después agradecer a los contestatarios que participaron, o expresar cortesía en un modo diferente, tal como al decir “Gracias por su atención” o “Gracias por su consideración”.)
Siga la solución con una nota breve.
Envía una nota después de que el problema haya sido resuelto a todos los que te ayudaron; hazles saber cómo se resolvió y agradeceles nuevamente el que te hayan socorrido. Si el problema atrajo la atención generalizada en una lista de correo o un grupo de ayuda, será apropiado publicar el seguimiento del mismo ahí mismo.
Lo óptimo sería que la réplica fuera para la entrada que comenzó la pregunta que fue publicada originalmente, y debería tener ‘CORREGIDO’, ‘RESUELTO’ o una mención igualmente obvia en el encabezado del tema. En las listas de correo con movimiento continuo, un potencial contestatario que lea una entrada acerca del “problema X” terminando con “problema X - RESUELTO” sabrá que no desperdicia su tiempo leyendo la entrada (a menos que (el/ella) personalmente halle el problema X interesante) y pueda así su tiempo de solución en un problema diferente.
Tu seguimiento no tiene que ser largo e involucrante; un simple “¡Qué tal! — fue un cable de red defectuoso! Gracias a todos . - Bill” será mejor que nada. De hecho, un resumen corto y agradable es mejor que una disertación larga a menos que la solución realmente sea técnicamente profunda. Diga que fue lo que resolvió el problema, pero no tienes que repetir todo el procedimiento de diagnóstico y solución por completo.
Para los problemas con algo de profundidad, es apropiado publicar un resumen de la secuencia del procedimiento de diagnóstico y solución. Describe tú problema real finalmente . Describe que te funcionó como solución, e indica los callejones sin salida después de todo. Los callejones sin salida suelen venir después de la solución correcta y otros materiales de resumen, en vez de transformar el seguimiento en una historia de detectives. Menciona los nombres de las personas que te ayudaron; de esa manera harás amigos.
Al parejo de ser cortes e informativo, este tipo de seguimiento ayudará a otros que busquen en el archivo de la lista de correo/grupo de ayuda/foro a saber exactamente que solución te ayudo y que podría ayudarles a ellos también.
Por último, pero no por ellos menos importante, este tipo de seguimiento ayuda a todos los que asistieron a sentir una satisfacción por la cercanía con el problema. Si no eres un enterado o un hacker, creenos, este sentimiento es muy importante para los gurúes y expertos a los que acudiste por ayuda. Las historias de problemas que siguieron sin resolver son cosas frustrantes; los hackers buscarán verlas resueltas. La buena voluntad que ganarás al estimular esta reacción será muy, pero muy importante y te ayudará la próxima vez que necesites formular una pregunta.
Considera cómo podrías ser capaz de prevenir a otros de tener los mismos problemas en el futuro. Preguntate si un parche en la documentación o las FAQs podría ayudar, y si la respuesta es afirmativa manda un parche al encargado.
Entre hackers, este tipo de buen comportamiento con el seguimiento es más importante que la amabilidad convencional. Es como obtendrás una buena reputación de interactuar bien con los demás, la cuál puede ser un valioso recurso.
Cómo interpretar las respuestas.RTFM y STFW: Cómo decirte que estas bien jodido ..
Hay una tradición ancestral y respetada: si recibes una respuesta “RTFM”, la persona que te lo envió piensa que deberías haber leído el estúpido manual. El o ella estarán seguramente en lo correcto. Ve a leerlo.
RTFM tiene un pariente joven. Si recibes una respuesta “STFW”, la persona que te lo envió piensa que debiste buscar en la red. El o ella estarán seguramente en lo correcto. Ve a buscarlo . (La versión intermedia de esto es cuando te dicen “&iexec;Google es tú amigo!”)
En los foros Web, también podrías ser advertido de buscar en los archivos del foro. De hecho, alguien podría ser considerado y proporcionarte la dirección de la entrada anterior donde el problema se soluciono. Pero no te fíes en esta consideración ; has tú búsqueda en los archivos antes de preguntar.
Usualmente, la persona que te dice que hagas una búsqueda tiene el manual o la página web con la información que necesitas abrir, y la está buscando mientras el o ella teclea. Estas respuestas significan que el o ella piensan que (a) la información que necesitas es f´cil de encontrar, y (b) aprenderás más si buscas la información fuera que si la tuvieras lista para digerirla ahí mismo.
No deberías ofenderte por esto; para los estándares hackers, tu contestador esta mostrándote una áspera muestra de respeto simplemente al no ignorarte. En vez de eso deberías estar agradecido por esta consideración maternal.
Si no entiendes ...
Si no entiendes la respuesta, no reclames de inmediato por una explicación. Usa las mismas herramientas que has usado para intentarlo y responde a tu pregunta original (manuales, FAQs, la Web, amigos experimentados) para comprender la respuesta. Entonces, si aún necesitas preguntar por explicación, muestra lo que has aprendido.
Por ejemplo, supon que te digo: “Suena como si tuvieras un atorón zentry; necesitas limpiarlo.” Entonces: aquí hay una siguiente mala pregunta: “¿Qué es un zentry?” Aquí hay una buena siguiente pregunta: “OK, leí la página de manual y los zentries sólo se mencionan bajo los switches -z y -p. Ninguno de ellos dice algo acerca de limpiar los zentries. ¿Esto es uno de ellos o estoy olvidando algo?”
Tratando con la descortesía.
Mucho de lo que se ve como rudeza en los círculos hackers no está pensado para ser ofensivo. En vez de eso, es producto del estilo directo de comunicación que es natural en la gente que está dedicada a resolver problemas que en hacer sentir a los demás bien y cómodos .
Cuando percibas descortesía, intenta reaccionar calmadamente. Si alguien realmente esta saliéndose de sus cabales, es muy seguro que un veterano de la lista o grupo de ayuda lo llame a la calma. Si eso no pasa y pierdes tu temperamento, es como si la persona ante la que te alteraste se estuviera comportando de acuerdo a las normas de la comunidad hacker y tú serás considerado en el error. Esto lastimará tus oportunidades de obtener ayuda o la información que necesitas.
De otro lado, ocasionalmente serás rudo y decir eso es gratuito. El lado opuesto de lo anterior es que es una forma aceptable de mandar al diablo a los ofensores reales, exhibiendo su mal comportamiento con un escalpelo verbal muy certero. Sé muy, pero muy seguro de tus bases antes de intentar esto, de cualquier manera. La línea entre corregir y ser primitivo y comenzar un a guerra sinsentido de flamazos es lo suficientemente delgada para que los hackers la entrecrucen frecuentemente; si eres un novato o un ajeno al medio, tus oportunidades de evitar este comportamiento son muy pocas. Si estas tras información en vez de diversión, lo mejor será mantener tus dedos fuera del teclado que atreverte a experimentar esto.
(Algunas personas aseguran que muchos hackers tienen una leve forma de autismo o el síndrome de Asperger, y que tienen perdidos algunos de los circuitos cerebrales que lubrican la interacción social humana “normal”. Esto podría ser o no cierto. Si no eres un hacker, te ayudará a lidiar con nuestras excentricidades si piensas en nosotros como unos dañados mentales. Adelante. No nos importa; nos gusta ser como quiera que seamos,y generalmente tenemos un saludable escepticismo acerca de las etiquetas clínicas.)
En la siguiente sección, vamos a hablar de un tema diferente; el tipo de “rudeza” que verás cuando tú tienes un comportamiento inadecuado.
Cómo no reaccionar como un perdedor.
Es seguro que vas a ser fregado un par de veces en los foros de la comunidad hacker — en las formas detalladas en este articulo, o similares. Y te dirán como joderte a ti mismo , posiblemente con detalles profusos. Y en público.
Cuando esto pase, lo peor que puedes hacer es lamentarte
