El siguiente artículo fué originalmente escrito para una lista de correo, pero muchas de sus recomendaciones se pueden aplicar perfectamente a este foro.
SoloCodigo
Cómo hacer preguntas de forma inteligente (How To Ask Questions The Smart Way)
Copyright © 2001 by Eric S. Raymond
Traducido al español por Fernando Ramos (Febrero 2002)
--------------------------------------------------------------------------------
Tabla de contenidos
Traducciones
Introducción
Antes de preguntar
Cuando pregunte
Cómo interpretar las respuestas
No reaccione como un perdedor
Preguntas que no se hacen
Preguntas buenas y malas
Si no puede obtener una respuesta
Recursos relacionados
--------------------------------------------------------------------------------
TraduccionesEste documento fué escrito originalmente en Inglés por Eric S. Raymond. Mi traducción es un punto de vista personal; si tiene alguna duda lo invito a referirse al original en inglés en la siguiente URL:
http://www.tuxedo.org/~esr/faqs/smart-questions.htmlExisten traducciones de este documento disponibles en Alemán y en Francés.
--------------------------------------------------------------------------------
IntroducciónEn el mundo de los "hackers", la clase de respuestas que usted obtiene a sus preguntas técnicas depende tanto de la forma en que hace sus preguntas como de la dificultad de desarrollar una respuesta. Esta guía le enseñará como hacer preguntas de una forma que probablemente le conseguirá una respuesta satisfactoria.
Lo primero que debe entender es que a los "hackers" realmente les gustan los problemas difíciles y las buenas preguntas, que inviten a pensar. Si no nos gustaran no estaríamos aquí. Si se nos dá una pregunta interesante para pensar les estaremos agradecidos; las buenas preguntas son un estímulo y un regalo. Las buenas preguntas nos ayudan a desarrollar nuestro entendimiento, y frecuentemente revelan problemas que podrían no haber sido detectados de otra manera. Entre los "hackers", "Buena pregunta!" es un cumplido fuerte y sincero.
A pesar de esto, los "hackers" tienen una reputación de responder a preguntas simples con lo que parece una mezcla de hostilidad y arrogancia. A veces parece que somos reflexivamente rudos con los novatos y los ignorantes. Pero esto no es realmente cierto.
Los que somos, sin disculparnos, es hostiles hacia gente que parece no querer pensar o hacer su propia tarea antes de formular sus preguntas. Gente así son una pérdida de tiempo - toman sin devolver, ellos gastan tiempo que podríamos haber empleado en otra pregunta más interesante y en otra persona más merecedora de una respuesta. Llamamos a esta gente fracasados.
Nota del traductor: (El autor usa el término "losers" originalmente en inglés).
Nos damos cuenta que hay mucha gente que solamente quiere utilizar el software que nosotros escribimos y que no tienen interés en aprender los detalles técnicos. Para la mayoría de la gente, un computador es solamente una herramienta, un medio hacia un fin; tienen cosas más importantes que hacer en la vida. Reconocemos este hecho y no esperamos que todo el mundo se interese en los detalles técnicos que nos fascinan. Sin embargo, nuestro estilo de responder preguntas está afinado para gente que tiene estos intereses y que están dispuestos a convertirse en participantes activos al solucionar problemas. Eso no vá a cambiar. No debería; si lo hiciera, seríamos menos efectivos en las cosas que mejor sabemos hacer.
Somos (en gran parte) voluntarios. Sacamos tiempo de nuestras ocupadas vidas para contestar preguntas, y a veces estamos sobrecargados de ellas. Así que filtramos sin piedad. En particular, eliminamos preguntas de gente que parecen ser fracasados para poder utilizar nuestro tiempo respondiendo preguntas más eficientemente, de ganadores.
Si usted considera esta actitud como odiosa, condescendiente o arrogante, verifique sus asunciones. No le pedimos que se arrodille ante nosotros - de hecho, la mayoría de nosotros nos encantaría poderlo tratar de igual a igual y darle la bienvenida en nuestra cultura, si usted pone el esfuerzo requerido para hacer eso posible. Pero sencillamente no es eficiente para nosotros el tratar de ayudar a gente que no está dispuesta a ayudarse a si misma. Si usted no pueded vivir con esta clase de discriminación, le sugerimos que le pague a alguien por un contrato de soporte técnico comercial en lugar de pedirle a los "hackers" que donen su tiempo personal para ayudarle.
Si usted decide pedir nuestra ayuda, no queremos que sea uno de los fracasados. La mejor forma de obtener una respuesta rápida y sensible, es hacerla como un ganador - hacer la pregunta como una persona con la inteligencia, la confianza y las pistas necesarias, que simplemente sucede que necesita ayuda con un problema en particular.
(Las mejoras a esta guía son bienvenidas. Usted puede enviar sugerencias a
ferchor2001@cox.net es español. Note sin embargo que este documento no intenta ser una guía general de "netiquette", y que generalmente rechazaré sugerencias que no sean específicamente relacionadas a producir respuestas útiles en un foro técnico.)
--------------------------------------------------------------------------------
Antes de preguntarAntes de hacer una pregunta técnica por email, o en un grupo de noticias, o en un sitio de charla de un sitio web, haga lo siguiente:
Trate de encontrar una respuesta leyendo el manual.
Trate de encontrar una respuesta leyendo un FAQ (Frequently Answered Questions - Preguntas contestadas frecuentemente )
Trate de encontrar una respuesta buscando en la web
Trate de encontrar una respuesta preguntándole a un amigo calificado
Cuando haga su pregunta, muestre el hecho de que ya ha hecho estas cosas; esto ayudará a establecer que usted no es una esponja perezosa y que está malgastando el tiempo de la gente. Mejor todavía, muestre lo que ya ha aprendido haciendo estas cosas. Nos gusta contestar preguntas de gente que ha demostrado que pueden aprender de las respuestas.
Prepare su pregunta. Piénsela bien. Preguntas apresuradas reciben respuestas apresuradas o ninguna respuesta. Entre mejor demuestre que usted ha pensado su pregunta y ha hecho un esfuerzo en solucionar su problema antes de pedir ayuda, mejores las posibilidades de que obtenga esa ayuda.
Tenga cuidado de hacer preguntas incorrectas. Si hace una pregunta basada en suposiciones incorrectas, Fulano Hacker probablemente responderá con una respuesta textual mientras piensa "Que pregunta estúpida...", y espera que la experiencia de obtener lo que ha pedido en lugar de lo que necesitaba le enseñe una lección.
Nunca asuma que usted tiene derecho a una respuesta. No lo tiene; después de todo, usted no está pagando por el servicio. Usted se ganará una respuesta, si se la gana, haciendo una pregunta que es sustancial, interesante y que hace pensar - una pregunta que implícitamente contribuye a la experiencia de la comunidad en lugar de meramente demandar de forma pasiva el conocimiento de otros.
Por otro lado, el hacer claro el que usted es capaz y está está dispuesto a ayudar en el proceso de desarrollar una solución es un muy buen comienzo. "Alguien puede proveer una pista?", "Qué hace falta en mi ejemplo?" y "Hay algún sitio que valga la pena chequear?" tienen mejores posibilidades de ser respondidos que "Por favor describa el procedimiento exacto que debo usar." por que está dejando en claro que usted está dispuesto a completar el proceso si sencillamente alguien le orienta en la dirección correcta.
--------------------------------------------------------------------------------
Cuando pregunteEscoja su foro cuidadosamente.
Sea sensitivo al escoger en dónde hace su pregunta. Usted probablemente será ignorado, o tachado de fracasado, si usted:
Envía su pregunta a un foro donde está fuera de contexto (off topic)
Envía una pregunta elemental a un foro donde se esperan preguntas técnicas avanzadas, o viceversa.
Envía su pregunta atravezada a demasiados grupos de noticias diferentes.
Los "hackers" eliminan los preguntas que están dirigidas inapropiadamente para tratar de proteger sus canales de comunicación de sumergirse en la irrelevancia. Usted no quisiera que esto le pasara.
En general, las preguntas a un foro público bien seleccionado tienen más posibilidades de obtener respuestas útiles que las preguntas equivalente en un foro privado. Hay múltiples razones para esto. Una de ellas es sencillamente el tamaño del grupo de posibles conocedores que responderán. Otra es el tamaño de la audiencia; los "hackers" prefieren responder unas pocas preguntas que eduquen a mucha gente que preguntas que solo beneficien a unos pocos.
--------------------------------------------------------------------------------
Siempre que sea posible, use las listas de correo del proyecto.
Cuando un proyecto tienen una lista de correo de desarrollo, escriba a la lista de correo, no a los desarrolladores individuales, inclusive si usted sabe quien puede responder mejor a su pregunta. Chequee la documentación del proyecto y su homepage buscando la dirección de la lista de correo y úsela. Hay varias razones para esta política:
Una pregunta que es lo suficientemente buena para ser hecha por un desarrollador también será de valor para el grupo entero. Por el contrario, si usted cree que su pregunta es demasiado tonta para la lista de correo, no es una excusa para acosar a desarrolladores individuales.
El hacer preguntas a la lista distribuye la carga entre los desarrolladores. El desarrollador individual (especialmente si es el líder del proyecto) puede estar demasiado ocupado para contestar sus preguntas.
La mayoría de las listas de correo son archivadas y los archivos son indexados por máquinas de búsqueda. Alguien puede encontrar su pregunta y la respuesta en la web en lugar de hacer de nuevo la pregunta en la lista.
Si existen ciertas preguntas que se observa que son hechas frecuentemente, los desarrolladores pueden usar esa información para mejorar la documentación o el software mismo y hacerlo menos confuso. Pero si esas mismas preguntas se hacen en privado, nadie tiene una visión completa de las preguntas que se hacen más frecuentemente.
Si usted no puede encontrar la lista de correo de un proyecto, y solo ve la dirección del mantenedor del proyecto, adelante, escríbale al mantenedor. Pero inclusive en ese caso, no asuma que la lista de correo no existe. Diga en su email que usted intentó y no pudo encontrar la lista de correo apropiada. También mencione que no importa que su mensaje sea re-enviado a otras personas. (Mucha gente cree que el email privado debe permanecer privado, inclusive si no hay nada secreto en el. Al permitir que su mensaje sea reenviado usted le da a escoger a su corresponsal el cómo manejar su email.)
--------------------------------------------------------------------------------
Escriba usando un lenguaje claro, con buena ortografía y normas gramaticales.
Hemos encontrado por experiencia que la gente que es negligente y descuidada al escribir es también negligente y descuidada pensando y escribiendo código ( lo suficiente como para apostar al respecto, por lo menos). El responder preguntas a gente negligente y descuidada no es gratificante; preferimos gastar nuestro tiempo en otro lado.
Asi que expresar su pregunta de forma clara y correcta es importante. Si no se le puede molestar para que haga eso, nostros no podemos ser molestados para ponerle atención. Haga un esfuerzo extra en pulir su vocabulario. No tiene que ser acartonado o demasiado formal - de hecho, la cultura "hacker" valora el lenguaje informal, en un argot técnico y humorístico usado con precisión. Pero debe ser preciso; tiene que haber una indicación de que usted está pensando y poniendo atención a lo que hace.
Use buena ortografía y buena puntuación. No utilice abreviaturas confusas. NO ESCRIBA TODO EN MAYUSCULAS, esto se lee como si gritara y es considerado descortés. (Todo en minúsculas es sólo un poco menos molesto, puesto que es difícil de leer. Alan Cox - el gran "hacker" de Linux - se sale con la suya, pero usted no lo hará.)
De forma más general, si usted escribe como un semi-analfabeta será ignorado casi con seguridad. El escribir como un "script kiddie" (un hacker-niño molesto que no conoce los hackers verdaderos) es el verdadero beso de despedida y le garantiza que no recibirá más que silencio pétreo ( o si le va bien, un buen sarcasmo y muestras de desprecio).
Si hace preguntas en un foro que no usa su idioma nativo, usted tendrá una cantidad limitada de espacio para errores ortográficos y gramaticales - pero ningún espacio para la pereza ( y si, generalmente nos damos cuenta de la diferencia ). Además, a menos que usted conozca quienes son sus corresponsales, escriba en Inglés. Los "hackers" ocupados simplemente eliminan preguntas en idiomas que no entienden y el inglés es el idioma de trabajo de la internet. Al escribir en inglés usted elimina las posibilidades de que su pregunta sea descartada sin leer.
--------------------------------------------------------------------------------
Envíe preguntas en formatos que sean fáciles de entender
Si usted hace su pregunta artificialmente difícil de leer, es más probable que sea pasada por alto a favor de otra que no lo sea. Asi que:
Envíe texto plano, no HTML. ( No es difícil desactivar el envío de HTML )
Los anexos MIME están bien generalmente, pero sólo si tienen un contenido real ( como un archivo fuente anexado o un parche ), y no son sólamente un formato generado por su cliente de correo (como otra copia de su mensaje).
No envíe email en el que párrafos enteros son una sola línea que se ajusta a los márgenes. (Esto hace demasiado difícil el responder solo a parte del mensaje). Asuma que sus corresponsales leerán el correo en una pantalla de texto de 80 caracteres y ajuste la longitud de sus lineas a algún valor menor que 80.
No envíe texto MIME codificado con comillas (MIME Quoted-Printable encoding) a un foro de idioma inglés. Esta codificación puede ser necesaria cuando usted está enviando en un idioma que ASCII no cubre en su totalidad, pero muchos agentes de e-mail no lo soportan. Cuando se dañan, todos esos jeroglíficos =20 distribuidos por el texto son feos y distraen.
Nunca, jamás espere que los "hackers" sean capaces de leer documentos en formatos propietarios y cerrados como Microsoft Word. La mayoría de los "hackers" tienen la misma reacción ante esto a tener una posta de estiércol de cerdo en la entrada de la casa.
Si está enviando correo desde una máquina Windows, elimine la característica estúpida de "Smart Quotes". Esto es para evitar el salpicar con caracteres basura todo su correo.
Si está usando un cliente de correo con interfaz gráfica, (como Netscape Messenger, MS Outlook, o esa calaña) dése cuenta que puede estar violando estas reglas cuando son usados con sus opciones por defecto. La mayoría de esos clientes tienen un comando de menú para "Ver fuente". Use esta opción en algo que esté en su folder de salida para verificar que está enviando texto plano sin esa capa de suciedad innecesaria.
--------------------------------------------------------------------------------
Use encabezados específicos, con significado
En las lista de correo o grupos de noticias, el encabezado es su oportunidad dorada para atraer la atención de expertos calificados en unos 50 caracteres o menos. No la desperdicie con babosadas como "Ayuda por favor!" (mucho menos "AYUDA POR FAVOR!!!!"); los mensajes con encabezados como estos son descartados por reflejo. No nos trate de impresionar con la profundidad de su angustia; utilice el espacio para una descripción super-concisa del problema.
Una buena convención para los encabezados, usada por muchas organizaciones de soporte técnico es "objeto - desviación". La parte del "objeto" especifica que cosa o grupo de cosas tiene el problema y la "desviación" describe la desviación del comportamiento esperado.
Estúpido:
AYUDA! El video no funciona bien en mi laptop!
Inteligente:
XFree86 4.1 deforma el cursor del mouse, chipset de video MarcaX ref. MV1005
Más inteligente:
Cursor del mouse en XFree86 4.1 en chipset de video MV1005 Marca X - Luce deformado
El proceso de escribir una descripción del "objeto-desviación" le ayudará a organizar sus ideas acerca del problema en más detalle. Qué ha sido afectado? Solo el cursor del mouse o lo otros gráficos también? Es esto específico a XFree86? A la versión 4.1? Es esto específico a los chipsets de video MarcaX? Al modelo MV1005? Un hacker que vea el resultado puede inmediatamente entender con qué está teniendo el problema y la naturaleza del mismo a primera vista.
Si hace una pregunta en un email que responde otra pregunta, asegúrese de cambiar el encabezado para indicar que está haciendo una pregunta. Un encabezado como "Re: test" o "Re: nuevo problema" tiene menos probabilidades de atraer la atención. Igualmente, elimine las comillas de mensajes previos a un mínimo consistente para dar pistas a los nuevos lectores.
--------------------------------------------------------------------------------
Sea preciso e informativo acerca de su problema
Describa los síntomas de su "bug" o problema de forma clara y cuidadosa.
Describa el ambiente en el cual ocurre. (máquina, sistema operativo, aplicación, etc. )
Describa la investigación que usted ha hecho para tratar de entender el problema antes de que que hiciera la pregunta.
Describa los pasos de diagnóstico que tomó para tratar de identificar con exactitud el problema antes de lanzar la pregunta.
Describa cambios recientes en su computador o configuración de software que puedan ser relevantes.
Haga lo mejor que pueda para anticiparse a las preguntas que un "hacker" hará y contéstelas por anticipado en su petición de ayuda.
Simon Tatham ha escrito un excelente tratado titulado "How to Report Bugs Effectively" (Como reportar bugs eficientemente). Le recomiendo encarecidamente que lo lea.
--------------------------------------------------------------------------------
El volumen no es precisión
Usted necesita ser preciso e informativo. No se consigue esto simplemente botando enormes cantidades de código o datos en una petición de ayuda. Si usted tiene un caso de prueba grande y complicado que está dañando su programa, trate de recortarlo y hacerlo tan pequeño como sea posible.
Esto es útil por 3 razones por lo menos. Primera: El ser visto invirtiendo esfuerzo en simplificar la pregunta hace que sea más probable el que obtenga una respuesta. Segundo: El simplificar la pregunta hace más probable que obtenga una respuesta útil. Tercero: En el proceso de refinar el reporte del fallo usted puede desarrollar la solución usted mismo.
--------------------------------------------------------------------------------
Describa los síntomas del problema, no lo que usted cree que pasa
No es útil decirle a los "hackers" lo que usted cree que está causando el problema. (Si sus historias de diagnóstico fueran de verdad buenas, estaría pidiéndole ayuda a otros?) Asi que, asegurese de decirles los síntomas puros de lo que está fallando, en lugar de sus interpretaciones y teorías. Deje que ellos hagan la interpretación y el diagnóstico.
Estúpido:
Estoy obteniendo cantidades de errores SIG11 al compilar el kernel y sospecho que el motherboard se rayó al instalarlo. Cual es la mejor forma de chequear esto?
Inteligente:
Tengo un equipo K6/233 con una motherboard FIC-PA2007 (chipset Apollo VIA VP2 ) con 256 Mb de memoria Corsair SDRAM PC133. Empiezo a recibir errores SIG11 unos 20 minutos después de prender el equipo, más precisamente al compilar el kernel, pero nunca en los primeros 20 minutos. Al reiniciar el computador no se reinicia el reloj, pero al apagarlo por la noche si se reinicia. El cambiar toda la RAM no ayudó. Incluyo la parte relevante de una sesión típica de compilación.
--------------------------------------------------------------------------------
Describa los sintomas de su problema en orden cronológico
Las pistas más útiles al descubrir algo que ha fallado frecuentemente estás dados por los eventos ocurridos inmediatamente antes del fallo. Por lo tanto su descripción debe describir precisamente lo que hizo y lo que la máquina hizo para producir el error. En el caso de procesos de línea de comandos, el tener un log de la sesión (por ejemplo, usando la utilidad de scripts) y el señalar las 20 lineas relevantes o algo asi es muy util.
Si el programa que le falló tiene opciones de diagnóstico (como la -v de verbose), trate de pensar cuidadosamente al seleccionar las opciones que añadirán información de debug valiosa a su mensaje.
Si su relato termina siendo muy largo (más de unos cuatro párrafos), puede ser útil el establecer suscintamente el problema al inicio y luego seguir una historia cronológica. De esta forma, los "hackers" sabrán de que se está hablando al leer su relato.
--------------------------------------------------------------------------------
No le pida a la gente que le conteste a su email privado
Los "hackers" creen que el solucionar problemas debe ser un proceso público y transparente en el cual el primer intento de respuesta puede y debe ser corregido si alguien que conoce más del asunto nota que está incompleto o incorrecto. Además, ellos también obtienen parte de su recompensa por responder el mensaje al ser vistos como competentes y conocedores por sus compañeros.
Cuando usted pide una respuesta privada, está desestabilizando tanto el proceso como la recompensa. No lo haga. El responder privadamente es una elección de su corresponsal - y si lo hace, es usualmente porque el piensa que la pregunta está muy mal hecha o es demasiado obvia como para ser interesante a otros.
Hay una excepción limitada a esta regla. Si usted piensa que la pregunta es tal que probablemente obtendrá una cantidad de respuestas similares, entonces las palabras mágicas son "escribame un email y haré un sumario de las respuestas recibidas para el grupo". Es cortés el tratar de ahorrarle a la lista o al grupo de discusión un montón de respuestas substancialmente idénticas - pero debe cumplir su promesa de enviar el sumario.
--------------------------------------------------------------------------------
Sea explícito acerca de la pregunta que tiene
Las preguntas abiertas tienden a ser percibidas como perdederas de tiempo abiertas. La gente que más probablemente le dará una respuesta correcta es también la más ocupada (inclusive si es solo por que toman la mayor parte del trabajo para si mismas). La gente así es alérgica a la perdedera de tiempo abierta y por lo tanto a las preguntas abiertas.
Tiene más probabilidades de obtener una respuesta útil si es explícito acerca de lo que desea que sus corresponsales hagan. (Den ideas, envíen código, chequeen sus arreglos, lo que sea). Esto enfocará sus esfuerzos y pone implícitamente un límite al tiempo y energía que un posible corresponsal tiene que poner al responderle. Esto es bueno.
Para entender el mundo en que viven los expertos, piense en su experiencia como un recurso abundante y el tiempo para responderle como uno escaso. Entre menos tiempo usted pida implícitamente, más probablemente tendrá una respuesta de alguien que sea realmente bueno y realmente ocupado.
Por lo tanto es útil el enmarcar su pregunta para minimizar el compromiso de tiempo que un experto requiere para comprenderla - pero esto generalmente no es lo mismo que simplificar la pregunta. De esta manera, por ejemplo, "Puede darme una referencia a una buena explicación de X?" es usualmente una mejor pregunta que "Me podría explicar X, por favor?". Si usted puede enviar algo del código que no funciona, es usualmente más inteligente el pedir que alguien explique que es lo que falla que pedirle a alguien que lo arregle.
--------------------------------------------------------------------------------
No haga preguntas de su tarea
Los "hackers" se dan cuenta fácilmente de las preguntas que son tarea; la mayoría de nosotros las hemos hecho. Esas preguntas son para que usted trabaje en ellas, de forma que aprenda de la experiencia. Está bien el pedir pistas, pero no el pedir soluciones completas.
--------------------------------------------------------------------------------
Evite las preguntas inútiles
Resista la tentación de cerrar su petición de ayuda con preguntas semánticamente nulas como "Alguien me puede ayudar?" o "Existe una solución?". Primero: si usted ha escrito su problema medio competentemente, esas preguntas son una muletilla superflua. Segundo: puesto que son superfluas, los "hackers" las encuentran molestas - y es probable obtener una respuesta impecablemente lógica pero igualmente superflua como "Si, alguien le puede ayudar" o "No, nadie le va a ayudar".
--------------------------------------------------------------------------------
La cortesía nunca molesta, y algunas veces ayuda.
Sea cortés. Use "Por favor" y "Gracias por adelantado". Deje claro que usted aprecia el tiempo que la gente usa ayudándole gratis.
Para ser honesto, esto no es tan importante como (y no sustituye a) usar buena gramática, ser claro, preciso y descriptivo, el evitar formatos propietarios etc.; los "hackers" en general prefieren reportes de problemas ásperos pero técnicamente precisos que un mensaje cortés pero vago. (Si esto le confunde, recuerde que valoramos una pregunta por lo que nos enseña.)
Sin embargo, si usted tiene todos sus puntos técnicos listos, la cortesía incrementa las posibilidades de obtener una respuesta útil.
(Debemos hacer notar que la única objeción seria que hemos recibido a esto de los "hackers" veteranos es a la recomendación de usar "Gracias por adelantado". Algunos hackers sienten una connotación de no se les agradecerá después. Nuestra recomendación es hacerlo antes y después.)
--------------------------------------------------------------------------------
Haga un seguimiento con una nota breve a la solución
Envíe una nota después de que el problema ha sido resuelto a todos aquellos que le ayudaron; déjeles saber como resultó todo y agradézcales de nuevo por su ayuda. Si el problema atrajo un interés general de la lista de correo o el grupo de noticias, lo apropiado es enviar la nota de seguimiento allí.
Su nota de seguimiento no tiene que ser larga y detallada. Un simple "Hola - era un cable de red dañado! Gracias a todos. Fulano" es mejor que nada. De hecho, un sumario corto y cortés es mejor que una larga disertación a menos que la solución sea realmente profunda técnicamente. Diga cuál acción solucionó el problema, pero no tiene que replicar la secuencia entera de la solución.
Además de ser cortés e informativa, esta clase de seguimiento le ayuda a otros que buscan en el archivo de la lista de correo o grupo de interés a saber exactamente que solución le ayudó y por lo tanto les puede ayudar a ellos.
Finalmente, pero no por ello menos importante, esta clase de seguimiento ayuda a todos los que le asistieron a darle un sentido de que el problema se ha cerrado. Si usted no es un técnico o un "hacker", confíe en nosotros cuando le decimos que esta sensación es muy importante para los gurús y expertos que le ayudaron a resolver el problema. Las narraciones de problemas que llevan a una nada no resuelta son muy frustrantes; a los "hackers" les pica el verlas resueltas. El buen karma que "rascar eso que les pica" le dá a usted, será muy útil la próxima vez que necesite poner una pregunta.
--------------------------------------------------------------------------------
Cómo interpretar las respuestasHay un par de acrónimos en inglés muy utilizados inclusive en los foros en español: RTFM y STFW. Le indican cuándo de verdad ha metido la pata.
Existe una tradición antigua y consagrada: si usted recibe una respuesta que dice "RTFM", la persona que la envió piensa que usted debió haber "Leído el Puto Manual". (Read The Fucking Manual). Generalmente está en lo cierto. Vaya y léalo.
RTFM tiene un hermanito menor: Si obtiene una respuesta que dice "STFW", la persona que lo envió piensa que usted debió haber "Buscado en la Puta Web" (Search The Fucking Web). Generalmente está en lo cierto, Vaya y busque.
Generalmente, la persona que envía alguna de estas respuestas tiene abierto el manual o la página web, y la está viendo mientras escribe. Estas respuestas significan que el piensa que a.) la información que usted necesita es fácil de encontrar, y b.) usted aprenderá más si busca la información que si se la dan con cucharita en la boca.
No debería sentirse ofendido por esto; en los estándares de los "hackers", le está dando una muestra áspera de respeto al no ignorarlo. Debería en cambio agradecerle por su amabilidad de abuela.
--------------------------------------------------------------------------------
Si usted no entiende...
Si no entiende la respuesta, no salte inmediatamente demandando una clarificación. Use las mismas herramientas que usó para tratar de responder la pregunta original (manuales, FAQs, la Web, amigos calificados) para entender la respuesta. Luego, si todavía necesita la clarificación, exhiba lo que ha aprendido.
Por ejemplo, suponga que le digo: "Parece que tiene una zentry corrupta; necesita eliminarla".
Entonces:
Aquí hay una mala pregunta de seguimiento: "Qué es una zentry?"
Aquí hay una pregunta de seguimiento buena: "OK, he leído la página del manual y las zentrys sólo están mencionadas junto a los switches -z y -p. Ninguno de ellos dice nada acerca de eliminar zentrys. Es alguno de ellos o me estoy perdiendo de algo?"
--------------------------------------------------------------------------------
Enfrentándose a la grosería
Mucho de lo que parece grosero en los círculos de los "hackers" no se supone que ofenda. Es mas bien, el producto del estilo de comunicaciones directo y sin tonterías que es natural a la gente que está más habituada a resolver problemas que a hacer sentir a la gente apreciada y querida.
Cuando perciba grosería, trate de reaccionar con calma. Si alguien realmente se ha pasado, es muy probable que algún miembro más antiguo del foro le llame la atención. Si eso no ocurre y usted pierde los estribos, es probable que la persona usted cree que lo ha insultado esté actuando de acuerdo a los estándares de la comunidad "hacker" y que sea usted el que está fallando. Esto daña las posibilidades de obtener la información que quiere.
Por otro lado, se encontrará ocasionalmente con grosería y posturas realmente gratuitas. El otro lado de lo mencionado anteriormente es que es una forma de tratar a los verdaderos ofensores realmente mal, disectando su mal comportamiento con un agudo escalpelo verbal. Sin embargo, asegúrese muy, muy bien, de dónde está parado antes de hacer esto. La línea entre corregir una descortesía y empezar una guerra de insultos insulsa es lo suficientemente delgada como para que los "hackers" mismos metan la pata frecuentemente. Si usted es un novato o un intruso, las posibilidades de evitar esa metida de pata son bajos. Si lo que busca es información en vez de entretenimiento, es mejor mantener sus dedos lejos del teclado en vez de arriesgarse a esto.
(Alguna gente sostiene que muchos "hackers" tienen una forma leve de Autismo o Síndrome de Asperge, y realmente les faltan algunos de los circuitos cerebrales que lubrican la interacción social 'normal'. Esto puede o no ser cierto. Si usted no es un "hacker" puede que el pensar de nosotros como gente con daño cerebral le ayude a hacernos frente. Hágalo. No nos importa; nos gusta ser lo que sea que somos y tenemos un sano escepticismo acerca de las etiquetas clínicas.)
En la próxima sección, hablaremos de un asunto diferente; la clase de "grosería" que verá cuando usted es el que se comporta mal.
--------------------------------------------------------------------------------
No reaccione como un fracasadoHay una buena probabilidad de que meta la pata unas cuantas veces un los foros de la comunidad "hacker" - en formas detalladas en este artículo o similares.
Cuando esto ocurre, lo peor que puede hacer es quejarse acerca de su experiencia, proclamar que ha sido asaltado verbalmente, demandar disculpas, gritar, dejar de respirar, amenazar con demandas, quejarse antes los empleadores de la gente, dejar la tapa del inodoro abierta, etc. En lugar de eso, haga lo siguiente:
Supérelo. Es normal. De hecho, es sano y apropiado.
Los estándares de las comunidades no se mantienen a sí mismos: son mantenidos por gente que los aplica activamente, visiblemente, en público. No se queje diciendo que todas las críticas han debido ser enviadas por correo privado: No funciona así. Tampoco es útil el insistir en que ha sido insultado personalmente cuando alguien dice que algunas de sus aseveraciones eran equivocadas o que sus puntos de vista difieren. Estas son actitudes de fracasado.
Han habido foros "hacker" donde, de algún sentido malsano de super-cortesía, los participantes se les ha prohibido poner de presente las fallas que encuentran en los envíos de otros y se les ha dicho "No diga nada si no está dispuesto a ayudar al usuario". La partida consecuente de participantes importantes hacia algún otro foro hace que se descienda en babosadas sin sentido y se conviertan en inútiles como foros técnicos.
Exageradamente "educado" (en ese sentido) o útil: Elija uno.
Recuerde: Cuando un hacker le diga que ha metido la pata, y (sin importar que tan descortésmente) le dice que no lo haga de nuevo, está actuando preocupado por 1) usted y 2) su comunidad. Sería mucho más fácil para él el ignorarle y filtrarlo fuera de su vida. Si no puede ingeniárselas para sentirse agradecido, por lo menos tenga un poco de dignidad, no se queje, y no espere ser tratado como una muñequita frágil sólo por que usted es un recién llegado con un alma teatralmente hipersensitiva y tiene falsas ilusiones de grandeza.
--------------------------------------------------------------------------------
Preguntas que no se hacenHe aquí algunas preguntas estúpidas clásicas y lo que los "hackers" están pensando cuando no las responden:
P:Dónde encuentro el programa X?
P:Mi {programa, configuración, sentencia SQL} no funciona
P:Tengo problemas con mi máquina Windows. Me puede ayudar?
P:Tengo problemas instalando Linux o X. Me puede ayudar?
P:Cómo puedo "crackear" privilegios de root /robar canales/leer email de otros?
P:Dónde encuentro el programa X?
Q: Dónde encuentro el programa X?
R: En el mismo sitio donde yo lo encontré, pendejo - al otro lado de una máquina de búsqueda. Es que no sabe todo el mundo cómo usar Google todavía?
P:Mi {programa, configuración, sentencia SQL} no funciona
R: Esta no es una pregunta y no estoy interesado en jugar "Veinte preguntas" para adivinar qué es lo que necesita. Tengo mejores cosas que hacer. Al ver algo como esto, mi reacción normalmente es una de las siguientes:
Tiene algo que añadir al respecto?
Oh, mala suerte, espero que lo arregles.
Y esto exactamente qué tiene que ver conmigo?
P:Tengo problemas con mi máquina Windows. Me puede ayudar?
R: Si. Bote esa basura Microsoft e instale Linux.
P:Tengo problemas instalando Linux o X. Me puede ayudar?
A: No. Necesitaría estar de cuerpo presente con su máquina para solucionar esto. Vaya y pidale ayuda al grupo local de usuarios de Linux. (Puede encontrar una lista de grupos de usuarios aquí).
P:Cómo puedo "crackear" privilegios de root /robar canales/leer email de otros?
R: Usted es una persona despreciable por querer hacer cosas como esa y un estúpido por pedirle a un "hacker" que le ayude a hacerlo.
--------------------------------------------------------------------------------
Preguntas buenas y malasFinalmente, voy a ilustrar como hacer pregunas de forma inteligente usando ejemplos; pares de preguntas acerca del mismo problema, una hecha de forma estúpida y otra de forma inteligente.
Estúpida: Dónde puedo averiguar acerca del Foonly Flurbamatic?
Esta pregunta está pidiendo a gritos un "STFW" como respuesta.
Inteligente: He usado Google para tratar de encontrar "Foonly Flurbamatic 2600" en la Web, pero sin resultados relevantes. Alguien sabe dónde puedo encontrar información de programación para este dispositivo?
Esta persona ya ha "Buscado en la puta Web" y parece que tiene un problema de verdad.
Estúpida: No puedo hacer que el código para el proyecto foo compile. Por qué no funciona?
El asume que alguien más ha metido la pata. Arrogante de su parte.
Inteligente: El código del proyecto foo no compila bajo Nulix 6.2. Ya he leído la FAQ, pero no dice nada acerca de problemas con Nulix. He aquí un log de mi intento de compilación. Estoy haciendo algo mal?
Esta persona ha especificado el ambiente, ha leído el FAQ, está mostrando el error y no asume que su problema se deben a un error de alguien más. Esta persona merece alguna atención.
Estúpida: Tengo problemas con mi motherboard. Alguien puede ayudarme?
La respuesta de Fulano Hacker a esto probablemente sería: "Seguro, también necesita que le cambien el pañal y le den el biberón?" seguida por un golpe en la tecla Delete.
Inteligente: He intentado X, Y y Z con el motherboard S2464. Como eso no funcionó intenté A, B y C. Noten el síntoma curioso cuando intenté C. Obviamente se está recalentando, pero los resultados no son lo que uno esperaría. Cuáles son las causas usuales de recalentamiento en los motherboards Athlon MP? Alguien tiene alguna idea para otro test que me ayude a encontrar el problema?
Esta persona, por otro lado, parece merecer una respuesta. Ha exhibido inteligencia al resolver su problema en lugar de esperar pasivamente a que le caiga una respuesta del cielo.
Nótese en la última pregunta, la pequeña pero importante diferencia entre demandar "Deme una respuesta" y "Por favor ayudeme a elucidar que otros diagnósticos puedo correr para entender qué ocurre".
De hecho, la forma de la última pregunta está basada muy de cerca en un incidente real que pasó en agosto del 2001 en la lista de correo del kernel de linux. Yo (Eric) era el que hacía la pregunta esa vez. Estaba observando unos bloqueos misteriosos en una motherboard Tyan S2464. Los miembros de la lista suplieron la información crítica que necesitaba para eliminarlos.
Haciendo la pregunta de la forma que yo lo hice, le daba a la gente algo que masticar. Hice fácil y atractivo el que ellos se involucraran. Demostré respeto por la habilidad de mis compañeros y los invité a consultarme como uno más de ellos. También demostré respeto por el valor de su tiempo contándoles de los callejones sin salida por los que yo ya había transitado.
Luego de eso, cuando agradecí a todos y puse de presente cómo había trabajado de bien el proceso, un miembro de la lista observó que el pensaba que no había trabajado por que yo fuera un "personaje" de la lista, si no por que hice la pregunta de la forma correcta.
Los "hackers" son de alguna forma una meritocracia implacable; estoy seguro de que él estaba en lo correcto y de que si me hubiera comportado como una esponja hubiera sido atacado o ignorado sin importar quién era yo. Su sugerencia de que yo escribiera el incidente completo para instruir a otros llevó directamente a la composición de esta guía.
--------------------------------------------------------------------------------
Si no puede obtener una respuestaSi no puede obtener una respuesta, por favor no lo tome personalmente y no crea que no queremos ayudarle. A veces los miembros del grupo pueden sencillamente no saber la respuesta. El no tener una respuesta no es lo mismo que ser ignorado, a pesar que ciertamente es dificil discernir la diferencia a la distancia.
En general, sencillamente mandar de nuevo la pregunta es mala idea. Va a parecer inútilmente molesto.
Hay otras fuentes de ayuda a las cuales acudir, frecuentemente mejor adaptadas a las necesidades de los novatos.
Hay muchos grupos de usuarios locales y en línea que son entusiastas respecto al software, a pesar de que pueden no haber escrito ningún software ellos mismos. Estos grupos se forman frecuentemente para que otra gente puedan ayudarse entre si y ayudar a usuarios nuevos.
Existen también cantidades de compañías comerciales con las cuales contratar soporte, grandes y pequeñas. (Red Hat y Linuxcare son dos de las mejor conocidas, hay muchas otras). No desfallezca por la idea de tener que pagar un poco por ayuda! Después de todo, si en su carro explota un casquete, lo normal es que usted vaya al taller y pague para que lo arreglen. Inclusive si el software no le ha costado nada, no puede suponer que el soporte también será siempre gratis.
Para un software popular como Linux, hay por lo menos 10,000 usuarios por desarrollador. Es sencillamente imposible que una persona atender las llamadas de soporte de más de 10,000 usuarios. Recuerde que inclusive si tiene que pagar por soporte, usted en todo caso está pagando mucho menos que si tuviera que comprar el software también. ( y el soporte para software propietario es usualmente más caro y menos competente que el soporte para software abierto --open-source-- ).
--------------------------------------------------------------------------------
Recursos relacionados
Si usted necesita instrucción en las cosas básicas de como usar computadores personales, Unix, y cómo trabaja la internet vea los "COMO" de Unix y Fundamentos de Internet.
Cuando usted libera software o escribe parches para software, trate de seguir las guías dadas en "Software Release Practice HOWTO".
