提问的智慧（How To Ask Questions The Smart Way）

Gestión del Foro Anuncios & Reglas
1

Original: How To Ask Questions The Smart Way

Traducción: Wang Gang<yafrank at 126 dot com>
Fecha: 26 de octubre de 2013
Contenido

Índice

Traducciones: indonesio, bielorruso, portugués de Brasil, chino simplificado, neerlandés, francés, georgiano, alemán, griego, hebreo, japonés, polaco, portugués, rumano, ruso, español, tailandés. Si deseas copiar, reflejar, traducir o citar este texto, consulta mi acuerdo de reproducción.

Descargo de responsabilidad

Muchos sitios de proyectos enlazan a este documento en su sección “cómo obtener ayuda”. Está bien, es justo lo que queremos. Pero si eres el administrador del sitio que genera ese enlace, por favor pon una nota bien visible cerca del enlace que diga: ¡No proporcionamos soporte para este proyecto!

Ya hemos sufrido el dolor de no tener esta aclaración: nos acosan sin cesar ciertos idiotas que creen que, como publicamos este texto, estamos obligados a resolver todos los problemas técnicos del planeta.

Si estás leyendo esto porque necesitas ayuda y te vas con la impresión de que puedes obtenerla directamente de los autores, entonces tú eres uno de esos idiotas. No nos preguntes a nosotros; no responderemos. Solo te enseñamos cómo obtener ayuda de quienes realmente entienden tu problema, y en el 99,9 % de los casos no seremos nosotros. A menos que estés absolutamente seguro de que el autor es experto en tu tema, no molestes; todos estaremos más contentos.

Introducción

En el mundo de los hackers, la respuesta que obtengas depende mucho de la forma en que preguntes y de la dificultad de tu problema. Este documento te explica cómo formular una pregunta de modo que tengas más posibilidades de recibir una respuesta satisfactoria.

El software libre ya se usa en muchos lugares; con frecuencia puedes obtener ayuda de usuarios con más experiencia que tú, no de los hackers mismos. Eso es bueno: suelen ser más tolerantes con los errores típicos de los novatos. No obstante, si sigues nuestras recomendaciones y tratas a esos usuarios como si fueran hackers, normalmente obtendrás respuestas más útiles.

Lo primero que debes entender es que a los hackers nos encantan los problemas difíciles y las buenas preguntas que nos hagan pensar. Si no fuera así, no habríamos escrito este texto. Si planteas una pregunta interesante que nos haga rascar la cabeza, te lo agradeceremos. Una buena pregunta es un estímulo y un regalo: nos ayuda a desarrollar nuestro conocimiento y a descubrir cosas que no habíamos considerado. Entre hackers, decir «¡Buena pregunta!» es un cumplido sincero y entusiasta.

Además, los hackers tenemos fama de ser hostiles o arrogantes con preguntas sencillas. A veces parecemos reaccionar con grosería refleja ante novatos y tontos, pero no es eso exactamente.

Lo que sí nos repatea sin disculpas es la gente que no quiere pensar ni hacer sus deberes antes de preguntar. Son un agujero negro temporal: solo saben tomar, no dar; malgastan tiempo que podría dedicarse a problemas más interesantes o a gente más merecedora. A esos los llamamos «perdedores» (por razones históricas, a veces escribimos «lusers»).

Reconocemos que muchos solo quieren usar nuestros programas y no les interesa aprender los detalles técnicos. Para la mayoría, el ordenador es solo una herramienta, un medio para un fin; tienen sus vidas y cosas más importantes que hacer. Lo aceptamos y no esperamos que a todos les apasione lo que a nosotros nos fascina. Pero nuestro estilo de responder está pensado para quienes sí tienen interés real y desean participar activamente en resolver el problema; eso no va a cambiar ni debería. Si cambiara, dejaríamos de ser eficaces en lo que mejor sabemos hacer.

La mayoría somos voluntarios que sacamos tiempo de nuestras vidas ocupadas para responder; a veces no damos abasto. Por eso filtramos sin piedad, especialmente las preguntas que parecen de perdedores, para dedicar el tiempo a los «ganadores».

Si te parece que esta actitud es arrogante o altanera, revisa tus suposiciones: no te exigimos que te sometas. De hecho, si haces tu parte, la mayoría estaremos encantados de tratarte de tú a tú y darte la bienvenida a nuestra cultura. Intentar ayudar a quien no quiere ayudarse es ineficaz. No es grave no saber; sí lo es ser negligente.

Así que no necesitas ser un técnico para atraer nuestra atención, pero sí debes mostrar la actitud que te llevará a serlo: perspicaz, pensante, observador, dispuesto a participar en la solución. Si no haces nada que te distinga, te sugieras contratar un servicio comercial en lugar de pedir ayuda gratuita.

Si decides pedirnos ayuda, no querrás ser un perdedor ni que te vean como tal. La mejor forma de obtener una respuesta rápida y útil es parecer alguien listo, seguro y con ideas, que solo necesita un empujón en un punto concreto.

(Se aceptan correcciones: [email protected] o [email protected]. Este texto no pretende ser una guía general de «netiquette»; suelo rechazar sugerencias no relacionadas con obtener buenas respuestas en foros técnicos.)

Antes de preguntar

Antes de enviar una pregunta técnica por correo, news o foro, haz lo siguiente:

  • Busca en los archivos históricos del foro.
  • Busca en Internet.
  • Lee el manual.
  • Lee la FAQ.
  • Investiga o experimenta por ti mismo.
  • Pregunta a algún amigo que sepa.
  • Si eres programador, lee el código fuente.

Cuando preguntes, indica que ya hiciste todo eso; ayudará a que no parezcas un parásito que desperdicia el tiempo de los demás. Explica también qué aprendiste en el proceso: nos gusta ayudar a quien demuestra que puede aprender.

Busca los mensajes de error en Google (tanto grupos como web); muchas veces encontrarás directamente la documentación o el hilo de la lista de correo que lo resuelve. Aunque no lo consigas, mencionar «he buscado estas frases en Google y no he encontrado nada útil» ya es positivo: indica qué no funcionó y ayuda a otros con el mismo problema.

No te impacientes: no esperes que una búsqueda de dos segundos resuelva un problema complejo. Lee la FAQ. Relájate y piensa antes de preguntar a un experto. Se nota cuánto has leído y pensado; si vienes preparado, es más probable que respondan. No lances todas tus dudas de golpe solo porque la primera búsqueda no dio resultado (o dio demasiados).

Piensa seriamente y prepara tu pregunta. Una pregunta descuidada solo recibe una respuesta descuidada o ninguna. Cuanta más evidencia muestres de haber intentado resolverlo, más probabilidades tendrás de recibir ayuda real.

No preguntes algo erróneo. Si tu pregunta parte de premisas falsas, algún hacker pensará «pregunta tonta…» y te responderá sobre esa base, dándote la lección de que a veces obtienes la respuesta a lo que preguntaste, no a lo que necesitabas.

Nunca supongas que tienes derecho a una respuesta. No lo tienes: no has pagado por el servicio. Si planteas una pregunta interesante, rica y estimulante, la «ganarás» porque aporta valor a la comunidad, no solo exige conocimiento.

Mostrar disposición a participar en la solución es un buen comienzo. «¿Alguien puede orientarme?», «¿Qué me falta?», «¿Qué debo leer?» suele funcionar mejor que «Dadme los pasos completos», porque demuestras que solo necesitas una pista.

Al hacer una pregunta

Elige cuidadosamente el foro

Haz cualquiera de estas cosas y probablemente te ignores o califiquen de perdedor:

  • Preguntar sobre algo ajeno al tema del foro.
  • Plantear preguntas triviales en foros avanzados (o viceversa).
  • Cruzar-publicar en muchos grupos.
  • Enviar correo privado a quien no te conoce ni está obligado a ayudarte.

Los hackers eliminan lo que no va al lugar correcto para no saturar los canales.

Usa buscadores para encontrar el sitio del proyecto relacionado con tu problema; allí suele haber FAQ, listas de correo y documentación. Si nada de eso funciona, la lista de correo es tu última opción.

Enviar un correo a un desconocido es un riesgo: no supongas que el autor de una página quiere ser tu consultor gratuito. Si no estás seguro de que tu pregunta será bienvenida, busca otro sitio o no preguntes.

Lee la FAQ o el charter del grupo antes de escribir; revisa mensajes anteriores para captar el tono. Busca palabras clave en los archivos: quizá la respuesta ya esté ahí.

No dispares a todas partes a la vez: es tan molesto como gritar.

Entiende el tema. Un error típico es preguntar por APIs de Unix o Windows en un foro sobre un lenguaje multiplataforma. Si no ves por qué es un error, infórmate antes de preguntar.

En general, es más fácil obtener buenas respuestas en foros públicos bien elegidos que en foros privados: hay más posibles respondientes y a los hackers les gusta ayudar a la mayoría.

Los autores de software popular ya reciben demasiado spam. Tu mensaje puede ser la gota que colme el vaso; ha habido casos en que abandonaron el soporte por ello.

Los foros para principiantes y el IRC suelen responder más rápido

Tu grupo local o la distribución Linux que usas probablemente anuncie foros o canales IRC para novatos. Empieza ahí, sobre todo si tu problema parece simple o común. Los canales IRC públicos invitan a preguntar y suelen dar respuesta en tiempo real.

Si el programa viene de tu distribución, pregunta primero en sus foros/listas y luego en los del proyecto; de lo contrario, los desarrollores te dirán «usa nuestro código».

Antes de escribir, usa la función de búsqueda del foro; los buscadores a veces no han indexado todo.

La tendencia es que el soporte a usuarios se dé por foro o IRC, reservando el correo para los desarrolladores. Empieza por los primeros.

Segundo paso: usa la lista de correo del proyecto

Cuando exista una lista de desarrolladores, escribe a la lista, no a un individuo, aunque creas que él puede responderte mejor. Encuentra la dirección en la documentación o la página del proyecto. Razones:

  • Una buena pregunta individual también beneficia al grupo.
  • Reparte la carga: los desarrolladores pueden estar saturados.
  • Los archivos de la lista se indexan en buscadores; otros encontrarán tu pregunta y su solución.
  • Si algo se pregunta mucho, los desarrolladores pueden mejorar la documentación o el código.

Si hay listas separadas de «usuarios» y «desarrolladores» y no vas a tocar código, usa la de usuarios. No presupongas bienvenida en la lista de desarrolladores: solo aumentarás el ruido.

Si tras varios días en la lista de usuarios no obtienes respuesta y tu problema es poco común, puedes probar la de desarrolladores, pero observa primero para captar el tono.

Si solo encuentras la dirección del mantenedor, escríbele, pero indica que no hallaste ninguna lista y que permites que reenvíe tu mensaje.

Usa un asunto significativo y claro

En listas, news o foros, el asunto es tu única oportunidad (en 50 caracteres) de atraer a los expertos. No la desperdicies con «Por favor ayuda» (y mucho menos «¡¡¡POR FAVOR AYUDA!!!», que se borra por reflejo). No intentes impresionarnos con tu drama; describe el problema con extrema brevedad.

Una buena fórmula es «objeto – desviación»: qué cosa falla y cómo se comporta de forma inesperada.

Tonto:

¡Socorro! ¡La pantalla de mi portátil no va bien!

Inteligente:

X.org 6.8.1 distorsiona el cursor, chip MV1005

Más inteligente:

Cursor distorsionado con X.org 6.8.1 y chip MV1005

Esa práctica te obliga a pensar con precisión: ¿qué se ve afectado?, ¿solo el cursor?, ¿solo en X.org?, ¿solo la versión 6.8.1?, ¿solo ese chip?, ¿solo el modelo MV1005? Un hacker debe entenderlo de un vistazo.

Imagina que alguien buscará en un índice de asuntos; cuanto mejor reflejes tu problema, más fácil será que el siguiente lo encuentre sin volver a preguntar.

Si preguntas dentro de un hilo, cambia el asunto para indicar que es una nueva pregunta y recorta las citas irrelevantes.

Para listas, no pulses «Responder» para iniciar un tema nuevo: limitarás tu audiencia. Algunos lectores (p. ej. mutt) ordenan por hilos y tu mensaje quedará oculto. Envía un correo nuevo.

En foros, donde los mensajes quedan ligados al hilo, puedes responder dentro del tema, pero ten en cuenta que solo lo verá quien siga ese hilo; si quieres llegar a más gente, abre otro tema.

Haz que tu pregunta sea fácil de responder

Terminar con «Por favor, responded a…» suele conseguir lo contrario. Si te parece molesto configurar tu cliente para que ponga la dirección correcta, a nosotros nos parece molesto pensar en tu problema.

En foros, pedir respuesta por correo privado es de mala educación, salvo que la información pueda ser sensible. Si solo quieres que te avisen, usa la opción del foro («seguir este hilo», «avisar por correo»), que existe en casi todos.

Escribe con buena ortografía, gramática y claridad

La experiencia dice que quien escribe descuidadamente suele pensar y programar descuidadamente. Responder a ese tipo de gente no merece la pena.

Expresarte con claridad es esencial. Si te parece mucho trabajo, a nosotros nos parece mucho trabajo leerte. Dedica un esfuerzo extra a redactar; no hace falta ser formal, de hecho el humor y el slang están bien, pero debe ser preciso y demostrar que has pensado el problema.

Respeta mayúsculas, puntuación y ortografía; no confundas «its» con «it’s», «loose» con «lose» ni «discrete» con «discreet». No escribas TODO EN MAYÚSCULAS (se considera gritar) ni todo en minúsculas (es difícil de leer).

Si escribes como un analfabeto, probablemente te ignores. Evita abreviaturas de chat («u» por «you»); pareces incapaz de pulsar dos teclas más. Y si escribes como un niño, puedes dar por hecho que nadie te responderá (o solo para regañarte).

En foros no nativos se toleran errores de idioma, pero no la pereza (sí notamos la diferencia). A menos que sepas el idioma de los posibles lectores, escribe en inglés; los hackers borran sin leer los mensajes que no entienden. El inglés es el idioma de trabajo de Internet.

Si el inglés es tu segundo idioma, advierte de ello para que los demás tengan paciencia, por ejemplo:* El inglés no es mi lengua materna; disculpen los errores ortográficos.

  • Si habla cierto idioma, por favor escríbame por correo o mensaje privado; quizá necesite ayuda para traducir mi pregunta.
  • Conozco bien el término técnico en sí, pero no estoy familiarizado con algunas de sus formas coloquiales o expresiones idiomáticas.
  • Ya he formulado la pregunta tanto en cierto idioma como en inglés; si responde en cualquiera de los dos, con gusto traduzco.

Envíe la pregunta en un formato legible y estándar

Si hace que su pregunta sea difícil de leer, probablemente la ignoren; la gente prefiere cuestiones claras:

  • Use texto plano, no HTML (apagar HTML no es difícil).
  • Los adjuntos MIME suelen estar bien si contienen algo útil (código fuente o parches), no meras plantillas del cliente de correo.
  • No envíe correos con frases de una sola línea pero retornos cada pocos caracteres (dificulta citar partes). Piense que el lector usa un terminal de 80 columnas; ajuste el texto por debajo de ese límite.
  • Pero tampoco fuerce saltos de línea en datos fijos (registros, logs). Inclúyalos tal cual para que quien responda vea exactamente lo mismo que usted.
  • En foros en inglés, no use codificación MIME “Quoted-Printable”. Puede ser necesaria para idiomas no-ASCII, pero muchos clientes no la soportan; los “=20” interrumpen la lectura y hasta alteran el sentido.
  • Nunca espere que un hacker lea documentos en formatos propietarios cerrados (Word, Excel). La mayoría reaccionan como si le echaran estiércol caliente a la puerta.
  • Si envía desde Windows, desactive las “comillas inteligentes” (Herramientas → Opciones de autocorrección → Formato mientras escribe).
  • En foros no abuse de emoticonos ni de HTML. Un par están bien, pero texto multicolor grita “novato”. Demasiados emoticonos, colores y fuentes hacen que parezca una niña tonta; no es buena idea salvo que busque ligar en vez de respuestas útiles.
  • Si usa un cliente gráfico (Outlook, Netscape Messenger, etc.), revise el mensaje con “Ver fuente” antes de enviar; asegúrese de que sea texto plano.

Describa el problema con precisión y contenido

  • Detalle cuidadosamente los síntomas.
  • Indique el entorno (máquina, SO, aplicación) con distribución y versión exactas (“Fedora Core 7”, “Slackware 9.1”).
  • Explique qué investigó y qué entendió antes de preguntar.
  • Mencione los pasos de diagnóstico que ya intentó.
  • Describa cambios recientes en el sistema o software.
  • Si es posible, proporcione un modo de reproducir el problema en un entorno controlado.
  • Anticipe lo que los hackers podrían preguntar y tenga las respuestas listas.

Si cree que el fallo está en el código, un ejemplo mínimo y reproducible multiplica las probabilidades de recibir ayuda.

Simon Tatham escribió Cómo reportar fallos de manera efectiva; léalo.

Brevedad y refinamiento

Sea breve y sustancial. Pegar montones de código o datos no ayuda. Si tiene un caso grande que provoca el fallo, recórtelo al mínimo.

Por qué:

  1. Demuestra esfuerzo y aumenta la probabilidad de respuesta.
  2. Facilita respuestas útiles.
  3. Mientras reduce el ejemplo, quizá encuentre usted mismo la solución.

No grite “¡bug!” demasiado pronto

Cuando algo falla, no lo etiquete como bug a menos que tenga bases muy sólidas: un parche que lo arregle o una prueba de regresión que falle. Para documentación, adjunte el texto corregido.

Recuerde: muchos usuarios no ven ese problema; si lo hubieran visto, ya habría aparecido en Google (¿lo buscó, verdad?). Además, cuestionar la calidad del software puede ofender a quienes lo escriben. Redacte su pregunta como si el error fuera suyo; si es un bug real, se aclarará en la respuesta.

Humildad excesiva ≠ trabajo previo

Evite frases como “Sé que soy un pobre principiante, pero…”. Es tan inútil como ser grosero y, junto a una descripción vaga, resulta irritante. Explique el contexto y el problema con claridad; eso posiciona mejor que la autodenigración.

Describa síntomas, no teorías

Diga qué observa, no qué cree que es la causa. Si quiere compartir su hipótesis, aclare que es solo eso y por qué cree que falla.

Estúpido:

Al compilar el kernel me salen errores SIG11; ¿cómo detecto la pista de circuito rota en la placa?

Inteligente:

Mi PC ensamblada (K6/233, placa FIC-PA2007, chipset Apollo VP2, 256 MB Corsair PC133) da SIG11 al compilar pasados 20 min tras encender. Reiniciar no resetea el reloj, pero apagar toda la noche sí. Cambiar RAM no arregla nada; adjunto log.

Recuerde: “Todos los expertos son de Misuri; muéstreme los hechos”.

Ordene los síntomas cronológicamente

Lo que ocurrió justo antes del fallo es la pista más valiosa. Inclúyalo todo: qué hizo usted, la máquina y el software. Si usa línea de comandos, adjunte 20 líneas del log.

Si el programa tiene opciones de depuración (-v), actívelas; no ahogue al lector, pero dé datos útiles. Si el informe es largo, empiece con un resumen y luego la secuencia completa.

Describa el objetivo, no el procedimiento

Si pregunta cómo hacer algo, diga primero qué quiere lograr y luego los pasos que intentó.

Estúpido:

¿Cómo hago que el selector de color me devuelva RGB hexadecimal?

Inteligente:

Quiero reemplazar la paleta de una imagen con colores exactos; lo único que se me ocurre es editar cada entrada, pero el selector no me da valores hex.

No pida respuesta privada

Los hackers prefieren transparencia: cualquiera puede corregir o mejorar la respuesta. Al pedir privacidad corta ese proceso y priva al respondiente de reconocimiento público.

Excepción: si espera muchas respuestas idénticas, puede decir: “Escríbanme y resumiré para la lista”, pero cumpla la promesa.

Sea específico

Las preguntas vagas se consideran agujeros sin fondo. Los expertos tienen tiempo escaso; cuanto más claramente diga qué necesita (orientación, código, revisión de parche), más probabilidades tiene de recibir ayuda.

Ej.: mejor “¿Dónde hay una buena explicación de X?” que “Explíquenme X”.

Sobre código

No pida que depuren cientos de líneas sin indicar dónde mirar. Pegue un fragmento breve y diga: “Tras la línea 7 debería aparecer pero sale ”.Es muy probable que obtengas una respuesta.

La forma más precisa de describir un problema de código es proporcionar un ejemplo mínimo que lo demuestre. ¿Qué es un ejemplo mínimo? Es una representación del problema que contenga únicamente el código necesario para reproducir el comportamiento inesperado. ¿Cómo se genera? Si sabes qué línea o fragmento causa el problema, cópialo y añade solo el código auxiliar imprescindible para que el ejemplo sea completo (lo justo para que el compilador, intérprete o cualquier otro programa lo acepte). Si no puedes reducirlo a un fragmento concreto, copia el código fuente y elimina todo lo que no esté relacionado con el problema. Cuanto más pequeño sea el ejemplo, mejor (ver menos es más).

No siempre es posible crear un ejemplo mínimo diminuto, pero esforzarse en ello es un excelente ejercicio que puede ayudarte a resolver el problema por ti mismo. Aunque no lo logres, a los hackers les gusta ver que lo has intentado, lo que hará que se muestren más colaboradores.

Si solo quieres que alguien revise tu código, indícalo desde el principio y señala qué parte crees que necesita atención y por qué.

No envíes tareas de clase

Los hackers detectan con facilidad las preguntas tipo “tarea”. La mayoría ya hicimos los deberes; eso es lo que debes hacer tú y así aprenderás. Preguntar por pistas está bien, pero no pidas la solución completa.

Si sospechas que se trata de una tarea y aún así no puedes resolverla, prueba en grupos de usuarios, foros o, en última instancia, en la lista de correo o foro de “usuarios” del proyecto. Aunque los hackers lo notarán, algún veterano podría darte una pista.

Elimina peticiones sin sentido

Evita añadir frases como “¿alguien puede ayudarme?” o “¿hay alguna respuesta?” al final de tu mensaje. Primero, si la descripción del problema es incompleta, esas frases son redundantes. Segundo, los hackers las consideran molestas y responderán con algo lógicamente correcto pero inútil, como “sí, puedes obtener ayuda” o “no, no hay ayuda para ti”.

En general, evita preguntas de sí o no, salvo que esperes una respuesta de ese tipo.

No marques tu pregunta como “urgente”, aunque lo sea para ti

Es tu problema, no el nuestro. Etiquetarlo como “urgente” suele tener el efecto contrario: la mayoría de los hackers borrarán el mensaje, considerándolo una petición egoísta de atención inmediata. Además, palabras como “urgente” pueden activar filtros de spam y tus destinatarios ni siquiera lo verán.

Hay una excepción muy localizada: si usas el programa en un entorno tan visible que entusiasme a los hackers, podría merecer la pena. En ese caso, menciona cortésmente que tienes una fecha límite; alguien podría acelerar la respuesta.

Es arriesgado: el criterio de “emocionante” de los hackers rara vez coincide con el tuyo. Publicar desde la Estación Espacial Internacional está bien; hacerlo por una causa benéfica o política, casi seguro que no. De hecho, un mensaje como “¡URGENTE: ayudad a salvar a esta adorable foca!” será ignorado o tomado con irritación.

La cortesía siempre ayuda

Sé educado: usa “por favor” y “gracias por tu atención” o “gracias por tu tiempo”. Deja claro que agradeces que alguien dedique su tiempo libre a ayudarte.

Sin embargo, la cortesía no sustituye a un mensaje bien escrito, claro, preciso, con contenido y sin formatos propietarios. Los hackers prefieren un informe de bug algo brusco pero técnico, a uno cortés pero vago.

Si ya has explicado bien el problema técnico, un extra de cortesía aumentará tus posibilidades de recibir una respuesta útil.

(El único punto que algunos veteranos critican es el “gracias de antemano”; piensan que implica que no volverás a dar las gracias después. Nuestra recomendación: o bien das las gracias dos veces, o usa “gracias por tu atención”.)

Cuando se resuelva, añade un breve resumen

Una vez resuelto, envía un mensaje a todos los que ayudaron, explicando cómo se solucionó y agradeciendo de nuevo. Si la discusión fue pública, publícalo allí.

Lo ideal es responder al hilo original con un asunto que incluya “Resuelto”, “Solucionado” o similar. Así, quien vea “Problema X” y “Problema X – Resuelto” sabrá que no necesita invertir más tiempo.

El resumen puede ser breve: “Hola: era el cable de red. ¡Gracias a todos! – Bill” basta. A no ser que la solución sea muy técnica, unas líneas amables valen más que un largo drama.

Para problemas complejos, incluye un resumen del historial de pruebas: estado final, qué lo arregló y qué caminos evitar. Pon los nombres de quienes ayudaron: ganarás amigos.

Este tipo de seguimiento ayuda a otros a encontrar la solución en archivos o foros y da satisfacción a quienes participaron. Sentir que el problema quedó cerrado es importante para los hackers. Además, esa “picadura” satisfecha genera reputación que te servirá la próxima vez.

Considera también si puedes evitar que otros caigan en el mismo error: ¿merece la pena un documento o un parche al FAQ? Si es así, envíalo al mantenedor.

En la cultura hacker, este tipo de cierre es más valioso que la simple cortesía: es cómo te ganas una buena reputación.

Cómo interpretar las respuestas

“RTFM” y “STFW”: cómo saber que te la has cargado

La tradición sagrada dice: si te responden “RTFM” (Read The Fucking Manual), es que creen que deberías leer el manual. Y probablemente tengan razón: léelo.

Su pariente más joven es “STFW” (Search The Fucking Web): el remitente piensa que deberías buscar en internet. Y también suele tener razón: búscalo. (Una versión más suave es “Google es tu amigo”.)

En foros también te pueden pedir que busques en los documentos. No dependas de esa ayuda: búscalos tú antes de preguntar.

Quien te lo dice ya tiene el manual o la página abierta mientras te escribe. Su mensaje significa:

  1. La información es fácil de encontrar.
  2. Aprenderás más buscando por ti mismo.

No te ofendas: según los estándares hacker, responder ya es un signo de respeto.

Si aún no entiendes…

Si no comprendes la respuesta, no pidas aclaraciones inmediatamente. Usa los mismos recursos que al principio (manual, FAQ, web, amigos expertos). Si aún necesitas ayuda, muestra lo que ya has entendido.

Ejemplo:
Mala réplica: “¿Qué es ‘cierta entrada’?”
Buena réplica: “Leí el manual: ‘cierta entrada’ solo se menciona con las opciones -z y -p, pero no explica cómo limpiarla. ¿A cuál te refieres o qué estoy pasando por alto?”

Frente a la grosería

Muchas actitudes que parecen groseras no lo son: es un estilo directo y eficiente, propio de quien prioriza resolver el problema sobre la diplomacia.

Si te sientes ofendido, reacciona con calma. Si alguien se pasa, los veteranos suelen intervenir. Si no lo hacen y tú estallas, puede que la comunidad te vea a ti como el problema, lo que dañará tus posibilidades de obtener ayuda.

En raras ocasiones habrá verdadera grosería. Entonces sí que puedes contraatacar con dureza, pero asegúrate de tener la razón. Corregir una ofensa real y entrar en una guerra de troleo es muy distinto; si eres novato, es fácil pasarse de la raya. Si lo que quieres es información, no arriesgues.

(Algunos afirman que muchos hackers tienen autismo leve o síndrome de Asperger; da igual si es cierto o no. Si no eres hacker, pensar que estamos “raros” puede ayudarte a manejar nuestras costumbres. Nos da igual: nos gusta ser así.)

No reacciones como un perdedor

En algún momento la cagarás (o parecerá que lo hiciste) y te lo mostrarán, quizá con color.

Lo peor que puedes hacer es quejarte, exigir disculpas, amenazar con abogados, escribir al jefe del otro, etc. En su lugar:

Aguanta, es normal y hasta saludable.

Los estándares de la comunidad se mantienen públicamente. No exijas que las críticas lleguen por privado; no funciona así. Lloriquear porque “te atacan” tampoco ayuda.

Hay foros que, en nombre de la “cortesía”, prohíben criticar; los participantes útiles se van y quedan solo charlas vacías. ¿Prefieres “amistad” vacía o utilidad?

Cuando un hacker te dice que la regaste y te pide que no lo repitas, está cuidando de ti y de la comunidad. Ignorarte sería más fácil. Si no puedes agradecer, al menos conserva la dignidad.

A veces te atacarán sin motivo. Quejarte entonces sí que empeorará las cosas. Esos trols suelen ser incompetentes o están probando si te desquicias. El resto los ignorará o les responderá. No te metas en su juego.

Preguntas prohibidas

Ejemplos de preguntas tontas y lo que piensan los hackers:

P: ¿Dónde puedo encontrar el programa X?
P: ¿Cómo hago Y con X?
P: ¿Cómo configuro mi prompt del shell?
P: ¿Puedo convertir documentos AcmeCorp a TeX con Bass-o-matic?
P: Mi {programa, configuración, SQL} no funciona.
P: Mi PC con Windows falla, ¿me ayudas?
P: Mi programa no corre; creo que el sistema X está roto.
P: No consigo instalar Linux, ¿me ayudas?
P: ¿Cómo hackeo la clave de root/robo privilegios/veo el correo de alguien?

P: ¿Dónde puedo encontrar el programa X?
R: En el mismo sitio que yo: el buscador. ¿Acaso alguien no sabe usar Google?

P: ¿Cómo hago Y con X?
R: Si quieres Y, no preguntes por X que quizá no sirva. Pregunta por Y directamente.

P: ¿Cómo configuro mi prompt del shell?
R: Si eres lo bastante listo para preguntar, también para leer el manual.

P: ¿Puedo convertir… con Bass-o-matic?
R: Pruébalo. Así sabrás la respuesta y no me harás perder el tiempo.

P: Mi {código} no funciona.
R: Eso no es una pregunta. ¿Qué más me cuentas? Oh, qué pena, espero que lo arregles.

P: Mi PC con Windows falla…
R: Sí, borra Windows y pon Linux o BSD.
(Nota: si el programa tiene versión oficial para Windows o interactúa con él, sí puedes preguntar, pero no te sorprendas si la culpa es del sistema.)

P: Creo que la herramienta del sistema X está rota.
R: Necesitas evidencias sólidas. Un fallo así, si fuera real, ya lo habría notado alguien más.

P: No consigo instalar Linux…
R: Necesitaría acceso físico a tu máquina; busca un grupo local de usuarios.
(Nota: si el problema es específico de una distribución, pregunta en sus listas o foros, después de buscar.)

P: ¿Cómo hackeo…?
R: Querer hacer eso te hace miserable; pedir que te enseñen te hace idiota.

Buenas y malas preguntas

Mala: ¿Dónde encuentro info sobre el Foonly Flurbamatic?
(Invita a “STFW”.)

Buena: Busqué “Foonly Flurbamatic 2600” en Google y no encontré nada útil. ¿Alguien sabe dónde hay documentación de programación?

Mala: No puedo compilar el código de ProyectoX, ¿por qué es tan malo?
(Asume que la culpa es ajena.)

Buena: El código de ProyectoX no compila en Linux 6.2. Leí el FAQ pero no hay nada sobre esta versión. Aquí está el log del error. ¿Qué estoy haciendo mal?

Mala: Mi placa base falla, ¿alguien me ayuda?
(Respuesta probable: “¿También quieres que te cambiemos el pañal?”)

Buena: En la placa S2464 probé X, Y, Z; luego A, B, C. Al probar C vi este síntoma raro… ¿Qué suele causar esto en placas Athlon MP? ¿Qué más puedo probar?

La diferencia entre “dame la respuesta” y “¿en qué más puedo investigar?” es sutil pero crucial.

La última pregunta es real: en agosto de 2001 pregunté en la lista lkml por un fallo extraño en la Tyan S2462. Obtuve la clave para resolverlo. No fue por mi nombre, sino por cómo planteé la pregunta: mostré lo que ya había hecho, respeté el tiempo de los demás y los invité a colaborar. Eso inspiró este artículo.

Si no obtienes respuesta

No significa que no queramos ayudar; a veces nadie sabe la respuesta. Repostear inmediatamente es molesto. Sé paciente: quien pueda ayudarte quizá esté durmiendo o tu pregunta esté mal formulada.

Existen otros recursos: grupos de usuarios, foros locales, listas de novatos, empresas de soporte comercial. Pagar por soporte no es malo: si se te rompe la junta de la cabeza del coche, la llevas al taller. Incluso el software libre suele ser más barato que el propietario más su soporte.

Cómo dar buenas respuestas

Sé amable. El estrés hace que la gente parezca brusca; no lo es.

A los primerizos, respóndeles en privado. No hay necesidad de humillar.

Si no estás seguro, dilo. Una respuesta errónea con aires de autoridad es peor que el silencio.

Si no puedes ayudar, al menos no estorba. No bromees sobre pasos que puedan estropearle la instalación a alguien.

Haz preguntas exploratorias para obtener más detalles. Convierte malas preguntas en buenas.

Si vas a responder, da una buena respuesta. No recomiendes parches chapuceros; sugiere mejores herramientas o replantea el problema.

¡Responde la pregunta real! Si alguien ya probó X, Y, Z, A, B y C, no le digas “prueba A o B”.

Ayuda a la comunidad: tras responder, pregúntate “¿cómo puedo mejorar la documentación para que no vuelvan a preguntar esto?” y envía el parche.

Cuando tu respuesta requiera investigación, muestra el camino, no solo el resultado: “enseña a pescar en lugar de dar el pez”.### Recursos relacionados

Si necesitas conocimientos básicos sobre cómo funcionan las computadoras personales, Unix e Internet, consulta Fundamentos del funcionamiento de Unix e Internet.

Cuando publiques software o parches, intenta seguir las Prácticas de publicación de software.

Agradecimientos

Evelyn Mitchell aportó algunos ejemplos de preguntas tontas e inspiró la redacción de la sección «Cómo responder preguntas de manera más útil», y Mikhail Ramendik contribuyó con sugerencias y mejoras especialmente valiosas.

基于STM32的同步整流Buck-Boost数字电源 开源
LCD1602 I2C模块无法显示字符