4.            Quando perguntar

4.1.              Escolha seu fórum com critério

4.2.              Sempre que possível use a lista do próprio projeto

4.3.              O campo assunto deve condensar objetivamente a sua dúvida

4.4.              Facilite a resposta

4.5.              Escreva de modo claro respeitando a ortografia e a gramática

4.6.              Envie sua pergunta num formato de fácil entendimento

4.7.              Seja preciso e informativo sobre seu problema

4.8.              Volume não é precisão

4.9.              Não reivindique que você encontrou um bug

4.10.          Humildade não garante que os outros façam as suas obrigações

4.11.          Descreva os sintomas do problema, não suas suposições

4.12.          Descreva os sintomas do problema em ordem cronológica

4.13.          Descreva o objetivo, não as etapas

4.14.          Não peça para as pessoas responderem em privado

4.15.          Seja explícito sobre a questão que você tem

4.16.          Não queira que os outros resolvam suas tarefas

4.17.          Evite perguntas semanticamente nulas

4.18.          Não destaque sua questão como “urgente”, mesmo que para você ela seja

4.19.          Cortesia numa é demais, e algumas vezes ajuda

4.20.          Feche o tópico com uma breve nota sobre a solução

  5.            Como interpretar respostas

5.1.              RTFM e STFW: Como lhe dizer que você passou da conta

5.2.              Se você não entende…

5.3.              Lidando com grosserias

  6.            Não reaja como um mané

  7.            Perguntas que não devem ser formuladas

  8.            Perguntas boas e más

  9.            Caso você não consiga uma resposta

  10.        Como responder perguntas de modo proveitoso

  11.        Recursos relacionados

  12.        Observação especial para mantenedores de listas de FAQ e webmasters

  13.        Agradecimentos

1. Negação de responsabilidade

Muitos websites dedicados a projetos possuem um link para este guia na seção de como obter ajuda. Isto é bom, é o tipo de uso que nós temos em mente, mas se você é o webmaster que colocou este link lá, por favor, coloque em destaque próximo ao link o aviso de que nós não somos a central de ajuda (help desk) de nenhum projeto.

Nós aprendemos do modo mais difícil que sem este aviso, nós seremos incomodados repetidamente por imbecis que pensam que por termos publicado este guia, nós temos a obrigação de resolver todos os problemas técnicos do mundo.

Se você está lendo este guia porque precisa de ajuda, e ficou com a impressão de que pode consegui-la diretamente dos autores, você é um dos imbecis em questão. Não nos pergunte nada. Nós vamos lhe ignorar. Nós estamos aqui para lhe mostrar como obter ajuda de pessoas que realmente conhecem o software ou hardware com o qual você está lidando, mas em 99 por cento do tempo não seremos nós. A menos de que você tenha certeza de que um dos autores é um especialista sobre o a questão que está lhe incomodando, esqueça-nos e todo mundo será mais feliz.

2. Introdução

No mundo dos hackers, o tipo de resposta que você obtém para sua pergunta técnica depende da maneira que você formulou a pergunta e da dificuldade de desenvolver a resposta. Este guia lhe ensinará como formular perguntas de modo que seja provável que você obtenha uma resposta satisfatória.

A primeira coisa que você deve entender é que os hackers gostam de problemas complexos e das perguntas capazes de desafiar as suas inteligências. Se não fosse assim, nós não estaríamos aqui. Se você nos der uma questão interessante para nos ocupar, nós lhe seremos grato, pois questões deste tipo ajudam-nos a desenvolver nosso entendimento, e freqüentemente revelam problemas que nos podemos não ter observado ou pensado a respeito. Entre os hackers, “boas questões” são um forte e sincero cumprimento.

Apesar disto, os hackers têm uma reputação de reagirem com hostilidade e arrogância quando se defrontam com perguntas primárias. Algumas vezes parece que nós reagimos automaticamente de modo rude com novatos e ignorantes Isto não é verdade.

O que nós somos, sem nenhum constrangimento, é hostil para com pessoas que parecem ser incapazes de pensar ou de fazer seu próprio tema de casa antes de formular perguntas. Pessoas assim é desperdício de tempo, eles demandam sem dar nada em troca, eles consomem tempo que nós poderíamos dedicar numa outra questão mais interessante ou com uma outra pessoa que fosse merecedora de uma resposta. Nós chamamos estas pessoas de “losers” 
(NT: “perdedores”, no Brasil atualmente seriam chamados de “manés”) (e por razões históricas algumas vezes nos soletramos “lusers”) 
(NT: contração das palavras “loser” e “user” querendo indicar um usuário mané).

Nós sabemos que existem muitas pessoas que querem apenas utilizar o software que nos escrevemos e não tem nenhum interesse em aprender detalhes técnicos. Para a maioria das pessoas, um computador é meramente uma ferramenta, um meio para um fim, eles têm coisas mais importantes para fazer e vidas para viver. Nós agradecemos por isto, e não esperamos que todos sejam tomados de interesse pelas matérias técnicas que nos fascinam. Apesar disto, nosso estilo de responder perguntas é voltada para pessoas que tenham interesse e estão dispostas a se tornarem participantes ativos na resolução de problemas. Isto não vai mudar, nem deve mudar, pois se mudasse, nós nos tornaríamos menos confiáveis nas coisas que fazemos melhor.

Nós somos (a grande maioria) voluntários. Nós despendemos tempo do nosso ocupado dia a dia para responder perguntas, e algumas vezes, nós ficamos totalmente envolvidos com algumas questões. Em conseqüência nós somos muito seletivos. Particularmente, nós desconsideramos perguntas de pessoas que parecem manés para desta forma darmos uma melhor atenção para pessoas que valham a pena.

Se você considera esta atitude detestável, intransigente ou arrogante, verifique nossas premissas. Nós não estamos pedindo que você se ajoelhe diante de nos, na verdade a maioria de nos adoraria interagir com você como um dos nossos e lhe dar as boas vindas na nossa cultura, mas só se você colocar o esforço necessário para tornar isto possível. Para nós é simplesmente ineficiente tentar ajudar pessoas que não fazem força para se auto-ajudar. Não existe nenhum problema em ser ignorante, mas não é aceitável agir estupidamente.

Assim, embora não seja necessário já ser competente tecnicamente para obter a nossa atenção, é necessário demonstrar o tipo de atitude que conduz a competência – atenção, solicitude, observador, esforço para ser um parceiro atuante no desenvolvimento de uma solução. Se você não pode conviver com este tipo de discriminação, nós sugerimos que você pague alguém por um contrato de suporte comercial ao invés de pedir para os hackers pessoalmente doarem ajuda para você.

Se você decidir buscar-nos para ajuda, você não quer ser um dos manes. Nem você quer parecer com eles. A melhor maneira de obter uma resposta rápida e satisfatória é perguntar como uma pessoa inteligente, confiante e que só necessita ajuda em algum problema particular.

Sugestões de melhorias deste guia serão bem vindas. Você pode envia-las para  esr@thyrsus.com. Observe contudo que este documento não tem a intenção de ser um guia geral para netiquette (netiqueta)
(NT: Contração de Network+Etiquette significando regras de boas maneiras na Internet), e eu geralmente rejeitarei sugestões que não sejam especificamente voltadas para trazer respostas úteis em um fórum técnico.

3. Antes de perguntar

Antes de fazer uma pergunta técnica por email, em um grupo de discussão ou então num grupo de conversação (Chat) pela Internet, realize as etapas abaixo:

a)     Procure encontrar a resposta pesquisando na Internet.

b)     Procure encontrar a resposta lendo o manual.

c)     Procure encontrar a resposta lendo uma FAQ 
(NT: acrônimo de “Frequently Asked Questions”, significando uma lista de questões freqüentemente formuladas).

d)     Procure encontrar a resposta examinando ou experimentando.

e)     Procure encontrar a resposta perguntando a um amigo mais experiente.

f)       Se você é um programador, procure encontrar a resposta lendo o código fonte.

Quando você formular sua questão, primeiramente relate as coisas que você já fez, isto ajudará a estabelecer que você não é uma esponja preguiçosa consumidora do tempo dos outros. Melhor ainda, relate o que você apreendeu fazendo estas coisas. Nós gostamos de responder questões para pessoas que demonstram que eles podem apreender a partir das respostas.

Use táticas como pesquisar com mecanismos de busca tipo Google usando palavras da mensagem de erro que você recebeu. Isto poderá levá-lo diretamente para documentos que ensinam como corrigir o problema ou para um conjunto de mensagens postadas em um grupo de discussão que lhe responderão a pergunta. Mesmo que você não tenha sucesso, dizendo “eu pesquisei usando a seguinte frase, mas não obtive nada de útil” é algo bom de se colocar numa mensagem solicitando ajuda.

Prepare sua pergunta. Analise ela do começo ao fim. Questões vagas recebem respostas vagas, ou nem isto. Quanto mais você demonstrar que você refletiu e se esforçou procurando resolver o seu problema antes de pedir ajuda, maior será a probabilidade de conseguir uma ajuda de verdade.

Evite fazer perguntas conceitualmente incorretas. Se você perguntar alguma coisa que está baseada numa premissa incorreta, é provável que alguém lhe responda com uma resposta “ao pé da letra” totalmente inútil para você enquanto pensa, “pergunta idiota ...”, esperando que a experiência de obter o que você perguntou ao invés do que você necessitava lhe ensinará uma lição.

Nunca assuma que você tem direito a uma resposta. Você não tem este direito garantido, afinal de contas você não está pagando por este serviço. Você receberá uma resposta, caso a sua pergunta tenha substância, seja interessante, seja desafiadora, uma pergunta que implicitamente contribua para o crescimento da comunidade ao invés de meramente demandar conhecimento dos outros.

Por outro lado, deixando claro que você é capaz e deseja ajudar no processo de desenvolver uma solução é um ótimo inicio. “Alguém tem uma pista?”, “O que está faltando no meu exemplo?” e “Existe algum outro site que eu deveria ter verificado?” tem muito mais probabilidade de obter uma resposta do que “Por favor informe o procedimento exato que eu devo seguir.” porque você está deixando claro que completará o processo se alguém lhe indicar a direção correta.

4. Quando perguntar

4.1. Escolha seu fórum com critério

Seja cuidadoso ao escolher onde formular sua questão. Você provavelmente será ignorado ou considerado um mané caso:

Colocar sua pergunta em um fórum onde ela é off topic 
(NT: algumas vezes abreviado como OT, significa fora do contexto do fórum / lista).

Colocar pergunta muito elementar em um fórum dedicado a questões técnicas avançadas, a situação oposta também é verdadeira.

Fizer postagem cruzada em diferentes grupos de discussão.

Colocar uma mensagem pessoal para alguém que não é das suas relações nem pessoalmente responsável por resolver os seus problemas.

Os hackers desconsideram perguntas que são inapropriadas de modo a evitar seus canais de comunicação possam ser tomados com irrelevâncias. Você não quer que isto aconteça com você.

O primeiro passo, portanto, é encontrar o fórum certo. Novamente, o Google ou outro serviço de busca na Internet será o seu amigo. Utilize-os para encontrar a homepage do projeto que estiver mais associada com o hardware ou software que lhe está dando problemas. Normalmente ela terá conexão com uma lista de FAQ e com listas de mensagens e seus arquivos. Estas listas são os últimos lugares para buscar ajuda, se seus próprios esforços (inclusive ler aqueles FAQ que você encontrou) não lhe mostrarem uma solução.

Enviar uma mensagem para uma pessoa ou fórum que você não conhece sempre envolve algum risco. Por exemplo, não assuma que o autor de uma página informativa deseja ser seu consultor gratuito. Não faça suposições otimistas de que sua pergunta será bem recebida, se você não tem certeza, mande-a para algum outro lugar ou então se contenha de espalhá-la para meio mundo.

Quando estiver escolhendo um grupo de notícias ou lista de discussão, não confie apenas no nome, procure por uma FAQ ou por um documento ou página que deixe claro os propósitos daquele grupo. Fazendo isto você poderá verificar se a sua pergunta é ou não on-topic. Observe as mensagens que são trocadas antes de enviar a sua, isto lhe dará uma idéia de como as coisas são feitas ali. Na verdade, fazer uma busca com palavras relacionadas com o seu problema antes de enviar a sua pergunta é uma ótima idéia. Isto pode lhe trazer a resposta e se não trouxer poderá lhe ajudar para formular melhor a sua pergunta.

Conheça qual é o seu tópico. Um erro clássico é perguntar sobre interface de programação Unix ou Windows em um fórum dedicado a uma linguagem ou biblioteca ou ferramenta que pode ser portável para os dois. Se você não compreende porque isto é um grave erro, seria muito bom que você não perguntasse nada até que compreenda.

Em geral, perguntas para um fórum público bem selecionado têm maior probabilidade de receberem uma resposta útil do que em fóruns fechados. Existem muitas razões para isto. Uma é o número de pessoas com potencial de responder. Outra é o número de membros, os hackers preferem responder perguntas que possam esclarecer muitas pessoas do que as que servem apenas a uns poucos.

De modo muito compreensível, hackers habilidosos e autores de programas populares já estão recebendo mais do que seria justo de mensagens fora de escopo. Sendo mais um nesta categoria, você poderá ser em casos extremos a gota d’água que vai entornar o copo, o que algumas vezes contribui para que projetos populares cancelem o suporte devido ao trafico de mensagens inúteis para suas contas pessoais se tornar intolerável.

4.2. Sempre que possível use a lista do próprio projeto

Quando um projeto tem uma lista para troca de mensagens, escreva para a lista e não para os desenvolvedores, mesmo que você acredite que você conhece quem pode responder melhor a sua pergunta. Verifique a documentação do projeto e sua homepage em busca do endereço da lista para troca de mensagens e utilize-a. Existem varias boas razões para esta pratica:

·         Qualquer questão que é boa o suficiente para ser respondida por um dos desenvolvedores também será de valor para todo o grupo. Em caso contrário, se você suspeita que sua questão é muito simplória para a lista, isto não é desculpa para incomodar algum desenvolvedor em particular.

·         Perguntando na lista distribui a carga entre os desenvolvedores. O desenvolvedor individual (especialmente se ele é o líder do projeto) pode estar muito atarefado para responder sua questão.

·         A maioria das listas possuem arquivos e os arquivos são indexados por mecanismos de busca. Alguém pode encontrar sua pergunta e a resposta na Internet dispensando uma nova consulta na lista.

·         Se algumas questões são levantadas com muita freqüência, os desenvolvedores podem usar esta informação para melhorar a documentação do software de modo a deixar o assunto mais claro. Se estas questões forem formuladas de maneira privada, ninguém poderá saber quais as duvidas que mais se repetem.

Se você não puder encontrar o endereço de uma lista de mensagens do projeto, mas somente o endereço do mantenedor do projeto, vá em frente e escreva para o mantenedor. Mesmo numa situação assim, não assuma que a lista do projeto não exista. Deixe claro na sua mensagem que você tentou, mas não conseguiu encontrar a lista apropriada. Também mencione que você não tem objeção em ter a sua mensagem repassada para terceiros (muitas pessoas acreditam que mensagem privada deveria permanecer privada, mesmo sem conter nada de confidencial. Consentindo que sua mensagem seja repassada você dá ao seu correspondente uma escolha sobre como lidar com a sua mensagem).

4.3. O campo assunto deve condensar objetivamente a sua dúvida

Em grupos de discussão ou fóruns, o campo assunto lhe oferece uma oportunidade de ouro para atrair a atenção de especialistas altamente qualificados fazendo uso de no máximo 50 caracteres. Não desperdice a oportunidade com bobagens como “Por favor, ajudem-me” (jamais “POR FAVOR, AJUDEM-ME!!!!!!”, mensagens trazendo no campo assunto este tipo de descrição são apagadas num ato de reflexo condicionado). Não tente nos impressionar com a profundidade da sua angustia, ao invés disto use o espaço para uma descrição super concisa do problema.

Uma boa convenção para o campo assunto, utilizada por muitas organizações de suporte técnico é “objeto – desvio”. O “objeto” especifica que coisa ou grupo de coisas está tendo um problema, e o “desvio” descreve o desvio em relação ao comportamento esperado.

Burra:

AJUDEM! Vídeo não funciona corretamente no meu laptop!

Inteligente:

Cursor do mause deformado no Xfree86 4.1, vídeo chipset Fooware MV1005

Brilhante:

Cursor do mause no Xfree86 4.1 com video chipset Fooware MV1005 – está deformado

O processo de escrever uma descrição no formato “objeto-desvio” lhe ajudará a organizar o pensamento em relação ao problema com mais detalhes. O que está afetado? Apenas o cursor do mause ou outros objetos gráficos também? Isto é específico para o XFree86? Para a versão 4.1? Isto é específico dos chipsets de vídeo Fooware? Para o modelo MV1005? Um hacker que ler o resultado pode imediatamente entender com o que você está tendo problema e qual é o problema, num piscar de olhos.

Se você formular uma questão quando responder uma mensagem, não esqueça de mudar a linha de assunto para indicar que você está perguntando alguma coisa. Uma linha de assunto como “Re: teste” ou “Re: novo bug” tem pouca chance de chamar a atenção de quem realmente tem algo para contribuir. Também elimine quotes 
(NT: conteúdo de outras mensagens) das mensagens anteriores ao máximo, deixando apenas o que for absolutamente necessário para o entendimento do assunto por parte de novos leitores.

Não clique automaticamente no botão responder para um grupo de discussão quando quiser iniciar um tópico totalmente novo. Isto limitará suas chances de obter uma resposta. Alguns aplicativos de email, como o Mutt, permitem classificar as mensagens por tópico e colocam todas as mensagens de um mesmo tópico numa pasta. Para ver as mensagens é necessário abrir a pasta. Se o usuário que usa este recurso não tiver interesse no assunto que você escolheu para encabeçar a sua mensagem, ele jamais tomará conhecimento da mesma. Se tiver interesse no assunto, vai julgar sua mensagem fora do contexto e muito provavelmente mandar ela para a lata de lixo.

Mudar o assunto não é suficiente. O Mutt (e provavelmente outros aplicativos de email) examina outras informações no cabeçalho e não somente a linha de assunto antes de atribuí-la para uma pasta. Por estas razões comece uma mensagem nova para tratar de um assunto novo.

4.4. Facilite a resposta

Terminando sua pergunta com “Por favor mande sua resposta para ...” torna bastante improvável que você obtenha uma resposta. Se você não pode dispensar alguns poucos segundos para definir um cabeçalho correto de Responder Para no seu programa de email, nós também não podemos dispensar alguns poucos segundos pensando no seu problema. Se seu programa de email não permite isto, consiga um programa melhor. Se seu sistema operacional não suporta nenhum programa de email que permita isto, consiga um sistema operacional melhor.

4.5. Escreva de modo claro respeitando a ortografia e a gramática

Nos apreendemos pela experiência que pessoas que escrevem com descuido e desatenção são igualmente assim quando pensam e codificam. Responder questões para pessoas descuidadas e desatentas não é algo recompensador e nós preferimos gastar nosso tempo com outras coisas.

Assim, é importante expressar sua questão de modo claro e bem. Se você não tem tempo para isto, nós não temos tempo para lhe dar atenção. Dispense um esforço extra para melhorar sua linguagem. Ela não precisa ser rebuscada ou formal, na verdade, a cultura hacker valoriza o informal, gírias e bom humor usado no momento certo. Mas ela tem que ser precisa, deve haver alguma indicação de que você está pensando e prestando atenção.

Escreva, pontue e use maiúsculas corretamente. Não confunda “passo” com “paço”, “senso” com “censo” ou “conserto” com “concerto”. Não ESCREVA COM TODOS OS CARACTERES EM MAIÚSCULO, isto é lido com se você estivesse gritando e é considerado rude (escrever com todos os caracteres minúsculos mas com um tamanho de letra que dificulta a leitura é quase tão irritante quanto a situação anterior. Alan Cox pode fazer isto, mas você não) 
(NT: Alan Cox é uma das pessoas mais importantes que estão por trás do sistema operacional Linux)

De maneira mais geral, se você escreve como um idiota semi-alfabetizado, você muito provavelmente será ignorado. Escrever como um “l33t script kiddie hax0r” é absolutamente fatal e uma garantia de que você não receberá nada a não ser um silencio absoluto. 
(NT: o texto colocado entre aspas foi escrito usando a chamada linguagem script kiddie utilizada por pessoas, em geral adolescentes, que escrevem na Internet de uma maneira característica, como dEliBeRadAmentE miXTurAr lEtRas MaiÚsCuLAs e mInúScUlAS, ou usando num3r0s para subs7i7uir 137ras – 3=E, 7=T, 1=L, 133t = Elite, hax0r = hacker. Outro exemplo: "1 4m 1337 h4x0r, d00d. 1 0WnZ3d j00!" = “I am an elite hacker, dude. I owned you!" = “Eu sou um hacker de elite meu chapa. Eu possuo você”.).

Se você estiver perguntando em um fórum que não usa sua língua mãe, você receberá algumas gozações por erros de ortografia e gramática, mas nenhum por preguiça. Também, a menos de que você conheça a língua dos que vão responder, escreva em inglês. Hackers atarefados tendem a desconsiderar mensagens escritas num idioma que eles não entendem, e o inglês é a língua da Internet. Escrevendo em inglês você estará minimizando suas chances de ter sua mensagem apagada sem ser lida.

4.6. Envie sua pergunta num formato que facilite o entendimento

Se você intencionalmente torna sua mensagem difícil de ler, ela muito provavelmente será deixada de lado em favor de outra que não seja difícil de ler. Assim:

·         Use mensagem de texto puro ao invés de HTML (não é difícil desativar HTML).

·         Anexos MIME (Multipurpose Internet Mail Extensions) normalmente são aceitáveis, mas somente se eles tiverem conteúdo útil (como um arquivo fonte ou patch) e não porcaria gerado por seu programa de email (como uma outra cópia da sua mensagem). 
(NT: para conhecer mais sobre MIME clique aqui)

·         Não envie mensagens na qual parágrafos inteiros são escritos numa única linha (isto torna muito difícil responder apenas parte da mensagem). Considere que quem vai responder estará lendo a mensagem num monitor com tela para 80 caracteres e ajuste sua quebra de linha para um valor alguma coisa abaixo de 80.

·         Como toda regra tem uma exceção, não quebre linhas de dados (tais como um log file ou a transcrição de uma seção). Os dados devem ser incluídos como são, desta forma quem responder pode ter certeza de que o que ele está vendo é o que você vê.

·         Não envie quotes codificados em MIME para um fórum de língua inglesa. Estes códigos podem ser necessários quando você está escrevendo em um idioma com caracteres não cobertos pelo código ASCII, mas muitos programas de email não têm suporte para eles. Quando eles são “traduzidos”, vários caracteres totalmente sem sentido ficam espalhados pelo texto tornando a leitura muito desagradável.

·         Jamais espere que os hackers sejam capazes de ler documentos escritos em formatos proprietários como, por exemplo, Microsoft Word. Muitos hackers reagem a isto da mesma forma que você faria se encontrasse uma pilha de fezes recém defecadas na porta de sua casa.

·         Se você está enviando email de um computador com sistema operacional Windows, desative o recurso imbecil de “Smart Quotes”. Isto evitará que você venha a espalhar caracteres totalmente desnecessários pela sua mensagem.

Se você estiver usando um cliente de email para ambiente gráfico (como o Netscape Messenger, MS Outlook ou similar) esteja atento que estes programas podem violar estas regras quando utilizados com seus ajustes padrões (default). A maioria destes aplicativos tem um comando do tipo “Ver Fonte”. Use este recurso em algumas de suas mensagens que ficam na caixa de enviadas para ter certeza de que você está enviando texto puro sem mais alguma coisa totalmente inútil.

4.7. Seja preciso e informativo sobre seu problema

·         Descreva os sintomas do seu problema ou bug com cuidado e de modo muito claro.

·         Descreva o ambiente no qual ele ocorre (computador, sistema operacional, aplicativo, etc.). Informe o desenvolvedor e a versão (por exemplo, “Red Hat 8.0”, “Slackware 5.1”, etc.).

·         Descreva as pesquisas que você fez para entender e resolver o problema ante de perguntar.

·         Descreva as etapas do diagnostico que você fez para esclarecer o problema antes de perguntar.

·         Descreva todas as alterações mais recentes em seu computador ou configuração de software que possa ser relevante.

Se esforce para antecipar as perguntas que um hacker fará, e responda as mesmas em avanço no seu pedido de ajuda.

Simon Tatham escreveu um excelente ensaio intitulado How to Report Bugs Effectively  
(NT: Como Relatar Bugs de Modo Efetivo)
Eu recomendo enfaticamente que você leia esta matéria.

4.8. Volume não é precisão

Você deve ser preciso e informativo. Isto não é obtido simplesmente descarregando um enorme volume de código ou dados num pedido de ajuda. Se você tem um grande e complicado caso de teste que está travando o programa, experimente eliminar os excessos e torna-lo menor o máximo que for possível.

Isto é útil por pelo menos três razões. Primeiro: demonstrando que você se esforçou em simplificar a questão você terá mais chances de obter uma resposta. Segundo: simplificando a resposta aumenta a probabilidade de você obter uma resposta útil. Terceiro: no processo de refinar seu relatório de falha, você pode descobrir a solução do problema.

4.9. Não reivindique que você encontrou um bug

Quando você estiver tendo problema com algum software, não afirme que você encontrou um bug 
(NT: o termo bug é utilizado no mundo da TI para designar um defeito num código ou na rotina de um programa), a menos de que você tenha absoluta certeza do que está dizendo. Dica: a menos de que você seja capaz de fornecer o código fonte de um patch que resolva o problema, ou um teste comparativo em relação a uma versão anterior que demonstre o comportamento incorreto, você provavelmente não está suficientemente seguro se efetivamente se trata de um bug ou não.

Lembre-se, existem muitos outros usuários que não estão tendo o seu problema. De outra forma você teria tomado conhecimento dele durante uma leitura da documentação e pesquisando na Web (você fez isto antes de reclamar, não fez?). Isto significa que muito provavelmente é você que está fazendo algo errado, não o software.

As pessoas que desenvolveram o software trabalham duro para que ele funcione da melhor maneira possível. Se você afirma que encontrou um bug, você indiretamente está dizendo que eles fizeram alguma coisa errada, e você quase sempre os ofenderá, mesmo quando você está certo. É muita falta de diplomacia destacar “bug” no campo assunto.

Quando formular sua pergunta, é melhor escrever que você acredita estar fazendo algo errado, mesmo que você esteja convicto de que encontrou um bug de verdade. Se realmente existir um bug, você ficará sabendo pelas respostas. É preferível que os desenvolvedores venham se desculpar com você se o bug realmente existir do que você ter que se desculpar com eles pela confusão que provocou.

4.10. Humildade não garante que os outros façam as suas obrigações

Algumas pessoas que estão conscientes de que não devem se comportar com rudeza ou arrogância, solicitando uma resposta, colocam-se no extremo oposto da humildade e da submissão. “Eu sei, eu sou um iniciante imbecil e mané, mas ...”. Isto é desviar a atenção e totalmente ineficiente. É especialmente desagradável quando acompanhado de falta de objetividade e precisão sobre o verdadeiro problema.

Não perca seu tempo, ou o nosso, com este tipo de atitude. Ao invés disto, apresente todos os fatos que estão por trás do problema e a sua pergunta da maneira mais clara possível. Esta maneira de se posicionar é muito melhor do que bancar o humilde e submisso.

4.11. Descreva os sintomas do problema, não suas suposições.

É inútil dizer para os hackers o que você acha que está causando seu problema. (Se suas teorias sobre a solução do problema fossem boas, por que você estaria consultando outros para ajuda?)

Desta forma, certifique-se de que você está relatando os sintomas do que está acontecendo de errado, ao invés de suas interpretações e teorias. Deixe a interpretação e o diagnóstico para os especialistas.

Burro:

Eu estou obtendo erros SIG11 consecutivos na compilação do kernel, e suspeito que rompeu um dos circuitos da placa mãe. Qual é a melhor maneira de verificar isto?

Inteligente:

Meu K6/233 montado em casa numa placa mãe FIC-PA2007 (chipset VIA Apollo VP2) com 256 MB Corsair PC133 SDRAM começou a apresentar freqüentes erros SIG11 cerca de 20 minutos após ser ligado durante a compilação do kernel, mas nunca antes dos primeiros 20 minutos. Reinicializar não zera o clock, mas mantê-lo desligado durante a noite sim. Trocar toda memória RAM não ajuda. A parte relevante do log de uma típica seção de compilação segue abaixo.

4.12. Descreva os sintomas do problema em ordem cronológica

Freqüentemente as melhores pistas para descobrir alguma coisa que deu errado estão nos eventos imediatamente anteriores. Deste modo, sua mensagem deverá descrever precisamente o que você fez, e como a máquina reagiu, conduzindo para o problema. No caso de processos que utilizam linhas de comando, utilizar o registro da seção (log) e copiar as vinte e poucas linhas relevante é muito útil.

Se o programa que lhe causou problemas tiver opções de diagnóstico (como, por exemplo, -v para verbose), procure pensar com muita atenção sobre selecionar opções que adicionarão informações úteis para solucionar o problema.

Se sua mensagem acabar ficando muito longa (mais do que quatro parágrafos), poderá ser útil relatar sucintamente o problema no início e a seguir apresentar o quadro cronológico. Deste modo, os hackers saberão o que procurar ao ler a sua mensagem.

4.13. Descreva o objetivo, não as etapas

Se você está tentando descobrir como fazer alguma coisa (de maneira oposta em relação a relatar um bug), comece descrevendo o objetivo. Somente depois descreva os passos específicos na direção do que está causando o problema.

Freqüentemente as pessoas que necessitam de ajuda técnica tem um importante objetivo em mente e insistem obstinadamente no que eles julgam ser uma alternativa particular rumo ao objetivo. Eles buscam ajuda com as etapas, sem conseguir imaginar que o caminho está errado. Isto pode consumir muito esforço para ser superado.

Burro:

Como eu faço para que o selecionador de cores do programa FooDraw carregue um valor RGB hexadecimal?

Inteligente:

Eu estou procurando substituir a tabela de cores de uma imagem com valores de minha escolha. No momento a única maneira que eu posso ver para fazer isto é editando cada ponto da tabela, mas eu não sou capaz de fazer com que o selecionador de cores do FooDraw carregue um valor RGB hexadecimal

A segunda versão da questão é inteligente. Ela permite uma resposta que sugere uma ferramenta mais adequada para a tarefa.

4.14. Não peça para as pessoas responderem em privado

Os hackers acreditam que resolver problemas deveria ser um processo transparente e público, durante o qual a primeira tentativa de resposta pode e deve ser corrigida se alguém com mais conhecimento notar que ela estava incompleta ou incorreta. Também, eles obtêm alguma recompensa por responder quando são reconhecidos por seus pares como conhecedores e competentes.

Quando você pede por uma resposta particular, você está impedindo tanto o processo como a recompensa. Não faça isto. É quem responde que escolhe se o fará em particular, e se assim fizer, normalmente é porque ele pensa que a questão e muito mal formulada ou obvia para despertar o interesse dos outros.

Existe uma exceção para esta regra. Se você pensa que a questão poderá gerar muitas respostas similares, então as palavras mágicas são “respondam para mim que eu farei um sumário de todas as respostas para o grupo”. Poupar a lista ou grupo de discussão de uma avalanche de mensagens substancialmente idênticas é um ato de cortesia, mas você deve manter a promessa de preparar e compartilhar o sumário.

4.15. Seja explícito sobre a questão que você tem

Questões vagas e/ou indefinidas tendem a serem encaradas como perda de tempo. As pessoas mais capazes de lhe dar uma resposta útil são também as pessoas mais ocupadas (basicamente porque eles assumem a maioria do trabalho). Pessoas assim são alérgicas com relação a desperdício de tempo e sendo assim elas também são alérgicas com perguntas vagas e/ou indefinidas.

Você terá maiores chances de obter uma resposta útil se você for explicito sobre o que você deseja que o respondente faça (fornecer endereços de memória, análise do seu patch, etc.). Isto direciona o esforço e implicitamente determina um limite de tempo e energia máximo a ser gasto com você por parte de quem lhe responder. Isto é bom.

Para entender o mundo em que os especialistas vivem, pense no conhecimento especializado como um recurso abundante e no tempo para responder como um recurso escasso. Quanto menos comprometimento de tempo você implicitamente demandar, maior será a probabilidade de você obter uma resposta de alguém realmente competente e realmente atarefado.

Sendo assim, vale a pena enquadrar sua questão de modo a minimizar o tempo que o especialista terá de dedicar a ela, mas isto freqüentemente não é a mesma coisa que simplificar a questão. Por exemplo, “Vocês poderiam me dar uma sugestão para uma boa explicação de X?” é uma forma de perguntar mais inteligente do que “Vocês explicariam X?” Se você tem algum programa que não esteja funcionando, é mais inteligente pedir para alguém explicar o que está errado do que pedir para alguém resolver o problema.

4.16. Não queira que os outros resolvam suas tarefas.

Os hackers são muito bons na identificação de perguntas que indiretamente demandam trabalho que deveria ser feito por quem perguntou. Eles pessoalmente já fizeram as tarefas que os preguiçosos estão demandando de terceiros. Colocar a mão na massa é uma boa maneira de você aprender. É aceitável pedir dicas, mas não é aceitável pedir toda a solução.

4.17. Evite perguntas semanticamente nulas.

Resista a tentação de encerrar sua solicitação de ajuda com interrogações semanticamente nulas como, por exemplo, “Alguém pode me ajudar?” ou “Existe alguma resposta?”. Primeiro, se você escreveu a descrição do seu problema com mediana competência, este tipo de colocação é totalmente supérfluo. Segundo, por serem supérfluas, os hackers as consideram irritantes, e são capazes de lhe retornar uma resposta impecavelmente lógica, mas sem nenhuma utilidade, do tipo “Sim, nós podemos lhe ajudar” e “Não, não existe solução para você”.

Em geral, fazer uma pergunta do tipo sim ou não é uma coisa a ser evitada, a menos que você deseje uma resposta do tipo sim ou não.

4.18. Não destaque sua questão como “urgente”, mesmo que para você ela seja.

É você que está com problemas, não nós. Reivindicar urgência pode se mostrar contraproducente. A maioria dos hackers simplesmente apaga este tipo de mensagem por as considerarem rudes e egoístas tentando obter atenção imediata e especial.

Existe somente uma exceção. Pode valer a pena mencionar isto se você estiver trabalhando em algum lugar muito famoso, um lugar que possa despertar o interesse dos hackers. Neste caso, se você estiver premido pelo tempo, e for bastante diplomático na sua colocação, as pessoas poderão se mostrar interessadas o suficiente para responder com rapidez.

Fazer isto é uma coisa que implica muito risco, os parâmetros de um hacker para decidir o que possa ser interessante ou não provavelmente são diferentes dos seus. Enviar uma mensagem da Estação Espacial Internacional pode qualificá-lo para fazer isto, mas enviar uma mensagem em nome dos caridosos do bem‑estar ou de uma causa política quase certamente não. Na verdade, escrevendo “Urgente: Ajudem-me a salvar as focas-bebê!” lhe renderá críticas ou desprezo, mesmo por hackers que pensam que focas-bebê são importantes.

Se você acha que isto é misterioso, releia este guia tantas vezes quanto for necessário para você entender, antes de sair enviando mensagens para meio mundo.

4.19. Cortesia numa é demais, e algumas vezes ajuda

Seja gentil. Use “Por favor” e “Obrigado por sua atenção” ou “Obrigado pela sua consideração”. Deixe claro que você agradece o tempo que as pessoas gastam para lhe ajudar gratuitamente.

Para ser honesto, isto não é tão importante quanto (e não substitui) escrever corretamente, de modo claro, descritivo e objetivo, não fazer uso de formatos proprietários, etc. Os hackers em geral preferem um relato de bug tosco, mas tecnicamente exato do que um polido porem vago (se isto lhe deixa confuso lembre que nos valoramos uma pergunta pelo que ela pode nos ensinar).

De qualquer modo, se você obedecer as recomendações acima, mostrar educação aumenta suas chances de obter uma resposta útil.

(Nós devemos registrar que a única objeção séria que nós recebemos de hackers veteranos para este guia diz respeito a nossa recomendação previa para usar “Obrigado antecipadamente”. Alguns hackers acham que isto não expressa uma vontade verdadeira de agradecer posteriormente. Nossa recomendação é dizer “Obrigado antecipadamente” primeiro e obrigado aos que responderam depois, ou expressar cortesia de outra maneira , como, por exemplo, dizendo “Obrigado pela atenção de vocês” ou “Obrigado pela consideração de vocês”).

4.20. Feche o tópico com uma breve nota sobre a solução

Envie uma mensagem após o problema ter sido resolvido para todos que lhe ajudaram, deixe os conhecer como a solução foi encontrada e agradeça-lhe novamente pela ajuda. Se o problema atrair o interesse geral da lista, é apropriado enviar uma mensagem dando mais informações sobre a questão previamente tratada lá.

A maneira ideal para fazer isto seria começar a mensagem com a questão originalmente colocada, e deveria ter na linha de assunto “CONSERTADO” “RESOLVIDO” ou outra palavra de mesmo significado. Em listas onde as coisas são resolvidas de forma muito rápida, um respondente potencial que vê uma mensagem sobre “Problema X” terminando com “Problema X – RESOLVIDO” sabe que não deve desperdiçar seu tempo mesmo para ler (a menos que o problema X seja de seu interesse) e pode despender seu tempo resolvendo um problema diferente.

Esta mensagem não tem que ser longa nem complicada, um simples “Salve, foi um cabo da rede que falhou. Obrigado a todos, Bill” seria melhor do que nada. Na verdade, um pequeno e gentil sumário é melhor do que uma longa dissertação, a menos que a solução tenha profundidade técnica de verdade. Diga qual ação resolveu o problema, sem precisar detalhar toda a seqüência para chegar lá.

Para problemas mais complexos, é apropriado fazer um sumário do histórico para solucionar a não conformidade. Descreva qual era o seu problema. Descreva o que funcionou como solução, e indique erros que podem ser evitados. Diga o nome das pessoas que lhe ajudaram, você estará fazendo amigos desta maneira.

Além de ser gentil e informativo, este tipo de relato ajudará outros pesquisando mensagens na lista/grupo de discussão/fóruns para saber exatamente qual solução lhe ajudou e assim pode também ajuda-los.

Por ultimo, mas nem por isto menos importante, este tipo de mensagem contribui para que todos que lhe ajudaram sintam-se satisfeitos com o desfecho do problema.

Se você não é especialista ou hacker, confie em nós que este sentimento é muito importante para os gurus ou expertos que estiveram lhe ajudando. Narrativas de problemas nos quais os hackers se empenharam para resolver e que gradualmente foram esfriando até acabar sem uma solução são coisas frustrantes. Agir corretamente lhe renderá bons frutos na próxima vez que você necessitar de uma nova ajuda.

Considere como você pode ser capaz de prevenir os outros de terem o mesmo problema no futuro. Pergunte a si mesmo se algum patch poderia ajudar, e se a resposta for sim envie o patch para o mantenedor.

Entre os hackers, este tipo de comportamento é na verdade mais importante que cortesia convencional. É como você consegue uma reputação por se comportar corretamente com os outros, o que pode ser um ativo de muito valor.

5. Como interpretar respostas

5.1. RTFM e STFW: Como lhe dizer que você passou da conta

Existe uma antiga e sagrada tradição: se você receber uma resposta com “LAPDM”, a pessoa que lhe enviou pensa que você deveria Ler A Porra Do Manual. Provavelmente ele estará certo. Vá em frente, leia o manual.

LAPDM tem um parente mais jovem. Se você receber uma resposta com “PNPDI”, a pessoa que lhe enviou pensa que você deveria Procurar Na Porra Da Internet. Provavelmente ele está certo. Vá em frente, procure na Internet 
(NT: as siglas LAPDM e PNPDI são as traduções de RTFM = Read The Fucking Manual e STFW = Searched The Fucking Web).

Freqüentemente a pessoa que escreve isto tem o manual ou a página da web com a informação que você necessita na frente dele, e está olhando para ele enquanto escreve. Estas respostas significam que ele pensa :
(a) que a informação que você necessita é fácil de ser encontrada e 
(b) você aprenderá mais se você procurar a informação do que se alguém lhe der de mão beijada.

Você não deve se ofender com isto, pelos padrões dos hackers, ele está demonstrando respeito por você, mesmo que de uma forma bruta, simplesmente não lhe ignorando. Você deveria lhe agradecer por esta forma de gentileza típica das avós.

5.2. Se você não entende…

Se você não entender a resposta, não demande esclarecimento imediatamente. Use as mesmas ferramentas que você utilizou para tentar encontrar um resposta da sua pergunta original (manuais, FAQs, Web, amigos mais experientes) para entender a resposta. Então, se você ainda necessitar pedir esclarecimento, acrescente o que você aprendeu.

Por exemplo, suponha que eu lhe diga: “Parece como se você tivesse um stuck zentry, você precisa removê-lo”. Então:

Aqui está um mau pedido de esclarecimento: “O que é um zentry”?

Aqui esta um bom pedido de esclarecimento: “OK, eu li o manual e os zentries somente são mencionados com os parâmetros –z e –p. Nenhum deles diz nada sobre remover zentries. É um desses ou eu deixei de observar alguma coisa”?

5.3. Lidando com grosseiras

Muito do que parece grosseria no ambiente hacker não visa ofender. Ao invés disto, é o produto direto do estilo de comunicação “podar as abobrinhas”, que é muito natural para pessoas que estão mais preocupadas em resolver problemas do que fazer os outros se sentirem desconfortáveis e confusos.

Quando você notar aspereza, procure reagir com calma. Se alguém realmente estiver sendo áspero, é muito provável que uma pessoa mais experiente da lista ou fórum irá chamar-lhe a atenção. Se isto não acontecer e você perder sua calma, é provável que a pessoa que lhe levou a perder a calma esteja se comportando dentro das normas da comunidade hacker e você provavelmente será considerado como faltoso. Isto prejudicará suas chances de receber a informação ou ajuda que você deseja.

Por outro lado, você poderá ocasionalmente se defrontar de maneira inesperada com aspereza e postura completamente gratuita. Quando isto ocorre, é aceitável criticar duramente o ofensor de fato, dissecando seu mau comportamento com um bisturi verbal bem afiado. Esteja muito certo do chão que você estiver pisando se você enveredar por este caminho. A divisória que separa a intenção de corrigir uma descortesia e começar uma guerra de flames 
(NT: um flame é uma mensagem enviada por um membro de uma lista atacando, de modo excessivamente descortês, outro membro, algumas vezes em termos pessoais) sem sentido é tão tênue que mesmo os hackers não raramente passam de um lado para outro; se você é um calouro ou um observador externo, suas chances de confundir as coisas são altas. Se você está buscando informação em lugar de diversão, é melhor manter seus dedos longe do teclado para evitar este tipo de risco.

(Algumas pessoas afirmam que muitos hackers sofrem de um tipo moderado de autismo ou síndrome de Asperger, que na verdade não possuem alguns circuitos cerebrais que lubrificam as interações dos seres humanos normais. Isto pode ou não ser verdade. Se você não é um hacker, pode ser útil para você procurar contornar nossas excentricidades caso você pense que nós sofremos de alguns desajustes mentais. Siga em frente. Nós não nos importamos, nós gostamos de ser o que somos, e geralmente temos um ceticismo saudável sobre rótulos clínicos).

Na próxima seção, nós trataremos sobre uma questão diferente, o tipo de “grosseria” que você verá quando você se comporta mal.

6. Não reaja como um mané.

Existem boas chances de que você cometa equívocos algumas vezes nos fóruns da comunidade hacker, de acordo com alguma maneira descrita neste guia ou similar. E lhe dirão no que você se equivocou com uma profusão de detalhes. Em público.

Quando isto acontece, a pior coisa que você pode fazer é reclamar sobre a experiência, dizendo ter sido atacado verbalmente com violência, solicitar pedidos de desculpas, chorar, segurar sua respiração, intimidar com ações judiciais, reclamar para os chefes deles, deixar o assento do vaso sanitário em pé, etc. Ao invés disto, aqui está o que você deve fazer:

Releve. É normal. Na verdade é saudável e apropriado.

Os padrões da comunidade não se mantêm por si mesmo. Eles são mantidos por pessoas que participam ativamente, de modo visível, em público. Não reclame que toda critica deveria ser feita de modo privado. Não é deste modo que as coisas funcionam. Nem é útil insistir que você foi pessoalmente insultado quando alguém comentou que uma de suas demandas não tinha procedência, ou que tem um ponto de vista diferente do seu. Estas atitudes são típicas dos manés.

Já existiram fóruns hackers com um senso de hiper-cortesia tão exagerado, onde os participantes são proibidos de apontarem faltas nas mensagens dos outros.

A orientação destes fóruns é “não diga nada se você não for capaz de ajudar o usuário”. A conseqüente saída de participantes chaves acaba por esvaziar o fórum e com o tempo ele se torna sem utilidade como local de discussão técnica.

Exageradamente “amigável” ou útil: escolha um.

Lembre-se, quando algum hacker lhe diz que você foi inconveniente, e (não importa quão ríspido) dizer lhe para não repetir isto novamente, sua atuação mostra consideração (1) para com você e (2) e para com a comunidade a qual ele pertence. Seria muito mais simples para ele lhe ignorar colocando um filtro. Se você não for capaz de ser grato, tenha ao menos um pouco de dignidade, não se queixe e não espere que lhe tratem como uma boneca frágil somente porque é um recém chegado de alma teatralmente hipersensível e com a ilusão de estar autorizado a tudo.

7. Perguntas que não devem ser formuladas

Aqui estão alguns perguntas imbecis clássicas, e o que os hackers pensam quando eles não as respondem.

Pergunta: Onde eu posso encontrar o programa ou o recurso X?

Resposta: No mesmo lugar onde eu encontrei, idiota – como o resultado de uma procura na Web. Pelo amor de Deus, será que as pessoas ainda não sabem como usar o Google.

Pergunta: Como eu posso usar X para fazer Y?

Resposta: Se o que você quer é fazer Y, você deveria formular a pergunta sem presumir o uso de um método que pode não ser apropriado. Perguntas deste tipo freqüentemente indicam uma pessoa que não é meramente ignorante sobre X, mas confusa sobre qual problema Y eles estão resolvendo e também muito absorto em detalhes particulares do problema deles. Em geral é melhor ignorar este tipo de pessoas até que elas definam melhor o problema.

Pergunta: Como eu posso configurar a indicação de “pronto” do meu shell?

Resposta: Se você é suficientemente inteligente para fazer esta pergunta, você tem suficiente inteligência para LAPDM e encontrar você mesmo a resposta.

Pergunta: Eu posso converter um documento X em um arquivo Y usando o conversor de arquivo Z?

Resposta: Experimente e veja. Se você fizer isto, você (a) aprenderá a resposta e (b) deixará de ocupar o meu tempo.

Pergunta: Meu {programa, configuração, declaração SQL} não funciona.

Resposta: Isto não é uma pergunta, e eu não estou interessado em brincar de Twenty Questions 
(NT: clássico jogo americano onde um jogador pensa em um animal, mineral ou vegetal enquanto que o outro jogador deve procurar descobrir do que se trata formulando perguntas até um máximo de vinte perguntas) para lhe extrair o que você realmente quer saber. Eu tenho coisa melhor para fazer. Quando eu vejo coisas como esta, minha reação normalmente é uma das seguintes:

Você tem mais alguma coisa para acrescentar?

Oh, isto é mau, eu espero que você consiga resolver.

E o que isto tem a ver comigo?

Pergunta: Eu estou enfrentando problemas com o Windows. Alguém pode me ajudar?

Resposta: Sim. Jogue fora o lixo da Microsoft e instale um sistema operacional de código aberto como o Linux ou o BSD.

Pergunta: Meu programa não funciona. Eu acho que o recurso X do sistema está com algum problema.

Resposta: Embora seja possível que você seja a primeira pessoa a observar uma deficiência obvia em chamadas do sistema e bibliotecas amplamente utilizadas por centenas ou milhares de pessoas, é mais provável que você esteja completamente perdido. Demandas extraordinárias necessitam evidencias extraordinárias, quando você demanda algo deste tipo, você deve suportá-la com uma documentação clara e exaustiva do caso de falha.

Pergunta: Eu estou tendo problemas instalando Linux ou X. Alguém pode me ajudar?

Resposta: Não. Eu necessitaria acessar fisicamente o seu computador para resolver isto. Pergunte ao seu grupo local de Linux ou X para ajuda desta natureza.

Pergunta: Como eu posso craquear root / roubar privilégios de administradores / ler o correio eletrônico de alguém?

Resposta:Você é um mau caráter por querer fazer este tipo de coisa e um retardado para solicitar que um hacker lhe ajude.

8. Perguntas boas e más

Finalmente, eu vou ilustrar com exemplos como fazer perguntas de um modo inteligente, usando duas perguntas sobre um mesmo problema, uma formulada de maneira burra e a outra de maneira inteligente.

Burra: Onde eu posso encontrar alguma coisa sobre o Foonly Flurbamatic?

              Esta pergunta pede pela clássica resposta PNPDI

Inteligente: Utilizei o Google para tentar encontrar “Foonly Flurbamatic 2600” na Internet, mas eu não consegui nenhuma dica útil. Alguém sabe onde eu possa encontrar informações sobre programação deste aparelho?

              Este já PNPDI, e aparentemente parece ter um problema de verdade.

Burra: Não consigo compilar o código do projeto X. Por que ele não está compilando?

              Ele assume que cometeu algum cometeu um erro codificando o projeto X. Arrogância da parte dele.

Inteligente: O código do projeto X não compila com o Nulix versão 6.2. Eu já li o FAQ, mas ele não tem nada sobre problemas do Nulix. Segue abaixo a transcrição da minha tentativa de compilação, é alguma coisa que eu fiz?

              Ele especificou o ambiente, ele leu o FAQ, ele está mostrando o erro e ele não está assumindo que o problema dele está sendo causado pela falha de alguém. Este cara pode merecer alguma atenção.

Burra: Eu estou tendo problemas com minha placa-mãe. Alguém pode me ajudar?

A resposta de um hacker para isto provavelmente será “Certo. Você também precisa de fraldas?” seguido de uma pressão sobre a tecla Del.

Inteligente: Eu tentei X, Y e Z com a placa-mãe S2464. Quando isto não resolveu, eu tente