Cómo hacer preguntas de manera inteligente
Eric Steven Raymond
Thyrsus Enterprises
Rick Moen
Derechos de autor 2001,2006 Eric S. Raymond, Rick Moen
Historial de revisiones
Revisión 3.6 19 Mar 2008 esr
Actualización menor y nuevos enlaces.
Revisión 3.5 2 Ene 2008 esr
Corrección de errores tipográficos y algunos enlaces de traducción.
Revisión 3.4 24 Mar 2007 esr
Nueva sección, «Al preguntar por el código».
Revisión 3.3 29 Sep 2006 esr
Doblado con una buena sugerencia de Kai Niggemann.
Revisión 3.2 10 Ene 2006 esr
Doblado en ediciones de Rick Moen.
Revisión 3.1 28 Oct 2004 esr
Documento’Google es tu amigo'».
Revisión 3.0 2 Feb 2004 esr
Adición importante de material sobre la etiqueta adecuada en los foros web.
——————————————————————————–
Tabla de Contenidos
Traducciones
Descargo de responsabilidad
Introducción
Antes de preguntar
Cuando Usted Pregunte
Elige tu foro con cuidado
Los foros Web e IRC dirigidos a los principiantes suelen dar la respuesta más rápida
Como segundo paso, utilice las listas de correo del proyecto
Usar encabezados de temas específicos y significativos
Facilitar la respuesta
Escribir en un lenguaje claro, gramatical y correctamente escrito
Enviar preguntas en formatos accesibles y estándar
Sea preciso e informativo sobre su problema
El volumen no es precisión
No afirme que ha encontrado un error
Arrastrarse no es un sustituto de hacer los deberes.
Describa los síntomas del problema, no sus suposiciones
Describa los síntomas de su problema en orden cronológico
Describa la meta, no el paso
No pida a la gente que responda por correo electrónico privado
Sea explícito sobre su pregunta
Al preguntar por el código
No publique preguntas sobre la tarea
Podar consultas inútiles
No marque su pregunta como»urgente», aunque sea para usted.
La cortesía nunca hace daño, y a veces ayuda.
Haga un seguimiento con una breve nota sobre la solución
Cómo interpretar las respuestas
RTFM y STFW: Cómo saber si has metido la pata seriamente
Si no entiendes…
Lidiando con la grosería
Sobre no reaccionar como un perdedor
Preguntas que no se deben hacer
Preguntas buenas y malas
Si no puede obtener una respuesta
Cómo responder a las preguntas de una manera útil
Recursos relacionados
Agradecimientos
Traducciones
Traducciones: Bahasa Indonesio Brasilo-Portugués Chino Checo Danés Holandés Estonio Finlandés Francés Georgiano Alemán Griego Hebreo Húngaro Italiano Japonés Polaco Portugués Rumano Ruso Serbio Español Sueco Tailandés Turco. Si desea copiar, reflejar, traducir o extraer este documento, consulte mi política de copias.
Descargo de responsabilidad
Muchos sitios web de proyectos tienen enlaces a este documento en sus secciones sobre cómo obtener ayuda. Está bien, es el uso que pretendemos? pero si usted es un webmaster que crea un enlace para la página de su proyecto, por favor, muestre en un lugar destacado cerca de la nota de enlace que no somos un servicio de ayuda para su proyecto!
Hemos aprendido de la manera difícil que sin tal aviso, seremos repetidamente acosados por idiotas que piensan que el hecho de haber publicado este documento hace que nuestro trabajo sea resolver todos los problemas técnicos del mundo.
Si usted está leyendo este documento porque necesita ayuda y tiene la impresión de que puede obtenerla directamente de los autores de este documento, usted es uno de los idiotas en cuestión. No nos hagas preguntas. Te ignoraremos. Estamos aquí para mostrarle cómo obtener ayuda de personas que realmente conocen el software o hardware con el que está tratando, pero el 99,9% de las veces no seremos nosotros. A menos que sepas con certeza que uno de los autores es un experto en lo que estás tratando, déjanos en paz y todo el mundo será más feliz.
Introducción
En el mundo de los hackers, el tipo de respuestas que se obtienen a las preguntas técnicas depende tanto de la forma en que se formulan las preguntas como de la dificultad de desarrollar la respuesta. Esta guía le enseñará cómo hacer preguntas de una manera más probable para obtener una respuesta satisfactoria.
Ahora que el uso del código abierto se ha generalizado, a menudo se pueden obtener tan buenas respuestas de otros usuarios más experimentados como de los hackers. Esto es algo bueno; los usuarios tienden a ser un poco más tolerantes con el tipo de fracasos que los novatos suelen tener. Aún así, tratar a los usuarios experimentados como hackers en las formas que recomendamos aquí será generalmente la manera más efectiva de obtener respuestas útiles de ellos también.
Lo primero que hay que entender es que a los hackers en realidad les gustan los problemas difíciles y las preguntas buenas y estimulantes sobre ellos. Si no lo hiciéramos, no estaríamos aquí. Si nos hace una pregunta interesante para masticar, le estaremos agradecidos; las buenas preguntas son un estímulo y un regalo. Las buenas preguntas nos ayudan a desarrollar nuestra comprensión, y a menudo revelan problemas que podríamos no haber notado o en los que no habríamos pensado de otra manera. Entre los hackers,»Buena pregunta» es un cumplido fuerte y sincero.
A pesar de ello, los hackers tienen la reputación de responder a preguntas sencillas con lo que parece hostilidad o arrogancia. A veces parece que somos reflexivamente groseros con los novatos y los ignorantes. Pero esto no es verdad.
Lo que somos, sin disculparnos, es hostil a la gente que parece no querer pensar o hacer su propia tarea antes de hacer preguntas. Gente así son los lavabos de tiempo que toman sin dar nada a cambio, y pierden el tiempo que podríamos haber gastado en otra pregunta más interesante y otra persona más digna de una respuesta. Llamamos a la gente así»perdedores». (y por razones históricas a veces lo deletreamos?lusers?.
Nos damos cuenta de que hay muchas personas que sólo quieren usar el software que escribimos, y que no tienen ningún interés en aprender detalles técnicos. Para la mayoría de las personas, una computadora es simplemente una herramienta, un medio para alcanzar un fin; tienen cosas más importantes que hacer y viven para vivir. Lo reconocemos, y no esperamos que todo el mundo se interese por las cuestiones técnicas que nos fascinan. Sin embargo, nuestro estilo de responder a las preguntas está dirigido a personas que se interesan y están dispuestas a participar activamente en la resolución de problemas. Eso no va a cambiar. Tampoco debería hacerlo; si lo hiciera, nos volveríamos menos eficaces en las cosas que mejor hacemos.
Somos (en gran parte) voluntarios. Tomamos tiempo de nuestras vidas ocupadas para contestar preguntas, y a veces estamos abrumados con ellas. Así que filtramos sin piedad. En particular, desechamos las preguntas de personas que parecen ser perdedoras para pasar nuestro tiempo de preguntas y respuestas de manera más eficiente, a los ganadores.
Si usted encuentra esta actitud odiosa, condescendiente o arrogante, revise sus suposiciones. No te pedimos que nos hagas una genuflexión? de hecho, a la mayoría de nosotros nos encantaría nada más que tratarte como un igual y darte la bienvenida a nuestra cultura, si haces el esfuerzo necesario para que eso sea posible. Pero simplemente no es eficiente para nosotros tratar de ayudar a las personas que no están dispuestas a ayudarse a sí mismas. Está bien ser ignorante; no está bien hacerse el estúpido.
Por lo tanto, aunque no es necesario ser técnicamente competente para obtener nuestra atención, es necesario demostrar el tipo de actitud que conduce a la competencia: alerta, reflexivo, observador, dispuesto a ser un socio activo en el desarrollo de una solución. Si no puedes vivir con este tipo de discriminación, te sugerimos que pagues a alguien por un contrato de soporte comercial en lugar de pedirle a los hackers que te ayuden personalmente.
Si decides venir a pedirnos ayuda, no quieres ser uno de los perdedores. Tú tampoco quieres parecerlo. La mejor manera de obtener una respuesta rápida y receptiva es preguntársela como una persona con inteligencia, confianza y pistas que sólo necesita ayuda en un problema en particular.
(Las mejoras a esta guía son bienvenidas. Puede enviar sus sugerencias por correo electrónico a esr@thyrsus.com o respond-auto@linuxmafia.com. Tenga en cuenta, sin embargo, que este documento no pretende ser una guía general sobre la netiqueta, y en general rechazaremos las sugerencias que no estén específicamente relacionadas con la obtención de respuestas útiles en un foro técnico.)
Antes de preguntar
Antes de hacer una pregunta técnica por correo electrónico, en un grupo de noticias o en un tablero de chat de un sitio web, haga lo siguiente:
Intenta encontrar una respuesta buscando en los archivos del foro al que planeas enviar mensajes.
Intente encontrar una respuesta buscando en la Web.
Trate de encontrar una respuesta leyendo el manual.
Intente encontrar una respuesta leyendo las preguntas frecuentes.
Trate de encontrar una respuesta mediante inspección o experimentación.
Trate de encontrar una respuesta preguntándole a un amigo hábil.
Si eres un programador, intenta encontrar una respuesta leyendo el código fuente.
Cuando haga su pregunta, muestre el hecho de que usted ha hecho estas cosas primero; esto ayudará a establecer que usted no está siendo una esponja perezosa y que está perdiendo el tiempo de la gente. Mejor aún, muestre lo que ha aprendido al hacer estas cosas. Nos gusta responder a las preguntas de las personas que han demostrado que pueden aprender de las respuestas.
Utilice tácticas como hacer una búsqueda en Google sobre el texto de cualquier mensaje de error que reciba (buscando en grupos de Google así como en páginas web. Esto bien podría llevarte directamente a arreglar la documentación o un hilo de la lista de correo respondiendo a tu pregunta. Incluso si no lo hace, decir»Busqué en Google en la siguiente frase pero no obtuve nada que pareciera prometedor» es algo bueno para hacer en correos electrónicos o publicaciones de noticias que solicitan ayuda, aunque sólo sea porque registra lo que las búsquedas no ayudan. También ayudará a dirigir a otras personas con problemas similares a su hilo, vinculando los términos de búsqueda a lo que esperamos que sea su hilo de problemas y resolución.
Tómate tu tiempo. No espere poder resolver un problema complicado con unos segundos de googleo. Lea y entienda las preguntas frecuentes, relájese y reflexione sobre el problema antes de dirigirse a los expertos. Confíe en nosotros, ellos podrán saber por sus preguntas cuánto leyó y pensó, y estarán más dispuestos a ayudar si viene preparado. No dispare instantáneamente todo su arsenal de preguntas sólo porque su primera búsqueda no encontró ninguna respuesta (o demasiadas.
Prepare su pregunta. Piénsalo bien. Las preguntas que suenan apresuradas obtienen respuestas precipitadas, o ninguna. Cuanto más haga para demostrar que habiendo puesto su pensamiento y esfuerzo en resolver su problema antes de buscar ayuda, más probable es que realmente obtenga ayuda.
Tenga cuidado de no hacer la pregunta equivocada. Si le preguntas a uno que se basa en suposiciones erróneas, J. Random Hacker es muy probable que responda con una respuesta inútilmente literal mientras piensa»Pregunta estúpida…», y espera que la experiencia de obtener lo que pediste en lugar de lo que necesitabas te enseñe una lección.
Nunca asuma que tiene derecho a una respuesta. No lo eres; después de todo, no estás pagando por el servicio. Usted ganará una respuesta, si se la gana, al hacer una pregunta sustancial, interesante y que invite a la reflexión, una que implícitamente contribuya a la experiencia de la comunidad en lugar de simplemente exigir pasivamente el conocimiento de los demás.
Por otro lado, dejar claro que usted es capaz y está dispuesto a ayudar en el proceso de desarrollo de la solución es un muy buen comienzo. ¿Podría alguien proporcionar un puntero,»¿Cuál es mi ejemplo que falta?», y»¿Qué sitio debería haber comprobado?» son más propensos a obtener respuesta que»Por favor, publique el procedimiento exacto que debería utilizar», porque usted está dejando claro que usted está realmente dispuesto a completar el proceso si alguien sólo puede señalar en la dirección correcta.
Cuando Usted Pregunte
Elige tu foro con cuidado
Sea sensible al elegir dónde hacer su pregunta. Es probable que lo ignoren, o que lo descarten como un perdedor, si usted lo hace:
publique su pregunta en un foro en el que no esté relacionada con el tema
enviar una pregunta muy elemental a un foro donde se esperan preguntas técnicas avanzadas, o viceversa
cruzando a demasiados grupos de noticias diferentes
enviar un correo electrónico personal a alguien que no sea ni conocido suyo ni responsable personalmente de la solución de su problema
Los piratas informáticos **** eliminan las preguntas que no son adecuadas para tratar de proteger sus canales de comunicación de ser ahogados en la irrelevancia. No quieres que esto te pase a ti.
El primer paso, por lo tanto, es encontrar el foro adecuado. Una vez más, Google y otros métodos de búsqueda en la Web son tus amigos. Utilícelos para encontrar la página web del proyecto más estrechamente relacionada con el hardware o software que le da dificultades. Por lo general, tendrá enlaces a una lista de preguntas frecuentes (FAQ), y a listas de correo de proyectos y sus archivos. Estas listas de correo son los últimos lugares a los que puede acudir en busca de ayuda, si sus propios esfuerzos (incluida la lectura de las preguntas frecuentes que encontró) no le encuentran una solución. La página del proyecto también puede describir un procedimiento de reporte de errores, o tener un enlace a uno; si es así, sígalo.
Disparar un correo electrónico a una persona o foro con el que no está familiarizado es, en el mejor de los casos, arriesgado. Por ejemplo, no asuma que el autor de una página web informativa quiere ser su asesor gratuito. No haga conjeturas optimistas sobre si su pregunta será bienvenida? si no está seguro, envíela a otro lugar o absténgase de enviarla.
Al seleccionar un foro web, grupo de noticias o lista de correo, no confíe demasiado en el nombre por sí mismo; busque una FAQ o una carta para verificar que su pregunta está en el tema. Lea algo del tráfico de atrás antes de publicar para que se haga una idea de cómo se hacen las cosas allí. De hecho, es una muy buena idea hacer una búsqueda de palabras clave para palabras relacionadas con su problema en el grupo de noticias o en los archivos de la lista de correo antes de publicar. Puede que encuentre una respuesta, y si no, le ayudará a formular una mejor pregunta.
No dispares a todos los canales de ayuda disponibles a la vez, eso es como gritar e irritar a la gente. Pasa a través de ellos suavemente.
Sepa cuál es su tema! Uno de los errores clásicos es hacer preguntas sobre la interfaz de programación de Unix o Windows en un foro dedicado a un lenguaje o biblioteca o herramienta portátil en ambos. Si no entiendes por qué esto es un error, es mejor que no hagas ninguna pregunta hasta que la recibas.
En general, las preguntas a un foro público bien seleccionado tienen más probabilidades de obtener respuestas útiles que las preguntas equivalentes a las de un foro privado. Hay múltiples razones para ello. Uno es simplemente el tamaño del grupo de encuestados potenciales. Otro es el tamaño de la audiencia; los hackers prefieren responder a preguntas que educan a mucha gente que a preguntas que sirven sólo a unos pocos.
Es comprensible que los hackers expertos y los autores de software popular ya estén recibiendo más que su parte justa de mensajes mal dirigidos. Añadiendo a la inundación, en casos extremos se podría incluso ser la gota que colma el vaso? bastantes veces, los colaboradores de proyectos populares han retirado su apoyo porque los daños colaterales en forma de tráfico inútil de correo electrónico a sus cuentas personales se volvieron insoportables.
Los foros Web e IRC dirigidos a los principiantes suelen dar la respuesta más rápida
Su grupo de usuarios local, o su distribución de Linux, puede anunciar un foro Web o canal IRC donde los novatos pueden obtener ayuda. (En los países no anglófonos, los foros de novatos son aún más propensos a ser listas de correo.) Estos son buenos primeros lugares para preguntar, especialmente si usted piensa que puede haber tropezado con un problema relativamente simple o común. Un canal IRC anunciado es una invitación abierta a hacer preguntas y a menudo obtener respuestas en tiempo real.
De hecho, si tiene el programa que le está dando problemas con una distribución de Linux (como es común hoy en día), puede ser mejor preguntar en el foro/lista de la distribución antes de probar el foro/lista del proyecto del programa. Los hackers del proyecto pueden decir,»usa nuestro edificio».
Antes de publicar en cualquier foro web, compruebe si tiene una función de búsqueda. Si lo hace, intente un par de búsquedas de palabras clave para algo como su problema; podría ayudar. Si usted hizo una búsqueda general en la Web antes (como debería haberlo hecho), busque en el foro de todos modos; es posible que su motor de búsqueda en la Web no haya indexado todo este foro recientemente.
Existe una tendencia creciente de los proyectos a dar soporte a los usuarios a través de un foro Web o canal IRC, con el correo electrónico reservado más para el tráfico de desarrollo. Por lo tanto, busque primero esos canales cuando busque ayuda específica para un proyecto.
Como segundo paso, utilice las listas de correo del proyecto
Cuando un proyecto tiene una lista de correo de desarrollo, escriba a la lista de correo, no a desarrolladores individuales, incluso si cree que sabe quién puede responder mejor a su pregunta. Compruebe la documentación del proyecto y su página de inicio para la dirección de una lista de correo del proyecto, y utilícela. Hay varias buenas razones para esta política:
Cualquier pregunta lo suficientemente buena como para ser formulada a un desarrollador también será de valor para todo el grupo. Por el contrario, si sospecha que su pregunta es demasiado tonta para una lista de correo, no es una excusa para acosar a los desarrolladores individuales.
Hacer preguntas en la lista distribuye la carga entre los desarrolladores. El desarrollador individual (especialmente si es el líder del proyecto) puede estar demasiado ocupado para responder a sus preguntas.
La mayoría de las listas de correo están archivadas y los archivos están indexados por los motores de búsqueda. Si usted hace su pregunta en la lista y es contestada, una futura consulta podría encontrar su pregunta y la respuesta en la Web en lugar de volver a hacerla.
Si se ven ciertas preguntas que se hacen a menudo, los desarrolladores pueden usar esa información para mejorar la documentación o el software en sí para ser menos confusos. Pero si esas preguntas se hacen en privado, nadie tiene el cuadro completo de las preguntas que se hacen con más frecuencia.
Si un proyecto tiene tanto un»usuario» como un»desarrollador». (o?hacker?) o foro Web, y usted no está hackeando el código, pregunte en la lista/foro de usuarios. No asuma que será bienvenido en la lista de desarrolladores, donde es probable que experimenten su pregunta como ruido que interrumpe el tráfico de su desarrollador.
Sin embargo, si estás seguro de que tu pregunta no es trivial, y no obtienes respuesta en la lista/foro de usuarios durante varios días, prueba con el de»desarrollador». Le aconsejamos que aceche allí unos días antes de publicar para aprender las costumbres locales (en realidad este es un buen consejo para cualquier lista privada o semiprivada.
Si no puede encontrar la dirección de la lista de correo de un proyecto, pero sólo ve la dirección del encargado del proyecto, escriba al encargado del proyecto. Pero incluso en ese caso, no asuma que la lista de correo no existe. Mencione en su correo electrónico que usted intentó y no pudo encontrar la lista de correo apropiada. También mencione que usted no se opone a que su mensaje sea reenviado a otras personas. (Muchas personas creen que el correo electrónico privado debe seguir siendo privado, incluso si no hay nada secreto en él. Al permitir que su mensaje sea reenviado, usted le da a su corresponsal la opción de cómo manejar su correo electrónico.)
Usar encabezados de temas específicos y significativos
En listas de correo, grupos de noticias o foros web, el encabezado del asunto es su oportunidad de oro para atraer la atención de expertos calificados en alrededor de 50 caracteres o menos. No lo malgastes en balbucear como»Por favor, ayúdame». (por no hablar de «POR FAVOR AYÚDAME!!!!!»; los mensajes con temas como ese se descartan por reflejo. No trate de impresionarnos con la profundidad de su angustia; use el espacio para una descripción superconcisa del problema.
Una buena convención para las cabeceras de los temas, utilizada por muchas organizaciones de soporte técnico, es»objeto – desviación». La parte»objeto» especifica qué cosa o grupo de cosas está teniendo un problema, y la parte»desviación» describe la desviación del comportamiento esperado.
Estúpido:
AYUDA! El vídeo no funciona correctamente en mi portátil!
Inteligente:
X.org 6.8.1 cursor de ratón deformado, conjunto de chips de vídeo Fooware MV1005
Más inteligente:
X.org 6.8.1 cursor del ratón en el chipset Fooware MV1005 vid. – está deformado
El proceso de escribir una descripción de»desviación de objeto» le ayudará a organizar su pensamiento sobre el problema con más detalle. ¿Qué es lo que se ve afectado? ¿Sólo el cursor del ratón u otros gráficos? ¿Es esto específico de la versión X.org de X? ¿A la versión 6.8.1? ¿Es esto específico de los chipsets de vídeo Fooware? Para el modelo MV1005? Un hacker que ve el resultado puede entender inmediatamente con qué está teniendo un problema y el problema que está teniendo, de un vistazo.
De manera más general, imagínese mirar el índice de un archivo de preguntas, con sólo las líneas de asunto. Haga que su línea de asunto refleje su pregunta lo suficientemente bien como para que el siguiente tipo que busque en el archivo con una pregunta similar a la suya pueda seguir el hilo de una respuesta en lugar de volver a publicar la pregunta.
Si hace una pregunta en una respuesta, asegúrese de cambiar la línea de asunto para indicar que está haciendo una pregunta. Una línea de Asunto que se vea como»Re: test» o»Re: nuevo error» es menos probable que atraiga cantidades útiles de atención. También, pare la cita de mensajes anteriores al mínimo consistente con las pistas en los nuevos lectores.
No se limite a responder a un mensaje de la lista para iniciar una conversación completamente nueva. Esto limitará su audiencia. Algunos lectores de correo, como mutt, permiten al usuario ordenar por hilos y luego ocultar los mensajes en un hilo doblando el hilo. La gente que hace eso nunca verá tu mensaje.
No basta con cambiar de tema. Mutt, y probablemente otros lectores de correo, busca otra información en los encabezados del correo electrónico para asignarla a un hilo, no a la línea de asunto. En su lugar, inicie un correo electrónico completamente nuevo.
En los foros web las reglas de buenas prácticas son ligeramente diferentes, ya que los mensajes suelen estar mucho más estrechamente ligados a hilos de discusión específicos y a menudo invisibles fuera de esos hilos. Cambiar el tema cuando se hace una pregunta en respuesta no es esencial. No todos los foros permiten incluso líneas de asunto separadas en las respuestas, y casi nadie las lee cuando lo hacen. Sin embargo, hacer una pregunta en una respuesta es una práctica dudosa en sí misma, porque sólo la verán aquellos que estén observando este hilo. Por lo tanto, a menos que estés seguro de que quieres preguntar sólo a las personas que están activas en el hilo, inicia uno nuevo.
Facilitar la respuesta
Terminando su consulta con ?por favor envíe su respuesta a…. ? hace bastante improbable que obtenga una respuesta. Si no puede tomarse la molestia de tomarse ni siquiera los pocos segundos necesarios para configurar un encabezado correcto de Respuesta-A en su agente de correo, no podemos tomarnos la molestia de tomarnos ni siquiera unos segundos para pensar en su problema. Si su programa de correo no lo permite, obtenga un mejor programa de correo. Si su sistema operativo no soporta ningún programa de correo electrónico que lo permita, obtenga un mejor sistema operativo.
En los foros web, pedir una respuesta por correo electrónico es de mala educación, a menos que usted crea que la información puede ser delicada (y alguien, por alguna razón desconocida, se lo hará saber, pero no todo el foro. Si desea una copia de correo electrónico cuando alguien responde en el hilo, solicite que el foro Web lo envíe; esta función es soportada casi en todas partes bajo opciones como»ver este hilo»,»enviar correo electrónico con las respuestas», etc.
Escribir en un lenguaje claro, gramatical y correctamente escrito
Hemos encontrado por experiencia que las personas que son escritores descuidados y descuidados también suelen ser descuidados y descuidados a la hora de pensar y codificar (a menudo lo suficiente como para apostar, de todos modos. Responder a preguntas para pensadores descuidados y descuidados no es gratificante; preferimos pasar nuestro tiempo en otro lugar.
Por lo tanto, es importante que exprese su pregunta de forma clara y correcta. Si no puedes molestarte en hacer eso, no podemos molestarnos en prestar atención. Gasta el esfuerzo extra para pulir tu idioma. No tiene que ser rígido o formal? de hecho, la cultura hacker valora el lenguaje informal, sagaz y humorístico utilizado con precisión. Pero tiene que ser preciso; tiene que haber alguna indicación de que estás pensando y prestando atención.
Deletrear, puntuar y poner en mayúsculas correctamente. No confundas»su» con»es»,»suelto» con»perder», o»discreto» con»discreto». No TIPO EN MAYÚSCULAS; esto se lee como gritos y se considera grosero (todo lo pequeño es sólo un poco menos molesto, ya que es difícil de leer. Alan Cox puede salirse con la suya, pero usted no puede.)
De manera más general, si escribes como un semianalfabeto ****, es muy probable que seas ignorado. Por lo tanto, no utilice métodos abreviados de mensajería instantánea. Si deletreas «tú» como «u», parecerás un semianalfabeto **** para ahorrar dos pulsaciones de teclas enteras. Peor: escribir como un guión de l33t kiddie hax0r es el beso absoluto de la muerte y garantiza que no recibirás nada más que silencio de piedra (o, en el mejor de los casos, un montón de desprecio y sarcasmo) a cambio.
Si usted está haciendo preguntas en un foro que no utiliza su idioma nativo, obtendrá una cantidad limitada de holgura para los errores ortográficos y gramaticales, pero no una holgura extra para la pereza (y sí, por lo general podemos detectar esa diferencia. Además, a menos que usted sepa cuáles son los idiomas de su encuestado, escriba en inglés. Los hackers ocupados tienden a hacer preguntas en idiomas que no entienden, y el inglés es el idioma de trabajo de Internet. Al escribir en inglés, usted minimiza las posibilidades de que su pregunta sea descartada sin ser leída.
Enviar preguntas en formatos accesibles y estándar
Si usted hace que su pregunta sea artificialmente difícil de leer, es más probable que se pase por alto a favor de una que no lo sea. Así que:
Envíe correo en texto plano, no en HTML. (No es difícil desactivar el HTML.)
Los archivos adjuntos MIME suelen estar bien, pero sólo si son contenido real (como un archivo fuente adjunto o un parche), y no simplemente una plantilla generada por su cliente de correo (como otra copia de su mensaje.
No envíe mensajes de correo electrónico en los que párrafos enteros sean líneas con múltiples pliegues. (Esto hace que sea demasiado difícil responder sólo a una parte del mensaje.) Suponga que sus encuestados leerán el correo en pantallas de texto de 80 caracteres de ancho y ajuste el ajuste de línea en consecuencia, a algo menos de 80 caracteres.
Sin embargo, no ajuste los datos (como volcados de archivos de registro o transcripciones de sesiones) a un ancho de columna fijo. Los datos deben incluirse tal cual, para que los encuestados puedan confiar en que están viendo lo que usted vio.
No envíe la codificación MIME Quoted-Printable a un foro en inglés. Esta codificación puede ser necesaria cuando se publica en un idioma que ASCII no cubre, pero muchos agentes de correo electrónico no lo soportan. Cuando se rompen, todos esos =20 glifos dispersos por el texto son feos y distraen? o pueden sabotear activamente la semántica de su texto.
Nunca, nunca espere que los hackers sean capaces de leer formatos de documentos propietarios cerrados como Microsoft Word o Excel. La mayoría de los hackers reaccionan a esto tan bien como lo harías si tuvieras un montón de estiércol de cerdo humeante tirado en la puerta de tu casa. Incluso cuando pueden hacer frente a la situación, les molesta tener que hacerlo.
Si está enviando correo electrónico desde un equipo con Windows, desactive la estúpida función»Citas inteligentes» de Microsoft. Esto es para evitar que salpiques a los personajes de la basura en tu correo.
En los foros Web, no abuse de las características de?smiley? y?HTML? (cuando estén presentes. Una sonrisa o dos por lo general está bien, pero el texto de colores de fantasía tiende a hacer que la gente piense que usted es patético. El uso excesivo de emoticonos, colores y fuentes te hará parecer una adolescente risueña, lo cual generalmente no es una buena idea a menos que estés más interesado en el sexo que en las respuestas.
Si está utilizando un cliente de correo con interfaz gráfica de usuario como Netscape Messenger, MS Outlook o de su tipo, tenga cuidado de que pueda violar estas reglas cuando se utiliza con su configuración predeterminada. La mayoría de estos clientes tienen un menú basado en el comando»View Source». Use esto en algo de su carpeta de correo, verificando el envío de texto sin formato sin adjuntar nada innecesario.
Sea preciso e informativo sobre su problema
Describa los síntomas de su problema o insecto con cuidado y claridad.
Describa el entorno en el que ocurre (máquina, sistema operativo, aplicación, lo que sea. Proporcione el nivel de distribución y lanzamiento de su proveedor (por ejemplo:»Fedora Core 7″,»Slackware 9.1″, etc..
Describa la investigación que realizó para tratar de entender el problema antes de hacer la pregunta.
Describa las medidas de diagnóstico que tomó para tratar de determinar el problema usted mismo antes de hacer la pregunta.
Describa cualquier cambio reciente que pueda ser relevante en la configuración de su ordenador o software.
Haga lo mejor que pueda para anticiparse a las preguntas que le hará un hacker, y respóndalas con anticipación en su solicitud de ayuda.
Simon Tatham ha escrito un excelente ensayo titulado How to Report Bugs Effectively. Le recomiendo encarecidamente que lo lea.
El volumen no es precisión
Usted necesita ser preciso e informativo. Este fin no se consigue simplemente volcando grandes volúmenes de código o datos en una solicitud de ayuda. Si tiene un caso de prueba grande y complicado que está rompiendo un programa, trate de recortarlo y hacerlo lo más pequeño posible.
Esto es útil por al menos tres razones. Dos: al simplificar la pregunta, es más probable que obtenga una respuesta útil. Tres: En el proceso de refinar su informe de fallo, puede desarrollar una solución o solución usted mismo.
No afirme que ha encontrado un error
Cuando tenga problemas con una pieza de software, no diga que ha encontrado un error a menos que esté muy, muy seguro de su terreno. Sugerencia: a menos que pueda proporcionar un parche de código fuente que solucione el problema, o una prueba de regresión contra una versión anterior que demuestre un comportamiento incorrecto, probablemente no esté lo suficientemente seguro. Esto se aplica también a las páginas web y a la documentación; si ha encontrado un error en la documentación, debe proporcionar un texto de sustitución y las páginas en las que debe continuar.
Recuerde, hay muchos otros usuarios que no están experimentando su problema. De lo contrario, se habría enterado de ello leyendo la documentación y buscando en la Web (lo hizo antes de quejarse, ¿no?. Esto significa que muy probablemente eres tú quien está haciendo algo mal, no el software.
La gente que escribió el software trabaja muy duro para que funcione lo mejor posible. Si usted afirma que ha encontrado un error, estará impugnando su competencia, lo que puede ofender a algunos de ellos incluso si está en lo cierto. Es especialmente poco diplomático gritar»bug» en la línea de Asunto.
Cuando haga su pregunta, es mejor escribir como si asumiera que está haciendo algo mal, incluso si está bastante seguro en privado de que ha encontrado un error real. Si realmente hay un error, lo oirás en la respuesta. Juega para que los mantenedores quieran disculparse contigo si el error es real, en lugar de para que les debas una disculpa si lo has estropeado.
Arrastrarse no es un sustituto de hacer los deberes.
Algunas personas que entienden que no deben comportarse de forma grosera o arrogante, exigiendo una respuesta, se retiran al extremo opuesto de la seducción. «Sé que sólo soy un patético novato perdedor, pero…». Esto es una distracción y no ayuda. Es especialmente molesto cuando se combina con la vaguedad sobre el problema real.
No pierda su tiempo, ni el nuestro, en una política de primates tosca. En su lugar, presente los antecedentes y su pregunta lo más claramente posible. Esa es una mejor manera de posicionarse que arrastrándose.
A veces los foros web tienen lugares separados para preguntas de novatos. Si sientes que tienes una pregunta de novato, sólo tienes que ir allí. Pero tampoco te arrastres allí.
Describa los síntomas del problema, no sus suposiciones
No es útil decirle a los hackers lo que usted cree que está causando su problema. (Si sus teorías diagnósticas fueran tan buenas, ¿estaría consultando a otros para obtener ayuda?) Por lo tanto, asegúrese de que les está diciendo los síntomas básicos de lo que sale mal, en lugar de sus interpretaciones y teorías. Deje que ellos hagan la interpretación y el diagnóstico. Si cree que es importante que diga lo que piensa, etiquételo claramente como tal y describa por qué esa respuesta no funciona para usted.
Estúpido:
Estoy obteniendo errores SIG11 consecutivos en las compilaciones del kernel, y sospecho que se ha producido una grieta en uno de los trazos de la placa madre. ¿Cuál es la mejor manera de buscarlos?
Inteligente:
Mi K6/233 construido en casa en una placa madre FIC-PA2007 (VIA Apollo VP2 chipset) con 256MB Corsair PC133 SDRAM comienza a recibir frecuentes errores SIG11 unos 20 minutos después del encendido durante el curso de la compilación del kernel, pero nunca en los primeros 20 minutos. Reiniciar no reinicia el reloj, pero apagarlo durante la noche sí. Cambiar toda la RAM no ayudó. A continuación se muestra la parte relevante de un registro de sesión de compilación típico.
Ya que el punto anterior parece ser difícil de entender para muchas personas, he aquí una frase para recordárselo: «Todos los diagnósticos son de Missouri.» El lema oficial de ese estado estadounidense es «Muéstrame» (ganado en 1899, cuando el congresista Willard D. Vandiver dijo «Vengo de un país que cultiva maíz, algodón, berberechos y demócratas, y la elocuencia espumosa no me convence ni me satisface». Soy de Missouri. Tienes que mostrarme.») En el caso de los diagnosticadores, no es una cuestión de escepticismo, sino más bien una necesidad literal y funcional de ver lo que se acerca lo más posible a la misma evidencia cruda que usted ve, en lugar de sus conjeturas y resúmenes. Muéstranos.
Describa los síntomas de su problema en orden cronológico
Las pistas más útiles para entender algo que salió mal a menudo se encuentran en los eventos inmediatamente anteriores. Por lo tanto, su cuenta debe describir con precisión lo que usted hizo, y lo que la máquina y el software hicieron, antes de la ampliación. En el caso de los procesos de línea de comandos, es muy útil tener un registro de sesión (por ejemplo, usar la utilidad de script) y citar las aproximadamente veinte líneas relevantes.
Si el programa que explotó tiene opciones de diagnóstico (como -v de verboso), intente seleccionar opciones que añadan información útil de depuración a la transcripción. Recuerde que más no es necesariamente mejor; intente elegir un nivel de depuración que informe en lugar de ahogar al lector en basura.
Si su cuenta termina siendo larga (más de unos cuatro párrafos), podría ser útil exponer sucintamente el problema al principio y luego seguir con el cuento cronológico. De esta manera, los hackers sabrán a qué atenerse al leer su cuenta.
Describa la meta, no el paso
Si está tratando de averiguar cómo hacer algo (en lugar de reportar un error), comience por describir la meta. Sólo entonces describa el paso particular hacia él que usted está bloqueado.
A menudo, las personas que necesitan ayuda técnica tienen en mente un objetivo de alto nivel y se quedan atascadas en lo que creen que es un camino particular hacia el objetivo. Vienen por ayuda con el paso, pero no se dan cuenta de que el camino está mal. Puede tomar un esfuerzo sustancial para superar esto.
Estúpido:
¿Cómo consigo que el selector de colores del programa FooDraw tome un valor RGB hexadecimal?
Inteligente:
Estoy tratando de reemplazar la tabla de colores de una imagen con valores de mi elección. Ahora mismo la única manera que puedo ver para hacer esto es editando cada ranura de la tabla, pero no puedo conseguir que el selector de color de FooDraw tome un valor RGB hexadecimal.
La segunda versión de la pregunta es inteligente. Permite una respuesta que sugiere una herramienta más adecuada para la tarea.
No pida a la gente que responda por correo electrónico privado
Los hackers creen que la resolución de problemas debe ser un proceso público y transparente durante el cual un primer intento de respuesta puede y debe ser corregido si alguien con más conocimientos advierte que está incompleto o incorrecto. Además, los ayudantes obtienen parte de su recompensa por ser encuestados por ser vistos como competentes y conocedores por sus pares.
Cuando usted pide una respuesta privada, está interrumpiendo tanto el proceso como la recompensa. No lo hagas. No lo hagas. Es la decisión del encuestado si responde en privado o no? y si lo hace, es generalmente porque piensa que la pregunta está demasiado mal formada o es demasiado obvia para ser interesante para los demás.
Hay una excepción limitada a esta regla. Si crees que la pregunta es tal que es probable que obtengas muchas respuestas que son muy similares, entonces las palabras mágicas son»envíame un correo electrónico y resumiré las respuestas para el grupo». Es cortés tratar de salvar a la lista de correo o grupo de noticias de una avalancha de publicaciones sustancialmente idénticas? pero tienes que mantener la promesa de resumir.
Sea explícito sobre su pregunta
Las preguntas abiertas tienden a ser percibidas como una pérdida de tiempo. Aquellas personas con más probabilidades de poder darte una respuesta útil son también las más ocupadas (aunque sólo sea porque ellas mismas asumen la mayor parte del trabajo. Las personas de este tipo son alérgicas a los lavabos de tiempo abierto, por lo que tienden a ser alérgicas a las preguntas abiertas.
Es más probable que obtenga una respuesta útil si es explícito acerca de lo que quiere que hagan los encuestados (proporcione indicadores, envíe código, compruebe su parche, lo que sea. Esto enfocará su esfuerzo e implícitamente pondrá un límite superior en el tiempo y la energía que el encuestado debe asignar para ayudarlo. Esto es bueno.
Para entender el mundo en el que viven los expertos, piense en la experiencia como un recurso abundante y en el tiempo para responder como un recurso escaso. Cuanto menor sea el compromiso de tiempo que pida implícitamente, más probable es que obtenga una respuesta de alguien realmente bueno y muy ocupado.
Por lo tanto, es útil enmarcar su pregunta para reducir al mínimo el tiempo necesario para que un experto pueda responderla, pero a menudo esto no es lo mismo que simplificar la pregunta. Así, por ejemplo,»¿Me darías un puntero para una buena explicación de X?» es usualmente una pregunta más inteligente que»¿Me explicarías X, por favor?». Si tienes algún código que funciona mal, normalmente es más inteligente pedirle a alguien que te explique qué es lo que está mal que pedirle a alguien que lo arregle.
Al preguntar por el código
No pida a otros que depuren su código roto sin dar una pista de qué tipo de problema deberían estar buscando. Publicar unos cuantos cientos de líneas de código, diciendo «no funciona», hará que te ignoren. Publicar una docena de líneas de código, diciendo «después de la línea 7 esperaba ver
Si usted simplemente quiere una revisión de código, dígalo de antemano, y asegúrese de mencionar qué áreas cree que podrían necesitar una revisión y por qué.
No publique preguntas sobre la tarea
Los hackers son buenos para detectar las preguntas de la tarea; la mayoría de nosotros las hemos hecho nosotros mismos. Esas preguntas son para que usted las resuelva, para que aprenda de la experiencia. Está bien pedir pistas, pero no soluciones completas.
Si sospecha que le han pasado una pregunta de tarea, pero no puede resolverla de todos modos, intente preguntar en un foro de grupo de usuarios o (como último recurso) en una lista/foro de usuarios de un proyecto. Mientras los hackers lo detectan, algunos de los usuarios avanzados pueden al menos darte una pista.
Podar consultas inútiles
Resista la tentación de cerrar su solicitud de ayuda con preguntas semánticamente nulas como»¿Alguien puede ayudarme?» o»¿Hay una respuesta? Primero: si ha escrito la descripción de su problema de forma competente, tales preguntas son, en el mejor de los casos, superfluas. Segundo: porque son superfluos, los hackers los encuentran molestos? y es probable que devuelvan respuestas lógicamente impecables pero despectivas como»Sí, se te puede ayudar» y»No, no hay ayuda para ti».
En general, hacer preguntas de»sí o no» es algo bueno que debe evitar a menos que quiera una respuesta de»sí o no».
No marque su pregunta como»urgente», aunque sea para usted.
Ese es tu problema, no el nuestro. Afirmar la urgencia es muy probable que sea contraproducente: la mayoría de los hackers simplemente eliminan mensajes como intentos groseros y egoístas para obtener atención inmediata y especial.
Hay una semi-excepción. Puede valer la pena mencionar si usted está usando el programa en algún lugar de alto perfil, uno por el que los hackers se entusiasmen; en tal caso, si usted está bajo presión de tiempo, y usted lo dice cortésmente, la gente puede interesarse lo suficiente como para responder más rápido.
Esto es algo muy arriesgado, sin embargo, porque la métrica de los hackers para lo que es emocionante probablemente difiere de la suya. El envío desde la Estación Espacial Internacional calificaría, por ejemplo, pero el envío en nombre de una causa benéfica o política que se sienta bien, casi con toda seguridad no lo haría. De hecho, la publicación»Urgente: Ayúdame a salvar a las crías de foca» te hará ser rechazado o incendiado incluso por hackers que piensan que las crías de foca son importantes.
Si encuentras esto misterioso, relee el resto de este»cómo» repetidamente hasta que lo entiendas antes de publicar algo.
La cortesía nunca hace daño, y a veces ayuda.
Sea cortés. Usa»Por favor» y»Gracias por tu atención» o»Gracias por tu consideración». Deje en claro que aprecia el tiempo que la gente pasa ayudándole gratuitamente.
Para ser honesto, esto no es tan importante como (y no puede sustituir) ser gramatical, claro, preciso y descriptivo, evitando formatos propietarios, etc.; los hackers en general prefieren recibir informes de errores algo bruscos pero técnicamente agudos que vaguedades educadas. (Si esto te desconcierta, recuerda que valoramos una pregunta por lo que nos enseña.)
Sin embargo, si usted tiene sus patos técnicos en una fila, la cortesía aumenta sus posibilidades de obtener una respuesta útil.
(Debemos tener en cuenta que la única objeción seria que hemos recibido de hackers veteranos a este CÓMO es con respecto a nuestra recomendación anterior de usar»Gracias de antemano». Algunos hackers sienten que esto connota una intención de no agradecer a nadie después. Nuestra recomendación es que primero se diga»Gracias por adelantado» y después se agradezca a los encuestados, o que se exprese cortesía de una manera diferente, como por ejemplo diciendo»Gracias por su atención» o»Gracias por su consideración».)
Haga un seguimiento con una breve nota sobre la solución
Envíe una nota después de que el problema haya sido resuelto a todos los que le ayudaron; hágales saber cómo salió y agradézcales nuevamente por su ayuda. Si el problema atrajo el interés general en una lista de correo o grupo de noticias, es apropiado publicar el seguimiento allí.
De manera óptima, la respuesta debe ser al hilo iniciado por la publicación de la pregunta original, y debe tener»ARREGLADO»,»RESOLVIDO» o una etiqueta igualmente obvia en la línea de asunto. En las listas de correo con respuesta rápida, un encuestado potencial que ve un hilo acerca de»Problema X» que termina con»Problema X – ARREGLADO» sabe que no debe perder el tiempo incluso leyendo el hilo (a menos que encuentre el Problema X interesante) y, por lo tanto, puede utilizarlo para resolver un problema diferente.
Su seguimiento no tiene que ser largo y complicado; un simple»Hola» fue un cable de red fallido! Gracias a todos. – Bill? sería mejor que nada. De hecho, un resumen corto y dulce es mejor que una disertación larga, a menos que la solución tenga una profundidad técnica real. Diga qué acción resolvió el problema, pero no necesita repetir toda la secuencia de resolución de problemas.
Para problemas con cierta profundidad, es apropiado publicar un resumen del historial de solución de problemas. Describa el enunciado final del problema. Describa lo que funcionó como solución e indique los callejones sin salida que se pueden evitar. Los callejones sin salida deben ir tras la solución correcta y otros materiales de resumen, en lugar de convertir el seguimiento en una historia de detectives. Nombra los nombres de las personas que te ayudaron; así harás amigos.
Además de ser cortés e informativo, este tipo de seguimiento ayudará a otros a buscar en el archivo de la lista de correo/grupo de noticias/foro para saber exactamente qué solución le ayudó a usted y, por lo tanto, también puede ayudarles a ellos.
Por último, y no por ello menos importante, este tipo de seguimiento ayuda a todos los asistentes a tener una sensación satisfactoria de cierre del problema. Si usted no es un técnico o un hacker, confíe en nosotros que este sentimiento es muy importante para los gurús y expertos a los que recurrió en busca de ayuda. Las narraciones de problemas que se dirigen a la nada no resuelta son cosas frustrantes; los hackers se mueren por verlas resueltas. La buena voluntad que el rascado que pica te hace ganar te será de mucha, mucha ayuda la próxima vez que necesites hacer una pregunta.
Considere cómo podría evitar que otros tengan el mismo problema en el futuro. Pregúntese si un parche de documentación o de preguntas frecuentes le ayudaría, y si la respuesta es sí, envíe ese parche al encargado del mantenimiento.
Entre los hackers, este tipo de buen comportamiento de seguimiento es en realidad más importante que la cortesía convencional. Así es como se obtiene la reputación de jugar bien con los demás, lo que puede ser un activo muy valioso.
Cómo interpretar las respuestas
RTFM y STFW: Cómo saber si has metido la pata seriamente
Hay una tradición antigua y sagrada: si recibes una respuesta que dice»RTFM», la persona que lo envió piensa que deberías haber leído el Manual *******. Es casi seguro que él o ella tiene razón. Ve a leerlo.
La RTFM tiene un pariente más joven. Si recibes una respuesta que dice»STFW», la persona que lo envió piensa que deberías haber buscado en la página web de *******. Es casi seguro que él o ella tiene razón. Ve a buscarlo. (La versión más suave de esto es cuando te dicen que»Google es tu amigo»)
En los foros web, también se le puede pedir que busque en los archivos del foro. De hecho, alguien puede incluso ser tan amable como para proporcionar un puntero al hilo anterior donde se resolvió este problema. Pero no se fíe de esta consideración; haga su búsqueda de archivos antes de preguntar.
A menudo, la persona que le dice que haga una búsqueda tiene el manual o la página web con la información que necesita abrir, y la mira mientras escribe. Estas respuestas significan que él piensa (a) que la información que usted necesita es fácil de encontrar, y (b) que usted aprenderá más si busca la información que si se la da con una cuchara.
Esto no debe ofenderlo; según los estándares de los hackers, su encuestado le está mostrando un tipo aproximado de respeto simplemente por no ignorarlo. Deberías estar agradecido por esta amabilidad de la abuela.
Si no entiendes…
Si no entiende la respuesta, no devuelva inmediatamente una solicitud de aclaración. Utilice las mismas herramientas que utilizó para intentar responder a su pregunta original (manuales, preguntas frecuentes, la Web, amigos expertos) para entender la respuesta. Luego, si todavía necesita pedir aclaraciones, muestre lo que ha aprendido.
Por ejemplo, supongamos que te lo digo: «Suena como si tuvieras un zentry atascado; necesitarás despejarlo. Entonces: aquí hay una mala pregunta de seguimiento:»¿Qué es un centinela? He aquí una buena pregunta de seguimiento: ?OK, he leído la página de manual y los zentries sólo se mencionan bajo los interruptores -z y -p. Ninguno de los dos dice nada sobre despejar los centinelas. ¿Es uno de estos o me estoy perdiendo algo aquí?
Lidiando con la grosería
Mucho de lo que parece grosería en los círculos de hackers no tiene la intención de ofender. Más bien, es el producto del estilo de comunicación directo y directo que es natural para las personas que están más preocupadas por resolver problemas que por hacer que los demás se sientan cálidos y confusos.
Cuando perciba la grosería, trate de reaccionar con calma. Si alguien está realmente actuando, es muy probable que una persona mayor en la lista o grupo de noticias o foro lo llame a él o ella. Si eso no sucede y pierdes los estribos, es probable que la persona con la que lo pierdes se esté comportando dentro de las normas de la comunidad hacker y serás considerado culpable. Esto perjudicará sus posibilidades de obtener la información o la ayuda que desea.
Por otro lado, ocasionalmente te encontrarás con rudezas y posturas que son bastante gratuitas. La otra cara de la moneda de lo anterior es que es una forma aceptable de golpear a los verdaderos delincuentes con bastante fuerza, diseccionando su mala conducta con un bisturí verbal agudo. Sin embargo, esté muy, muy seguro de su terreno antes de intentarlo. La línea entre la corrección de una incivilidad y el inicio de una guerra de llamas sin sentido es lo suficientemente delgada como para que los propios hackers se equivoquen con frecuencia; si eres un novato o un forastero, tus posibilidades de evitar un error de este tipo son bajas. Si buscas información en lugar de entretenimiento, es mejor no tocar el teclado que arriesgarte a hacerlo.
(Algunas personas afirman que muchos hackers tienen una forma leve de autismo o Síndrome de Asperger, y que en realidad carecen de algunos de los circuitos cerebrales que lubrican la interacción social humana»normal». Esto puede o no ser cierto. Si usted no es un hacker, puede ayudarle a hacer frente a nuestras excentricidades si piensa que tenemos daños cerebrales. Adelante, adelante. No nos importará; nos gusta ser lo que somos, y generalmente tenemos un sano escepticismo sobre las etiquetas clínicas.)
En la siguiente sección, hablaremos de un tema diferente; el tipo de»grosería» que verás cuando te portes mal.
Sobre no reaccionar como un perdedor
Lo más probable es que la cagues unas cuantas veces en los foros de la comunidad de hackers? de la forma que se detalla en este artículo, o algo similar. Y se te dirá exactamente cómo la has cagado, posiblemente con un lado colorido. En público.
Cuando esto sucede, lo peor que puedes hacer es quejarte de la experiencia, decir que has sido agredido verbalmente, pedir disculpas, gritar, aguantar la respiración, amenazar con demandas, quejarte a los empleadores de la gente, dejar la tapa del inodoro levantada, etc. En cambio, esto es lo que harás:
Supéralo. Es normal. Es normal. De hecho, es saludable y apropiado.
Las normas comunitarias no se mantienen por sí solas: Son mantenidas por personas que las aplican activamente, visiblemente, en público. No te quejes de que todas las críticas deberían haber sido transmitidas por correo electrónico privado: Así no es como funciona. Tampoco es útil insistir en que usted ha sido insultado personalmente cuando alguien comenta que uno de sus reclamos estaba equivocado, o que sus puntos de vista difieren. Esas son actitudes de perdedor.
Ha habido foros de hackers en los que, por un sentido erróneo de hipercortesía, se prohíbe a los participantes publicar cualquier fallo en los mensajes de otros, y se les dice: «No digas nada si no estás dispuesto a ayudar al usuario». La consiguiente partida de participantes despistados a otra parte hace que desciendan en balbuceos sin sentido y se conviertan en foros técnicos inútiles.
Exageradamente»amigable». (de esa manera) o útil: Elige uno.
Recuerda: Cuando ese hacker te dice que la has cagado, y (no importa cuán bruscamente) te dice que no lo vuelvas a hacer, está actuando por preocupación por (1) ti y (2) su comunidad. Sería mucho más fácil para él ignorarte y filtrarte de su vida. Si no puedes ser agradecido, al menos ten un poco de dignidad, no te quejes, y no esperes ser tratado como una muñeca frágil sólo porque eres un recién llegado con un alma teatralmente hipersensible y delirios de derecho.
A veces la gente te atacará personalmente, se encenderá sin una razón aparente, etc., incluso si no la cagas (o sólo la cagas en su imaginación. En este caso, quejarse es la manera de meter la pata.
Estos flamers son o bien lamers que no tienen ni idea pero que se creen expertos, o psicólogos potenciales que están probando si usted la va a cagar. Los otros lectores los ignoran o encuentran maneras de lidiar con ellos por su cuenta. El comportamiento de los flamencos crea problemas para ellos mismos, que no tienen por qué preocuparte.
No te dejes arrastrar por una guerra de llamas, tampoco. La mayoría de las llamas son mejor ignoradas? después de que hayas comprobado si realmente son llamas, no indicadores de las maneras en las que has metido la pata, y no respuestas inteligentemente cifradas a tu pregunta real (esto también sucede.
Preguntas que no se deben hacer
Aquí hay algunas preguntas estúpidas clásicas, y lo que los hackers están pensando cuando no las contestan.
P: ¿Dónde puedo encontrar el programa o recurso X?
P: ¿Cómo puedo usar X para hacer Y?
P: ¿Cómo puedo configurar el intérprete de comandos de mi shell?
P: ¿Puedo convertir un documento de AcmeCorp en un archivo TeX usando el conversor de archivos Bass-o-matic?
P: Mi {programa, configuración, sentencia SQL} no funciona
P: Tengo problemas con mi máquina Windows. ¿Puedes ayudarme?
P: Mi programa no funciona. Creo que la instalación del sistema X está rota.
P: Tengo problemas para instalar Linux o X. ¿Pueden ayudarme?
P: ¿Cómo puedo descifrar privilegios de root/robo de channel-ops/leer el correo electrónico de alguien?
Q:
¿Dónde puedo encontrar el programa o recurso X?
A:
El mismo lugar donde lo encontraría, tonto? al otro lado de una búsqueda en la web. Ghod, ¿todavía no saben usar Google?
Q:
¿Cómo puedo usar X para hacer Y?
A:
Si lo que quiere es hacer Y, debe hacer esa pregunta sin suponer previamente el uso de un método que puede no ser apropiado. Las preguntas de este formulario a menudo indican a una persona que no es meramente ignorante acerca de X, sino que está confundida acerca de qué problema Y está resolviendo y demasiado obsesionada con los detalles de su situación particular. Por lo general, es mejor ignorar a estas personas hasta que definan mejor su problema.
Q:
¿Cómo puedo configurar el intérprete de comandos de mi shell?
A:
Si eres lo suficientemente inteligente para hacer esta pregunta, eres lo suficientemente inteligente para RTFM y averiguarlo por ti mismo.
Q:
¿Puedo convertir un documento de AcmeCorp en un archivo TeX usando el conversor de archivos Bass-o-matic?
A:
Pruébalo y verás. Si lo hicieras, (a) aprenderías la respuesta, y (b) dejarías de hacerme perder el tiempo.
Q:
Mi {programa, configuración, sentencia SQL} no funciona
A:
Esta no es una pregunta, y no estoy interesado en jugar a las Veinte Preguntas para sacarte tu pregunta real? Tengo mejores cosas que hacer. Al ver algo así, mi reacción es normalmente de una de las siguientes:
¿tienes algo más que añadir a eso?
Oh, que mal, espero que lo arregle.
y esto tiene exactamente que ver conmigo?
Q:
Tengo problemas con mi máquina Windows. ¿Puedes ayudarme?
A:
Sí, tira esa basura de Microsoft e instala un sistema operativo de código abierto como Linux o BSD.
Nota: puede hacer preguntas relacionadas con los equipos de Windows si se trata de un programa que tiene una versión oficial de Windows, o si interactúa con equipos de Windows (por ejemplo, Samba. Simplemente no se sorprenda por la respuesta de que el problema es con Windows y no con el programa, porque Windows está tan roto en general que este es el caso muy a menudo.
Q:
Mi programa no funciona. Creo que la instalación del sistema X está rota.
A:
Si bien es posible que usted sea la primera persona en notar una deficiencia obvia en las llamadas y bibliotecas del sistema utilizadas por cientos o miles de personas, es más probable que no tenga ni idea. Las reclamaciones extraordinarias requieren pruebas extraordinarias; cuando usted hace una reclamación como ésta, debe respaldarla con documentación clara y exhaustiva del caso de fracaso.
Q:
Tengo problemas para instalar Linux o X. ¿Pueden ayudarme?
A:
No. Necesitaría acceso práctico a su máquina para solucionar esto. Vaya a pedir ayuda práctica a su grupo de usuarios de Linux local. (Puede encontrar una lista de grupos de usuarios aquí.)
Nota: las preguntas sobre la instalación de Linux pueden ser apropiadas si está en un foro o lista de correo sobre una distribución en particular, y el problema es con esa distribución; o en foros de grupos de usuarios locales. En este caso, asegúrese de describir los detalles exactos de la falla. Pero primero haga una búsqueda cuidadosa, con «linux» y todas las piezas de hardware sospechosas.
Q:
¿Cómo puedo descifrar privilegios de root/robo de channel-ops/leer el correo electrónico de alguien?
A:
Eres un delincuente por querer hacer esas cosas y un imbécil por pedirle a un hacker que te ayude.
Preguntas buenas y malas
Finalmente, voy a ilustrar cómo hacer preguntas de una manera inteligente con el ejemplo; pares de preguntas sobre el mismo problema, una hecha de una manera estúpida y otra de una manera inteligente.
Estúpido: ¿Dónde puedo encontrar información sobre el Foonly Flurbamatic?
Esta pregunta sólo pide «STFW» como respuesta.
Inteligente: Usé Google para tratar de encontrar»Foonly Flurbamatic 2600″ en la Web, pero no obtuve resultados útiles. ¿Puedo obtener un indicador de información de programación en este dispositivo?
Este ya tiene STFWed, y suena como si tuviera un problema real.
Estúpido: No puedo conseguir el código del proyecto foo para compilar. ¿Por qué está roto?
La pregunta asume que alguien más metió la pata. Arrogante imbécil…
Inteligente: El código del proyecto foo no se compila bajo la versión 6.2 de Nulix. He leído el FAQ, pero no tiene nada que ver con los problemas relacionados con Nulix. Aquí hay una transcripción de mi intento de compilación; ¿es algo que hice?
El querent ha especificado el entorno, ha leído las FAQ, está mostrando el error, y no está asumiendo que sus problemas son culpa de otra persona. Este podría valer algo de atención.
Estúpido: Tengo problemas con mi placa madre. ¿Alguien puede ayudar?
J. Es probable que la respuesta de Random Hacker a esto sea:»Correcto. ¿Necesitas eructar y cambiar pañales, también? seguido de un golpe de la tecla de borrar.
Inteligente: Probé X, Y y Z en la placa madre S2464. Cuando eso no funcionó, probé A, B y C. Noten el curioso síntoma cuando probé C. Obviamente, el florecimiento se está estropeando, pero los resultados no son los que uno podría esperar. ¿Cuáles son las causas habituales del grommicking en las placas base Athlon MP? ¿Alguien tiene ideas para más pruebas que pueda hacer para determinar el problema?
Esta persona, por otra parte, parece merecedora de una respuesta. Ha mostrado inteligencia para resolver problemas en lugar de esperar pasivamente a que la respuesta caiga de lo alto.
En la última pregunta, nota la sutil pero importante diferencia entre exigir»Dame una respuesta» y»Por favor, ayúdame a averiguar qué diagnósticos adicionales puedo hacer para lograr la iluminación».
De hecho, la forma de esta última pregunta se basa en un incidente real que ocurrió en agosto de 2001 en la lista de correo linux-kernel (lkml. Yo (Eric) fui el que hizo la pregunta esa vez. Estaba viendo misteriosas cerraduras en una placa madre Tyan S2462. Los miembros de la lista me proporcionaron la información crítica que necesitaba para resolverlos.
Al hacer la pregunta de la manera en que lo hice, le di a la gente algo que masticar; hice que fuera fácil y atractivo para ellos involucrarse. Demostré respeto por la capacidad de mis compañeros y los invité a que me consultaran como compañero. También demostré respeto por el valor de su tiempo al contarles los callejones sin salida que ya había recorrido.
Después, cuando agradecí a todos y comenté lo bien que había funcionado el proceso, un miembro de lkml observó que pensaba que había funcionado no porque yo fuera un»nombre» en esa lista, sino porque hice la pregunta en la forma correcta.
Los hackers son en cierto modo una meritocracia muy despiadada; estoy seguro de que tenía razón, y que si me hubiera comportado como una esponja me habría quemado o ignorado sin importar quién fuera yo. Su sugerencia de que escribiera todo el incidente como instrucción para los demás condujo directamente a la composición de esta guía.
Si no puede obtener una respuesta
Si no puede obtener una respuesta, por favor no se tome a pecho que no sentimos que podemos ayudarle. A veces los miembros del grupo pueden simplemente no saber la respuesta. No responder no es lo mismo que ser ignorado, aunque hay que reconocer que es difícil detectar la diferencia desde fuera.
En general, simplemente re-publicar su pregunta es una mala idea. Esto será visto como una molestia inútil. Tenga paciencia: la persona con su respuesta puede estar en una zona horaria diferente y dormida. O puede ser que su pregunta no estaba bien formada para empezar.
Hay otras fuentes de ayuda a las que puede acudir, a menudo fuentes mejor adaptadas a las necesidades de un principiante.
Hay muchos grupos de usuarios locales y en línea que son entusiastas del software, aunque es posible que nunca hayan escrito ningún software por sí mismos. Estos grupos a menudo se forman para que las personas puedan ayudarse entre sí y ayudar a los nuevos usuarios.
También hay muchas compañías comerciales con las que puede contratar ayuda, tanto grandes como pequeñas (Red Hat y SpikeSource son dos de las más conocidas; hay muchas otras. No se preocupe por la idea de tener que pagar por un poco de ayuda! Después de todo, si el motor de su automóvil explota una junta de culata, lo más probable es que la lleve a un taller de reparaciones y pague para que la reparen. Incluso si el software no le costó nada, no puede esperar que el soporte siempre sea gratuito.
Para software popular como Linux, hay al menos 10.000 usuarios por desarrollador. Simplemente no es posible que una persona pueda manejar las llamadas de soporte de más de 10.000 usuarios. Recuerde que incluso si tiene que pagar por el soporte, todavía está pagando mucho menos que si tuviera que comprar el software también (y el soporte para software de código cerrado suele ser más caro y menos competente que el soporte para software de código abierto.
Cómo responder a las preguntas de una manera úti
l
Sé gentil. El estrés relacionado con los problemas puede hacer que las personas parezcan groseras o estúpidas incluso cuando no lo son.
Responder a un primer infractor fuera de línea. No hay necesidad de humillación pública para alguien que pudo haber cometido un error honesto. Es posible que un novato real no sepa cómo buscar en los archivos o dónde se almacenan o publican las preguntas frecuentes.
Si no lo sabes con seguridad, ¡dilo! Una respuesta errónea pero con un sonido autoritario es peor que ninguna. No guíe a nadie por el camino equivocado simplemente porque es divertido sonar como un experto. Sea humilde y honesto; dé un buen ejemplo tanto a los que preguntan como a sus compañeros.
Si no puedes ayudar, no molestes. No haga bromas sobre procedimientos que podrían arruinar la configuración del usuario? el pobre inocente podría interpretarlos como instrucciones.
Haga preguntas de sondeo para obtener más detalles. Si eres bueno en esto, el consultor aprenderá algo? y tú también lo harás. Trate de convertir la pregunta mala en una buena; recuerde que todos fuimos novatos alguna vez.
Aunque a veces está justificado murmurar RTFM cuando se responde a alguien que es un vago perezoso, un puntero a la documentación (incluso si sólo es una sugerencia para buscar en Google una frase clave) es mejor.
Si vas a responder a la pregunta, dale un buen valor. No sugiera soluciones poco convincentes cuando alguien está usando la herramienta o el enfoque equivocado. Sugiera buenas herramientas. Vuelva a formular la pregunta.
Ayude a su comunidad a aprender de la pregunta. Cuando responda a una buena pregunta, pregúntese:»¿Cómo tendría que cambiar la documentación o las preguntas más frecuentes para que nadie tenga que volver a responderla? A continuación, envíe un parche al mantenedor de documentos.
Si investigó para responder a la pregunta, demuestre sus habilidades en lugar de escribir como si se hubiera sacado la respuesta del trasero. Responder a una buena pregunta es como alimentar a una persona hambrienta con una comida, pero enseñarles a investigar con el ejemplo es mostrarles cómo cultivar alimentos para toda la vida.
Recursos relacionado
s
Si necesita instrucción en lo básico de cómo funcionan las computadoras personales, Unix e Internet, vea El Unix y Fundamentos de Internet CÓMO.
Cuando libere software o escriba parches para el software, intente seguir las directrices de la Práctica de Liberación de Software HOWTO.
Agradecimientos
Evelyn Mitchell contribuyó con algunos ejemplos de preguntas estúpidas e inspiró la sección»Cómo dar una buena respuesta». Mikhail Ramendik contribuyó con algunas sugerencias de mejora particularmente valiosas.
El sitio Myspace debe estar en la lista negra y como tal bloqueado por el personal de TI de la escuela. Si quieres entrar en este sitio web mientras estás en la escuela, necesitas más que la contraseña de alguien, necesitas un ordenador separado, preferiblemente un NB y una conexión inalámbrica de banda ancha para entrar en ese sitio web y no vas a ningún sitio cerca del sistema informático de la escuela.
Col
0Votos Compartir Bandera