¿Cómo preguntar?

Encontré esto, y si bien está preparado hacia las listas de correo, nunca está de más recordarlo en un foro, donde abundan lo threads con títulos del estilo "Ayuda con mi problema", "Como solucionar esto", o que no se detalla con precisión el problema. Espero que haga reflexionar a muchos​

:encouragement:



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
——————————————————————————–
Traducciones
Este 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:
Welcome to the Tuxedo.org!
Existen traducciones de este documento disponibles en Alemán y en Francés.
——————————————————————————–
Introducción
En 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 preguntar
Antes 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 pregunte
Escoja 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.
——————————————————————————–


[Sigue...]

excelente información

Buenisimo 🙂

Gracias por el aporte🙄🙄🙄