Como fazer perguntas de maneira inteligente

Tradução para o português do documento de Eric S. Raymond, por CJr. O original (em inglês) pode ser encontrado aqui.
Traduzido da Revisão 3.4, de 24 de março de 2007.
Última alteração em 05 de março de 2011.
Copyright © 2001, 2009 Eric S. Raymond

Introdução

No mundo dos hackers, o tipo de respostas que você obtém para as suas questões técnicas depende tanto da maneira com que você pergunta quanto da dificuldade para criar e organizar a resposta. Este guia vai ensinar-lhe como fazer perguntas de um modo que torne mais provável o recebimento de uma resposta satisfatória.

Agora que o uso de software livre (open source) se tornou difundido, você pode obter respostas de outros usuários, mais experientes, ao invés de obtê-las de hackers. Isto é uma Boa Coisa; usuários tendem a ser um pouquinho mais tolerantes com o tipo de erros que os iniciantes costumam cometer. Mesmo assim, tratar usuários experientes como hackers, da maneira que recomendamos aqui, é em geral a maneira mais efetiva de obter deles respostas úteis.

A primeira coisa a compreender é que hackers realmente gostam de problemas difíceis e perguntas sobre eles que provoquem a reflexão. Se não gostássemos, não estaríamos aqui. Se você nos der uma pergunta difícil para mastigar, seremos gratos a você; boas questões são um estímulo e um presente. Boas questões nos ajudam a desenvolver nossa compreensão e várias vezes revelam problemas que ainda não tínhamos notado ou lhes dado maior atenção. Entre hackers, "Boa pergunta!" é um caloroso e sincero cumprimento.

Apesar disso, os hackers têm uma reputação de responder a questões simples com uma atitude que parece hostilidade ou arrogância . Às vezes parece que somos sempre rudes com iniciantes ou ignorantes. Mas isso não é verdade.

Somos (na verdade e sem desculpas) hostis à pessoas que parecem não ter vontade de pensar ou de fazer seu próprio dever de casa antes de fazer perguntas. Pessoas que são sorvedouros de tempo - que tomam sem retribuir - gastam o tempo que poderíamos ter usado respondendo a outra pergunta mais interessante ou a outra pessoa que merecesse mais uma resposta. Chamamos pessoas assim de "losers" (perdedores, derrotados) e, por razões histórias, às vezes soletramos "lusers".

Sabemos que há muitas pessoas que querem usar o software que escrevemos e não têm interesse em aprender os detalhes técnicos. Para a maioria, o computador é meramente uma ferramenta, um meio para atingir um fim; eles têm coisas mais importantes para fazer; têm suas vidas para serem vividas. Nós aceitamos este fato e não esperamos que ninguém tenha interesse nas questões técnicas que nos fascinam. Mas nosso estilo de resposta é voltado para as pessoas que têm este interesse e que querem ser participar ativamente da solução dos problemas que aparecem. Isso não vai mudar. Nem deveria; se mudássemos, seríamos menos eficazes no que fazemos melhor.

Somos, na maior parte, voluntários. Tiramos tempo de nossas vidas cheias para responder a perguntas e às vezes somos soterrados por elas. Então filtramos sem compaixão. Em particular, jogamos fora perguntas de pessoas que parecem ser losers para gastar nosso tempo mais eficientemente, com os winners (vencedores).

Se você acha essa atitude vergonhosa, condescendente ou arrogante, reveja seus conceitos. Não estamos pedindo que você se ajoelhe e nos adore - de fato, quase todos nós gostamos mesmo é de tratá-lo como igual e dar as boas vindas ao nosso meio e à nossa cultura, caso você se esforce para tornar isso possível. O caso é que, para nós, simplesmente não é eficaz ajudar pessoas que não querem se ajudar. É OK ser ignorante; bancar o ignorante não é.

Portanto, não é preciso ser tecnicamente competente para receber nossa atenção, mas é necessário demonstrar o tipo de atitude que leva à competência - ser alerta, cheio de ideias, observador, desejoso de ser uma parte colaboradora e ativa na procura de uma solução. Se você não consegue suportar este tipo de discriminação, sugerimos que pague um contrato de suporte comercial ao invés de pedir a hackers para doar-lhe a ajuda necessária.

Se você está decidido a nos pedir ajuda, você não quer ser um perdedor. Também não quer parecer um. A melhor maneira de obter uma resposta útil e rápida é fazer perguntas como uma pessoa inteligente, confiante e situada que apenas precisa de ajuda em um problema específico.

(Melhorias para este guia são bem-vindas. Você pode enviar sugestões para o email esr@thyrsus.com.Note que este documento não é um guia de netiquette e costumamos rejeitar sugestões que não sejam diretamente relacionadas ao assunto, ou seja, como obter respostas elucidativas em um fórum técnico.)

(N.T.: Erros neste documento são geralmente do tradutor e não do autor)

Antes de perguntar

Antes de perguntar via email, em um newsgroup ou via chat, faça o seguinte:

  1. Tente encontrar uma resposta fazendo uma procura nas mensagens já enviadas do fórum para o qual você pretende enviar a sua dúvida.
  2. Tente encontrar uma resposta procurando na web.
  3. Tente encontrar uma resposta lendo o manual.
  4. Tente encontrar uma resposta lendo um FAQ.
  5. Tente encontrar uma resposta por inspeção ou experimentando.
  6. Tente encontrar uma resposta perguntando a um amigo mais capacitado.
  7. Se você é um programador, tente encontrar uma resposta lendo o código-fonte.

Quando perguntar, lembre-se mostrar que, primeiro, você fez tudo isso; isto ajudará a estabelecer que você não está sendo uma ameba preguiçosa e assim gastando o tempo dos outros. Melhor ainda, mostre o que você aprendeu ao seguir os passos acima.Gostamos de responder perguntas para quem demonstra que pode aprender com as respostas.

Use táticas como fazer uma busca Google pelo texto de qualquer mensagem de erro que você tenha (e procure nos Grupos Google também). Isso pode levar você direto à documentação da solução ou a uma sequencia de mensagens que respondem à sua pergunta. Mesmo que isso não resolva, dizer "Procurei no Google esta frase mas não consegui nada promissor " é uma boa coisa a se colocar em emails ou mensagens para newsgroups solicitando ajuda, porque no mínimo indica que estas buscas não vão trazer resultados significativos.

Não se apresse. Não espere ser capaz de resolver um problema complicado com apenas alguns segundos de busca no Google. Leia e entenda os FAQs, respire fundo, relaxe e pense no problema antes de recorrer aos especialistas. Confie no que dizemos: eles serão capazes de dizer, apenas lendo suas perguntas, quanto você gastou lendo e pensando e serão muito mais receptivos se você tiver se preparado. Não dispare todo o seu arsenal de perguntas imediatamente só porque a sua primeira busca não trouxe nenhuma resposta (ou respostas demais).

Prepare a sua pergunta. Pense bem nela. Questões mal elaboradas obtém respostas apressadas, ou nenhuma resposta. Quanto mais você demonstra que colocou empenho e esforço em resolver seu problema antes de pedir ajuda, mais possibilidade de realmente conseguir ajuda você tem.

Cuidado para não fazer a pergunta errada. Se a sua pergunta for baseada em premissas erradas, o mais certo é Um Hacker Qualquer enviar uma resposta inútil e literal, enquanto pensa "Pergunta idiota...", esperando que a experiência de receber o que você pediu ao invés do que realmente precisa vai lhe ensinar uma lição.

Nunca assuma ser merecedor de uma resposta. Afinal de contas, você não está pagando pelo serviço. Você pode receber uma resposta, se chegar a receber, por fazer uma pergunta substancial, interessante, que provoca a reflexão - uma pergunta que implicitamente contribui para a experiência da comunidade ao invés de passivamente demandar conhecimento dela.

Por outro lado, deixar claro que você está apto e quer participar do processo de solução é um bom começo. "Alguém poderia me dar um direcionamento?", "O que falta no meu exemplo?" e "Em que site devo procurar?" têm mais possibilidade de ser respondidos do que "Por favor forneça o procedimento que eu deveria seguir.", porque você está deixando claro que realmente quer completar o processo se alguém puder simplesmente colocar você na direção certa.

Quando for a hora de perguntar

Escolha os fóruns cuidadosamente

Seja cuidadoso quando escolher onde incluir sua pergunta. Você vai ser ignorado, ou descrito como um loser, se:

Hackers "detonam" perguntas inapropriadas para proteger seu canal de comunicações de ser "afogado" pela irrelevância. Você não quer que isto aconteça no seu caso.

O primeiro passo, portanto, é encontrar o fórum certo. Novamente, o Google e outros mecanismos de busca são seus aliados. Use-os para encontrar a página mais associada ao hardware ou software que está lhe trazendo problemas. Usualmente há links para listas de FAQs (Frequently Asked Questions) e também para listas de discussão e seus arquivos de perguntas já enviadas. Essas listas de discussão são o último recurso para obter ajuda, se seus próprios esforços (incluindo ler os FAQs encontrados) não levarem a uma solução. A página encontrada pode também conter links detalhando como se deve informar os bugs encontrados. Caso existam, use-os.

Enviar mensagens a uma pessoa ou fórum com o qual você não é familiarizado é, no mínimo, arriscado. Por exemplo, não assuma que o autor de uma página web informativa quer ser seu consultor grátis. Não seja otimista a ponto de acreditar que sua pergunta será automaticamente bem-vinda - se você não tem certeza, envie-a para outro lugar, ou não envie.

Quando selecionar um fórum web, um newsgroup ou lista de discussão, não confie somente no nome dos tópicos; procure um FAQ ou descrição para verificar se o tópico realmente cobre o assunto da sua pergunta. Leia algumas das mensagens antes de enviar a sua; assim, você tem uma ideia de como as coisas são feitas por ali. É uma ótima ideia fazer uma busca no newsgroup ou lista de discussão pelas palavras-chave relativas ao seu problema antes de enviar mensagens. Se este procedimento não encontrar uma solução, vai ajudar você a formular melhor a pergunta.

Não envie mensagens para todos os canais de ajuda simultaneamente. Isto equivale a gritar; irrita as pessoas. Tente todos os que escolheu, mas um de cada vez.

Conheça o assunto de sua pergunta! Um erro clássico é perguntar sobre detalhes de programação Unix ou Windows em um fórum de uma linguagem, biblioteca ou ferramenta que atende às duas plataformas. Se você não sabe por que isto é um erro, faria melhor em não perguntar até descobrir.

Em geral, é mais provável encontrar respostas úteis recorrendo a um fórum público bem selecionado do que a um privado. Há muitas razões para isso. Uma delas é simplesmente a quantidade de potenciais respondentes. A outra é a quantidade de pessoas que acessam o fórum, a audiência; hackers preferem responder a questões que esclarecem muitas pessoas simultaneamente do que as que servirão apenas a um público pequeno.

Compreensivelmente, hackers habilidosos e autores de softwares populares já estão recebendo mais do que a cota necessária de mensagens equivocadas. Se você se juntar aos que as enviam, você pode se tornar a gota d'água - várias vezes acontece de contribuidores de projetos de grande aceitação terem retirado sua participação por sofrerem o efeito colateral de ter suas caixas postais entupidas de emails equivocados e inúteis.

Lembre-se: Fóruns web e IRC direcionados a iniciantes geralmente respondem mais rapidamente

Seu grupo de usuários local ou os autores de sua distribuição Linux geralmente patrocinam um fórum web ou canal IRC onde iniciantes podem conseguir suporte. (Em países de língua não-inglesa, fóruns para iniciantes tendem a ser listas de discussão via email). Estes são bons lugares para começar a perguntar, especialmente se você acha que está lidando com um problema relativamente simples ou comum a muitos usuários. Um canal IRC patrocinado é um convite para que todos perguntem e geralmente sejam respondidos em tempo real.

Na verdade, se você obteve o software que está lhe dando problemas de uma distribuição (o que é comum hoje em dia), é melhor perguntar no fórum/lista da distribuição antes de tentar o fórum do próprio software. Os hackers do fórum do software poderiam simplesmente dizer "use nossa versão".

Antes de enviar mensagens a qualquer fórum web, verifique se ele tem uma ferramenta de busca. Se tiver, tente uma busca pelas palavras-chave que definem o seu problema; isto com certeza ajudará. Se você fez uma busca web genérica antes (como deveria), procure no fórum assim mesmo; sua ferramenta de busca web pode não ter re-indexado o fórum recentemente.

Existe uma tendência crescente de projetos fornecerem suporte via um fórum web ou canal IRC, deixando o email mais reservado para o tráfego das mensagens de desenvolvedores. Procure por estes canais em primeiro lugar quando precisar de ajuda específica para o projeto.

Segundo passo: listas de discussão via email do projeto

Quando um projeto possui uma lista de discussão via email, escreva para esta lista, não para os desenvolvedores, mesmo que você acredite que saiba quem pode responder melhor à sua questão. Procure pelo endereço da lista na documentação do projeto e em sua página web e use-o. Existem várias boas razões para fazer isto:

Se o projeto tem listas ou fóruns web separados para "usuários" e "desenvolvedores" (ou "hackers") e você não está investigando ou ajudando a desenvolver o código, use lista/fórum "usuários". Não presuma ser bem-findo à lista de desenvolvedores, onde é mais certo que tratem a sua pergunta como ruído perturbando o fluxo de contato dos desenvolvedores.

No entanto, se você está certo de que a sua pergunta não é trivial e não obteve uma resposta na lista/fórum "usuários" depois de muitos dias de espera, tente a de "desenvolvedores". Esteja avisado: frequente esta lista por vários dias para aprender o "dialeto do local" antes de perguntar (isto é um bom conselho tanto em listas privadas como semi-privadas).

Se você não conseguiu o endereço da lista de discussão por email e só consegue ver o endereço do mantenedor do projeto, vá em frente e escreva para ele. Mas mesmo neste caso, não presuma que a lista não existe. Diga em seu email que você tentou, mas não conseguiu encontrar a lista apropriada. Mencione também que os emails trocados entre vocês permanecerão privados, mesmo que não haja nada de secreto neles. Diga também que não se importa se a mensagem que você está enviando for repassada para outras pessoas. (Muita gente acredita que emails privados devem permanecer privados, mesmo que não haja nada secreto neles. Mas permitir que sua mensagem seja repassada dá ao destinatário mais uma alternativa para tratar seu email).

Use o campo "assunto" de maneira significativa e detalhada

Em listas de discussão via email, newsgroups ou fóruns web, o campo "assunto" das mensagens que você envia representa a sua oportunidade de ouro para, em menos de 50 caracteres, atrair a atenção de especialistas qualificados. Não a desperdice com bobagens como "Por favor me ajude" ("POR FAVOR ME AJUDE!!!" é impensável: mensagens com esse assunto são descartadas por simples reflexo). Não tente nos impressionar com a profundidade do seu desespero; ao invés disso, use o espaço para uma descrição super concisa da descrição do seu problema.

Uma boa convenção para o campo assunto, usada por muitas empresas de suporte técnico, é a "objeto-desvio". A parte "objeto" especifica a coisa ou grupo de coisas que apresenta problemas e a parte "desvio" descreve qual o comportamento que difere (desvia) do esperado.

Estúpido:

     AJUDEM! O vídeo do meu laptop não funciona!

Inteligente:

     Xfree86 4.1 cursor não aparece, placa de vídeo Fooware MV 1005

Ainda mais inteligente:

     Xfree86 4.1 cursor usando placa de vídeo Fooware MV1005 - não é mostrado

O processo de escrever uma descrição "objeto-desvio" vai ajudá-lo a organizar mais detalhadamente suas ideias sobre o problema. O que é afetado pelo problema? Somente o cursor (do mouse) ou também outros elementos gráficos (como janelas)? Este comportamento é específico do XFree86? Somente acontece na versão 4.1? É específico das placas de vídeo Fooware? Do modelo MV1005? Um hacker que veja o resultado de um bom assunto "objeto-desvio" entende imediatamente o que apresenta problemas e o problema em si, na primeira leitura.

Imagine que você está olhando para o índice de um arquivo de perguntas, que mostra apenas as linhas de assunto. Captou a ideia? Faça, portanto, com que sua linha de assunto reflita sua pergunta tão bem que o próximo usuário que procurar no arquivo por uma dúvida similar à sua esteja apto a seguir o fluxo até a resposta correta, ao invés de enviar novamente a pergunta para a lista.

Se você fizer uma pergunta respondendo a um email já enviado (reply), esteja certo de mudar a linha de assunto para indicar que você está fazendo uma pergunta. Uma linha de assunto "Re: teste" ou "Re: novo bug" é muito menos propensa a atrair a atenção. Use também partes das mensagens anteriores (chamadas de "quotes") com parcimônia, apenas para instruir e direcionar os leitores que tem acesso somente à última mensagem.

Não escolha simplesmente "Responder" a uma mensagem para iniciar um novo fluxo (thread). Isto limitará a sua audiência. Alguns softwares de email, como o Mutt, permitem ao usuário fazer o agrupamento das mensagens por fluxo em visões de árvore (treeviews) e então esconder todas as mensagens, deixando visível somente a principal. Quem fizer isso nunca verá a sua mensagem.

Mudar o campo assunto não é o suficiente. O Mutt (e provavelmente outros softwares de email) procura não pela linha de assunto, mas por outras informações do cabeçalho do email para descobrir a que fluxo ele pertence. Faça um novo email ao invés disso.

Em fóruns web as boas práticas são ligeiramente diferentes, porque geralmente as mensagens são muito mais restritas a fluxos de discussão específicos, chegando a ser às vezes invisíveis fora destes fluxos. Então, mudar o assunto quando se faz uma pergunta respondendo a um email não é essencial - nem todos os fóruns permitem modificar o campo assunto na resposta - e quase ninguém lê mesmo quando isso é permitido. Mas a própria prática do reply é dúbia em si, porque a resposta será vista somente por aqueles que estão acompanhando este fluxo (thread) específico. Então, inicie um novo fluxo, a menos que você perguntar somente às pessoas que acompanham o fluxo original.

Facilite a resposta

Terminar sua pergunta com "Por favor envie sua resposta para..." faz com que dificilmente você obtenha uma resposta. Se você não pode perder nem mesmo os poucos segundos necessários para configurar o seu programa de email com um endereço de resposta correto, também não vamos gastar nem alguns segundos pensando no seu problema. Se seu software de email não permite essa configuração, consiga um software melhor. Se seu sistema operacional não suporta nenhum software de email que permita isso, consiga um sistema operacional melhor.

Em fóruns web, pedir para responder em outro email é extremamente rude, a menos que você acredite que a informação possa ser restrita (e que alguém irá permitir, por alguma razão desconhecida, que somente você fique sabendo da resposta, em detrimento dos demais participantes do fórum). Se você quer ser avisado por email quando alguém enviar uma mensagem para umaa lista/fluxo específico, configure o fórum para lhe enviar um email quando isso acontecer; a maioria dos fóruns suporta essa configuração (opções "monitorar este fluxo", "enviar email quando houver nova mensagem no fluxo", etc.).

Escreva em linguagem clara, gramaticalmente correta

Sabemos por experiência que pessoas descuidadas e bagunçadas ao escrever são usualmente descuidadas e bagunçadas ao pensar e programar (essa correlação acontece o suficiente para apostarmos nisso).

Portanto, expressar sua pergunta claramente e bem é importante. Se você não se importa em fazer isso, também não nos importaremos em prestar atenção a ela. Faça um esforço extra para polir sua linguagem. Ela não precisa ser sofisticada ou formal - de fato, a cultura hacker valoriza a linguagem informal, com gírias e humor, quando usada com propriedade e precisão. Mas ela deve ser precisa; tem de haver alguma indicação de que você está pensando e prestando atenção.

Digite, pontue e use maiúsculas corretamente. Não confunda "its" com "it's", "loose" com "lose" ou "discrete" com "discreet". Não DIGITE EM MAIÚSCULAS, isso significa que você está gritando e é considerado rude (escrever tudo em minusculas é só um pouco menos irritante, porque é difícil de ler. O Alan Cox pode fazer isso, mas você não pode.

Em geral, se você escreve como um idiota semi-letrado, certamente será ignorado. Escrever como um sup3r garoto hack3r é o fim: isso garante que você não receberá nada além de um silêncio pétreo (ou, no melhor dos casos, uma grande quantidade de desprezo e sarcasmo em forma de ajuda).

Se você for enviar perguntas a um fórum que não usa sua língua nativa, terá um pequeno crédito para erros de gramática e digitação - mas definitivamente nenhum crédito para preguiça (sim, nós usualmente sabemos a diferença). Se você não sabe qual a língua nativa de seus destinatários, escreva em inglês. Hackers ocupados tendem a simplesmente apagar mensagens em línguas que eles não entendem - e o inglês é a língua oficial da Internet. Escrevendo em inglês você minimiza as chances que sua mensagem seja descartada sem ao menos ser lida.

Envie mensagens em formatos que sejam fáceis de entender

Se você faz com que sua pergunta fique difícil de ler, certamente ela será preterida por uma que seja mais fácil. Então:

Se você usa um software de email com interface gráfica (como o Netscape Messenger, Microsoft Outlook e seus similares) cuidado: eles podem quebrar estas regras se estiverem usando as configurações padrão. Muitos softwares como estes possuem uma opção de menu chamada "Ver código-fonte". Use esta opção nas mensagens da sua caixa de saída para garantir que você está enviando somente texto em suas mensagens, sem nenhuma "nata" anexa.

Seja preciso e informe corretamente seu problema

Faça o melhor possível para antecipar as perguntas que um hacker faria e respondê-las já em seu pedido de ajuda.

Simon Tatham escreveu um excelente ensaio, intitulado Como relatar bugs de maneira eficaz. Recomendo fortemente que você o leia.

Quantidade não é precisão

Você deve ser preciso e informativo. Não é possível alcançar este fim simplesmente enviando grandes volumes de dados em um pedido de ajuda. Se seu caso de teste que apresenta o problema é grande e complicado, tente resumi-lo o mais possível.

Fazer isso é útil por pelo menos três razões. Uma: se ficar claro que você investiu esforço em simplificar a pergunta antes de enviá-la, suas chances de receber uma resposta aumentam. Duas: simplificar a pergunta torna mais provável que você receba uma resposta útil. Três: durante o processo de refinamento de seu relatório de erro, talvez você mesmo desenvolva uma solução ou paliativo para o problema.

Não fique dizendo que achou um bug

Quando você está tendo problemas com um software, não diga que achou um bug a menos que você esteja muito, muito certo disso. Uma dica: a menos que possa fornecer o código-fonte que soluciona o problema, ou um teste de regressão contra uma versão anterior que demonstra o comportamento incorreto, você provavelmente não está certo o bastante. Isso também se aplica a páginas web e documentação; se você encontrou um "bug" de documentação, deveria fornecer o texto correto para substituição e em quais páginas ele deveria substituir o texto atual.

Lembre-se, há vários usuários que não tiveram o mesmo problema que você. Se eles também tivessem tido o problema, você teria sabido dele lendo a documentação e procurando na Web (você fez isso antes de reclamar, não fez?). Isso significa, muito provavelmente, que é você que está fazendo alguma coisa errada, não o software.

As pessoas que escreveram o software trabalharam duro para fazê-lo funcionar tão bem quanto possível. Se você diz que achou um bug, está dizendo implicitamente que eles fizeram algo errado e quase sempre isso vai ofendê-los - mesmo quando você estiver correto. É especialmente não-diplomático escrever "bug" no campo Assunto da mensagem.

Quando for perguntar, o melhor a fazer é escrever como se você estivesse fazendo algo errado, mesmo que esteja bastante certo de que achou um bug real. Se existir realmente um bug, você vai ficar sabendo pela resposta. Fazendo as coisas desta maneira, os mantenedores do sofware irão se desculpar no caso do bug ser real, ao invés de você ter de se desculpar com eles no caso de estar errado.

Auto-piedade não substitui fazer o seu dever de casa

Algumas pessoas que entendem que quando se pergunta não se deve agir de maneira rude ou arrogante, exigindo uma resposta, caem no extremo oposto da auto-piedade. "Eu sei que sou somente um iniciante e patético loser, mas...". Isso distrai o leitor do objetivo principal e não é de nenhuma ajuda. É especialmente irritante quando combinado com uma descrição ou dados vagos do problema em questão.

Não gaste o seu tempo, nem o nosso, com política de nível primata. Ao invés disso, apresente os fatos do contexto e sua pergunta o mais claramente que puder. Esta é uma maneira melhor de se posicionar do que usar de auto-piedade.

Algumas vezes os fóruns web tem lugares separados para perguntas de principiantes. Se você achar que a sua pergunta é realmente de principiante, este é o lugar certo para ela. Mas não use de auto-piedade aí também.

Descreva os sintomas do problema, não os seus palpites

Não é útil explicar a hackers o que você acha que está causando o seu problema (se as suas teorias de diagnóstico são assim tão boas, será que você estaria pedindo ajuda?). Por isso, esteja seguro de descrever os sintomas reais do problema, ao invés de suas teorias e interpretações sobre ele. Deixe que eles façam a interpretação e o diagnóstico. Se você acha que é importante descrever seus palpites, marque-os claramente como tais e descreva porque eles não estão funcionando para você.

Estúpido:

     Estou tendo erros SIG11 back-to-back na compilação do kernel e suspeito de uma quebra de hairline em um dos motherboard traces. Qual é a melhor maneira de conferir se é isso mesmo?

Inteligente:

     Meu K6/233 montado em casa, com placa-mãe FIC-PA2007 (chipset VIA Apollo VP2) e 256MB de memória SDRAM PC133 Corsair apresenta erros SIG11 frequentes, aproximadamente 20 minutos depois de ligado (nunca antes disso), durante a compilação do kernel. Se reinicio, os erros continuam imediatamente. Mas se deixo a máquina desligada durante toda a noite, voltam os erros depois de 20 minutos. Trocar todos os bancos de RAM não ajudou. Segue abaixo a parte relevante de uma sessão de compilação.

Já que este assunto parece ser difícil de entender para muitas pessoas, aqui vai uma frase que ajuda a guardar a ideia: "Todos os diagnosticadores são do Missouri". O lema oficial deste estado é "Mostre-me" (atribuído em 1899, quando o congressista Willard D. Vandiver disse "Eu venho de um lugar que cultiva milho e algodão e Xanthium e Democratas e eloquência fajuta nunca me convence ou me satisfaz. Venho do Missouri. Você tem que me mostrar."). No caso dos diagnosticadores, isso não é um problema de ceticismo, mas uma necessidade literal, funcional de ver o mais perto possível a evidência bruta que você viu e não suas conjecturas ou conclusões. Mostre-nos.

Descreva os sintomas do seu problema em ordem cronológica

As pistas mais úteis para descobrir algo errado muitas vezes estão nos eventos que ocorreram imediatamente antes do erro. Sua descrição deve, portanto, descrever precisamente o que você fez e o que a máquina fez, até o momento do problema. No caso de processos de linha de comando, ter um log da sessão (por exemplo usando o utilitário script) e destacar as 20 ou mais linhas relevantes é muito útil.

Se o software que travou com você tem opções de diagnóstico (como -v para modo verboso), pense cuidadosamente sobre a viabilidade de selecionar opções que irá gerar informações úteis de debug para o log da sessão.

Se sua descrição do problema acabou ficando longa (mais que quatro parágrafos), pode ser útil descrever sucintamente o problema no começo e então seguir numa linha cronológica. Desta maneira, os hackers vão saber o que procurar quando lerem sua mensagem.

Descreva o objetivo final, não os passos para chegar a ele

Se você quer descobrir como se faz alguma coisa (ao invés de reportar um bug), comece descrevendo o objetivo final. Somente depois descreva o passo no qual você está preso.

Muitas vezes, as pessoas que necessitam de ajuda técnica têm um objetivo final em mente, mas ficam obcecadas com um caminho específico para a solução. Pedem ajuda para resolver um passo, sem perceber que o próprio caminho está errado. É necessário muito esforço para superar isto.

Estúpido:

     Como posso fazer com que o selecionador de cores do software FooDraw receba um valor hexadecimal?

Inteligente:

     Estou tentando trocar a tabela de cores de uma imagem por valores personalizados. Neste momento, a única solução em que consigo pensar é editar cada entrada da tabela, mas nâo consigo fazer com que o selecionador de cores do FooDraw receba um valor hexadecimal.

A segunda versão da pergunta é inteligente. Ela permite uma resposta que sugira uma ferramenta mais bem adaptada à tarefa.

Não peça que as pessoas enviem a resposta para um email privado

Hackers acreditam que a solução de problemas deve ser um processo público e transparente, onde uma primeira tentativa de resposta pode e deve ser corrigida caso alguém mais capacitado perceba que ela seja incompleta ou incorreta. Lembre-se de que eles obtém parte de sua recompensa por responder perguntas por serem vistos por seus pares como competentes e capacitados.

Quando você pede uma resposta em um email privado, você atrapalha o processo e não permite a recompensa. Não faça isso. É escolha do respondente quando enviar uma resposta em particular - e se ele o faz, é geralmente por achar que a pergunta é muito óbvia ou mal elaborada para interessar aos demais.

Existe uma exceção, embora limitada, à esta regra. Se você acha que a pergunta certamente receberá muitas respostas similares, então as palavras mágicas são "enviem as respostas para mim e eu farei o resumo delas para o grupo". É cortês tentar, evita que a lista de discussão ou newsgroup receba um caminhão de respostas idênticas - mas você tem que cumprir o compromisso de fazer e enviar o sumário.

Seja explícito sobre o objetivo da pergunta

Perguntas abertas tendem a ser percebidas como ralos de tempo. As pessoas mais capazes de fornecer uma resposta útil são também as mais ocupadas (geralmente são elas que fazem quase todo o trabalho). Pessoas assim são alérgicas a sorvedouros de tempo e tendem a ser alérgicas a perguntas abertas.

Nota do tradutor: Foi utilizada a tradução "perguntas abertas" para "open-ended questions". A definição de "open-ended questions" é geralmente descrita como "o tipo de perguntas que incentivam a 'contar a história' com suas próprias palavras". Exemplificando: uma questão fechada ("close-ended question") seria: "Você tem um bom relacionamento com seus pais?" e sua equivalente aberta é "Fale-me sobre seu relacionamento com seus pais".

Você geralmente receberá uma resposta útil se for explícito e objetivo sobre o que você quer que os respondentes façam (fornecer referências, enviar código, verificar se a atualização que você está usando é a correta, etc.). Isso vai focar os esforços de seus respondentes e ao mesmo tempo colocar implicitamente um limite superior para o tempo e a energia que um respondente deve usar para responder à sua pergunta. Isto é bom .

Para entender o mundo em que vivem os especialistas, pense em expertise como um recurso abundante e tempo para responder como um recurso escasso. Quanto menos tempo você implicitamente demanda para a sua pergunta, mais possibilidades de receber uma resposta útil de alguém realmente competente e realmente ocupado você tem.

Portanto, é útil formular sua pergunta de modo a minimizar o tempo necessário para um expert respondê-la - note que, geralmente, isto não é a mesma coisa que simplificar a pergunta. Por exemplo: "Você poderia me fornecer uma referência de uma boa explicação sobre X?" é usualmente uma pergunta mais inteligente do que "Você poderia por favor explicar X?". Se você tem um código-fonte que não funciona, é mais inteligente pedir a alguém para explicar qual é o erro do que pedir a alguém para resolvê-lo.

Quando a pergunta for sobre código-fonte

Não peça aos outros para depurar seu código-fonte problemático sem fornecer uma dica sobre o tipo de problema que deve ser encontrado. Enviar algumas centenas de linhas dizendo "isto não funciona" vai fazer com que você seja ignorado. Ao contrário, enviar uma dúzia de linhas, dizendo "depois da linha 7 eu esperava que acontecesse <x>, mas aconteceu <y>" torna muito mais fácil obter uma resposta.

A maneira mais eficiente de ser preciso sobre um problema que envolva código-fonte é fornecer um caso de teste mínimo que demonstre o bug. Mas o que seria um caso de teste mínimo? É uma ilustraçço do problema: uma quantidade de código suficiente apenas para exibir o problema em questão e nada mais. Como fazer um caso de teste mínimo? Se você sabe que uma linha ou parte do código está produzido o comportamento problemático, faça uma cópia dela e adicione apenas código suficiente para produzir um exemplo completo (ou seja, o suficiente para ser aceito pelo compilador/interpretador/qualquer coisa que processe o programa. Se você não consegue limitar as linhas a uma seção em particular, faça uma cópia de tudo e remova as partes que não afetam o comportamento problemático. Quanto menor for seu caso de teste, melhor (veja a seção chamada "Volume não é precisão").

Gerar um caso de teste realmente pequeno não será sempre possível, mas tentar é uma boa disciplina, já que pode ajudar você a resolver o problema sozinho - e mesmo que não faça, os hackers gostam de ver que você tentou. Isto vai fazê-los mais cooperativos.

Se você deseja simplesmente uma revisão de código, exponha isso logo de início e esteja certo de citar quais áreas você acredita que devem ser revistas e porquê.

Não envie perguntas do tipo "dever de casa"

Hackers são bons em descobrir quando uma pergunta é do tipo "dever de casa"; a maioria de nós já as fez. Estas questões são para você resolver, para que assim você aprenda com a experiência. É OK perguntar por dicas, mas não pela solução completa.

Se você suspeita que uma pergunta do tipo "dever de casa" foi passada para você, mas de qualquer maneira não consegue resolvê-la, tente perguntar em um fórum voltado para usuários ou (como último recurso) em um fórum ou lista de projeto "para usuários". Mesmo que os hackers percebam o tipo da pergunta, alguns dos usuários avançados podem ao menos fornecer uma dica.

Evite perguntas supérfluas

Resista à tentação de terminar o seu pedido de ajuda com perguntas semanticamente nulas como "Alguém pode me ajudar?" ou "Existe uma resposta?". Primeiro: se você descreveu seu problema mais ou menos competentemente, estas perguntas em sua mensagem são no mínimo supérfluas. Segundo: porque elas são supérfluas, os hackers as acham aborrecidas - e ficam propensos a devolver respostas impecavelmente lógicas mas evasivas como "Sim, você pode ser ajudado" e "Não, não há ajuda possível no seu caso ".

Em geral, fazer perguntas do tipo sim-ou-não é algo a se evitar, a não ser que você queira respostas do tipo sim-ou-não.

Não marque sua pergunta como "Urgente", mesmo que ela seja urgente para você

O problema é seu, não nosso. Demandar urgência é muito propenso a ser contraproducente: muitos hackers vão simplesmente apagar estas mensagens como tentativas grosseiras e egoístas de obter atenção imediata e diferenciada.

Existe uma semi-exceção a esta regra. Pode ser válido mencionar que você está usando o software em algum lugar considerado famoso, um que vai excitar os hackers; neste caso, se você está correndo contra o relógio e diz isso de maneira educada as pessoas podem ficar interessadas o suficiente em responder rapidamente.

Esta é, no entanto, uma coisa arriscada a se fazer, porque a métrica dos hackers para o que é excitante é provavelmente diferente da sua. Mensagens vindas da Estação Espacial Internacional, por exemplo, se qualificam como excitantes, mas as vindas de uma organização de caridade ou política certamente não serão. De fato, enviar a mensagem "Urgente: Ajude-me a salvar os lindos bebês baleia!" vai garantir que você seja ignorado ou atacado até pelos hackers que acham que os lindos bebês baleia são importantes.

Se você acha tudo isso um mistério, releia o resto deste documento repetidamente até entendê-lo antes de enviar qualquer coisa.

Cortesia nunca é problema e algumas vezes ajuda

Seja cortês. Use "Por favor" e "Obrigado por sua atenção" ou "Obrigado por sua consideração". Deixe claro que você considera valioso o tempo que foi gasto pelos outros para ajudar você de graça.

Para ser honesto, isto não é tão importante quanto (e não pode ser um substituto para) ser gramaticalmente correto, preciso e descritivo, evitar formatos proprietários, etc.; geralmente os hackers preferem relatórios de bugs meio bruscos mas tecnicamente acurados do que polidez vaga. (Se isto intriga você, lembre-se de que nós hackers valorizamos a pergunta pelo que ela nos ensina.)

No entanto, se você cumpriu o seu dever de casa na parte técnica, a polidez aumenta suas chances de obter uma resposta útil.

(É preciso notar que a única objeção séria que recebemos de hackers veteranos a este guia diz respeito à nossa recomendação anterior em usar "Agradeço antecipadamente" ("thanks in advance").Alguns hackers acham que isto denota a intenção de não agradecer a ninguém depois. Nossa recomendação é dizer "Agradeço antecipadamente" primeiro e agradecer aos respondentes depois, ou expressar cortesia de uma maneira diferente, como por exemplo usar "Obrigado por sua atenção" ou "Obrigado por sua consideração".)

Envie uma mensagem breve após a solução do problema

Envie uma mensagem breve após o problema ter sido resolvido a todos os que ajudaram; deixe-os saber como o problema foi resolvido e agradeça-os novamente pela ajuda. Se o problema atraiu o interesse geral em uma lista de discussão ou newsgroup, é apropriado enviar a mensagem para lá.

Idealmente, a mensagem deve ser uma resposta na mesma sequência de mensagens iniciada pela mensagem original que descreveu o problema. A mensagem deve ter um assunto óbvio como "CORRIGIDO" ou "RESOLVIDO". Em listas de discussão com alta taxa de recebimento de mensagens, um respondente em potencial que vê uma sequência de mensagens sobre o "Problema X" que termina com "Problema X - RESOLVIDO" sabe que não precisa gastar seu tempo nem para lê-la (a menos que ele(ela) ache o Problema X particularmente interessante) e pode assim usar seu tempo para resolver um problema diferente.

Sua mensagem de agradecimento não deve ser longa; um simples "Opa -- Era um cabo de rede com problema! Obrigado a todos - Bill" é melhor que nada. Na verdade, um resumo pequeno e bem escrito é melhor que uma longa dissertação, a menos que a solução tenha uma profundidade técnica considerável. Diga qual ação resolveu o problema; não é necessário relembrar toda a sequência de ações da solução.

Para problemas com alguma profundidade técnica, é apropriado enviar um resumo das ações que levaram à solução. Descreva o problema. Descreva a solução que funcionou e indique os becos sem saída depois. Eles devem vir depois da solução correta e dos outros assuntos do resumo, ao invés de transformar a mensagem em uma história de detetive. Indique os nomes das pessoas que ajudaram você; dessa maneira você fará amigos.

Além de ser cortês e informativo, este tipo de mensagem vai ajudar outras pessoas que porventura procurem nos arquivos da lista de discussão/newsgroup/fórum a encontrar e entender exatamente que solução ajudou você e que portanto pode também ajudá-los.

Por último, mas não menos importante, este tipo de mensagem ajuda a todos que participaram a sentir que o problema foi fechado. Se você não é um aficionado ou hacker, confie em nós: este sentimento é muito importante para os gurus e experts a quem você pediu ajuda. Narrativas de problemas que acabem não resolvidos são frustrantes; hackers têm coceira para vê-las resolvidas. O bom carma que traz resolver essa coceira será de muita, muita ajuda para você na próxima vez em que precisar fazer uma pergunta.

Pense em como você pode ser capaz de prevenir que outros enfrentem o mesmo problema no futuro. Pergunte-se se correções na documentação ou FAQ ajudariam e, se a resposta for sim, faça as correções e mande-as para o responsável pela manutenção do projeto.

Entre hackers, este tipo de comportamento é realmente mais importante que a polidez convencional. É assim que você constrói uma reputação de trabalhar bem (e para) as outras pessoas, o que pode vir a ser um patrimônio muito valioso.

Como interpretar respostas

RTFM e STFW: Como saber se você realmente fez m...

Existe uma antiga e reverenciada tradição: se você recebeu uma resposta contendo "RTFM", a pessoa que a enviou acha que você deveria "Ler a m... do manual" ("Read The Fucking Manual"). Ela deve ter razão. Vá ler.

RTFM tem um irmão mais novo. Se você recebeu uma resposta contendo "STFW", a pessoa que a enviou acha que você deveria "Procurar na maldita Web" ("Search The Fucking Web"). Ela deve ter razão. Vá procurar. (A versão mais amena desta mensagem é quando dizem para você "O Google é seu amigo!")

Em fóruns web, também podem dizer a você para procurar nos arquivos. Na verdade, pode até existir alguém tão gentil a ponto de fornecer uma referência para a sequência de mensagens na qual o problema foi desenvolvido. Mas não se fie nisso; faça a procura nos arquivos antes de perguntar.

Frequentemente a pessoa que diz a você para fazer a procura sozinho está olhando para o manual ou página web com a informação que você precisa enquanto digita a mensagem. Isto significa que ele pensa que (a) a informação de que você precisa é fácil de achar e (b) você vai aprender mais se procurar pela informação do que se ela lhe for servida em uma bandeja de prata.

Você não deveria se sentir ofendido com isto; pelos padrões hacker, ele está mostrando certo respeito por você pelo fato de simplesmente não ignorá-lo. Você deveria agradecê-lo por sua bondade maternal.

Se você não entender...

Se você não entender a resposta para sua pergunta, não envie imediatamente um pedido por explicações detalhadas. Use as mesmas ferramentas que serviram para testar e investigar a sua questão (manuais, FAQs, web, amigos mais experientes) para entender a resposta. Então, se você ainda necessitar de explicações, mostre o que aprendeu tentando entender.

Por exemplo, suponha que eu diga: "Parece que você tem um zentry com problemas; limpe as configurações dele." O exemplo ruim de resposta é: "O que é um zentry?" Um bom exemplo seria: "OK, eu li o manual e os zentries são mencionados somente nas opções -p e -z. Nenhuma delas diz nada sobre limpar as configurações de um zentry. Alguma dessas é a opção certa ou estou entendendo errado?"

Lidando com a grosseria

Nos círculos hacker, Muito do que parece grosseria não tem o propósito de ofender. É, ao invés disso, o produto de um estilo de comunicação direto, tipo esqueça-as-formalidades, que é natural a pessoas que estão mais preocupadas em resolver problemas do que em fazer com que os outros se sintam felizes e queridos.

Quando você perceber a grosseria, tente reagir com calma. Se alguém está realmente se excedendo, é muito provável que uma pessoa mais graduada da lista de discussão ou newsgroup vai chamar a atenção dele por isso. Se isso não acontecer e você perder a cabeça, é provável que a pessoa que irritou você estivesse agindo dentro das normas da comunidade hacker e você é quem estará errado. Isto vai piorar suas chances de conseguir a informação ou ajuda de que precisa.

Por outro lado, você vai lidar ocasionalmente com grosseria e fingimento que são realmente gratuitos. O outro lado da moeda do parágrafo anterior é que é aceitável bater em ofensores reais pra valer, dissecando seu mau comportamento com um escalpelo verbal afiado. No entanto, esteja muito, muito certo disso antes de tentar. A linha entre corrigir uma incivilidade e iniciar uma guerra de mensagens (flamewar) sem motivo é fina o suficiente para que mesmo os próprios hackers sejam responsáveis por infringi-la sem razão às vezes; se você é um novato ou ainda não pertence ao grupo, suas chances de evitar esse erro são poucas. Se você deseja informação e não entretenimento, é melhor manter seus dedos longe do teclado do que se arriscar a isso.

(Algumas pessoas afirmam que vários hackers sofrem de uma forma branda de autismo ou Síndrome de Asperger e que não possuem alguns dos circuitos cerebrais que facilitam a interação social humana 'normal'. Isto pode ou não ser verdade. Se você não é um hacker, o fato de pensar que as nossas excentricidades são resultado de um problema cerebral pode ajudar. Vá em frente. Nós não nos importamos; nós gostamos de ser como somos e geralmente mantemos um saudável ceticismo sobre rótulos clínicos.)

Na próxima seção, vamos falar sobre um assunto diferente; o tipo de "grosseria" que você vai experimentar quando você se comporta mal.

Sobre como não reagir como um Loser

Existem boas chances de que algumas vezes você faça m... em fóruns hacker - das maneiras descritas neste artigo ou similares. E, nessas ocasiões, você ouvirá exatamente como foi que você fez m..., possivelmente com expressões coloridas. Em público.

Quando isso acontecer, a pior coisa que você pode fazer é fazer birra sobre o fato, reclamar que foi assaltado verbalmente, exigir desculpas, gritar, prender o fôlego, tramar processos legais, reclamar com os empregadores dos responsáveis pelas mensagens, deixar a tampa da privada aberta, etc. Ao invés de tudo isso, eis aqui o que você deve fazer:

Supere isso. É normal. Na verdade, é saudável e apropriado.

Padrões de comunidade não mantém a si mesmos. São mantidos por pessoas que os aplicam ativamente, visivelmente, em público. Não faça birra dizendo que todas as críticas deveriam ser enviadas para um email privado: não é assim que a coisa funciona. Também não adianta insistir que você foi pessoalmente insultado quando alguém comenta que uma das suas reclamações é errada, ou que tem um ponto de vista diferente. Estas são atitudes de loser.

Já houve fóruns hacker onde, devido a algum senso equivocado de hiper-cortesia, os participantes foram proibidos de enviar qualquer mensagem que destacasse os erros alheios e foi dito a eles "Se você não quiser ajudar o usuário, não diga nada." A consequente debandada de participantes tecnicamente competentes para outros lugares fizeram com que estes fóruns perdessem seu sentido e significado e se tornassem imprestáveis.

Exageradamente "amigável" (da maneira descrita acima) ou útil: escolha uma das duas.

Lembre-se: Quando aquele hacker lhe diz que você fez m... e (não importa o quão agressivamente) lhe diz para não fazer isso de novo, ele age pensando em (1) você e (2) sua comunidade. Seria muito mais fácil para ele ignorar você e filtrá-lo de sua vida. Se você não pode ser grato a ele por não fazer isso, tenha ao menos um pouco de dignidade, não faça birra e não espere ser tratado como uma boneca frágil somente porque é um principiante com uma alma teatralmente hipersensitiva e ilusões de que tem direitos especiais.

Algumas vezes as pessoas vão atacar você de maneira pessoal, enviar mensagens agressivas sem uma razão aparente, etc., mesmo que você não tenha feito m... (ou que eles apenas pensem que você fez). Neste caso, reclamar é a maneira de realmente fazer m...

Estes atacantes (flamers) ou são lamers sem noção, mas que acreditam ser experts, ou candidatos a psicólogs testando se você vai fazer m... Os outros participantes ou os ignoram ou encontram suas próprias maneiras de tratar com eles. O comportamento destas pessoas cria problemas para elas mesmas e você não deve se preocupar com isso.

N. do T.: O conceito "lamer" provavelmente levaria um documento tão grande quanto esse para ser descrito com as cores adequadas. Mas acredite: você com certeza não quer ser um lamer.

Também não se deixe ser arrastado para uma flamewar. É melhor ignorar muitas das mensagens agressivas (flames) -- depois de conferir se elas são realmente flames e não explicações sobre como você fez m..., ou mesmo respostas para a sua pergunta inteligentemente cifradas (isto também costuma acontecer).

Perguntas que não se deve fazer

Aqui vão algumas perguntas estúpidas clássicas e o que os hackers pensam quando não as respondem.

P: Aonde posso encontrar o programa ou recurso X?
P: Como posso usar X para fazer Y?
P: Como posso configurar meu shell prompt?
P: Posso converter um documento da AcmeCorp em um arquivo TeX usando o conversor Bass-o-matic?
P: Meu {programa, configuração, SQL} não funciona.
P: Tenho problemas com meu computador que roda Windows. Podem me ajudar?
P: Meu programa não funciona. Acho que o recurso X do sistema está com problemas.
P: Tenho problemas instalando o Linux ou o X. Podem me ajudar?
P: Como posso quebrar a senha do administrador/conseguir privilégios de administrador do canal IRC/ler os emails de alguém?

P: Aonde posso encontrar o programa ou recurso X?
R: No mesmo lugar em que eu o encontrei, idiota-na outra ponta de uma busca web. Caramba, sera possível que ainda tem gente que não sabe usar o Google?
P: Como posso usar X para fazer Y?
R: Se o que você quer é fazer Y, você deveria perguntar exatamente isso, sem pressupor o uso de um método que pode não ser apropriado. Perguntas desta forma muitas vezes mostram que a pessoa não somente ignora X, mas está confusa sobre o problema Y que tenta resolver e está obcecada pelos detalhes particulares da situação. É geralmente melhor ignorar esse tipo de pessoa até que eles definam melhor o seu problema.
P: Como posso configurar meu shell prompt?
R: Se você é esperto o suficiente para perguntar isso, também é esperto o suficiente para RTFM e descobrir por você mesmo.
P: Posso converter um documento da AcmeCorp em um arquivo TeX usando o conversor Bass-o-matic?
R: Tente e descubra. Se você fizer isso, vai (a) aprender a resposta e (b) parar de desperdiçar meu tempo.
P: Meu {programa, configuração, SQL} não funciona.
R: Isto não é uma pergunta e eu não estou interessado em brincar de adivinhação para extrair a sua pergunta real de você - tenho coisas melhores para fazer. Quando vejo uma coisa dessas, minha reação é geralmente uma das seguintes:
  • você tem alguma coisa a acrescentar a isso?
  • oh, isso é tão ruim. Espero que você consiga consertar.
  • o que isso tem exatamente a ver comigo?
P: Tenho problemas com meu computador Windows. Podem me ajudar?
R: Sim. Jogue fora esse lixo da Microsoft e instale um sistema operacional open-seouce como o Linux ou o BSD.

Nota: você pode fazer perguntas relacionadas a máquinas com sistema operacional Windows se elas são sobre um software que tem uma versão oficial para Windows, ou interage com máquinas Windows (como por exemplo o Samba). Mas não fique surpreso se obter uma resposta que diz que o problema é com o Windows e não com o software, porque o Windows é geralmente tão problemático que este é muitas vezes o caso.
P: Meu programa não funciona. Acho que o recurso X do sistema está com problemas.
R: Mesmo que exista a possibilidade de que você seja a primeira pessoa a perceber um problema óbvio nas chamadas de sistema e bibliotecas que são usadas frequentemente por centenas de milhares de pessoas, é muito mais provável que você seja um total sem noção. Descobertas extraordinárias demandam evidências extraordinárias; quando você faz uma descoberta dessas, deve baseá-la em documentação clara e exaustiva da falha.
P: Tenho problemas instalando o Linux ou o X. Podem me ajudar?
R: Não. Para isso, eu precisaria de acesso físico à sua máquina. Peça esse tipo de ajuda ao seu grupo de usuários Linux (você pode encontrar uma lista de grupos de usuários aqui.)

Nota: perguntas sobre a instalação do Linux podem ser inapropriadas se você estiver em um fórum ou lista de discussão sobre uma distribuição Linux específica e o problema é com essa distribuição; ou em fóruns de grupos de usuários locais. Neste caso, esteja certo de descrever os detalhes exatos da falha. Mas antes disso, faça uma busca cuidadosa, contendo a palavra "linux" e todos os components de hardware suspeitos.
P: Como posso quebrar a senha do administrador/conseguir privilégios de administrador do canal IRC/ler os emails de alguém?
R: Você é um pária por querer fazer essas coisas e um idiota por pedir a um hacker para lhe ajudar.

Boas e más perguntas

Vou, finalmente, ilustrar como perguntar de maneira inteligente com exemplos; pares de perguntas sobre o mesmo problema, uma estúpida e outra inteligente.

Estúpida: Onde posso encontrar material sobre o Foonly Flurbamatic?

Esta pergunta simplesmente implora por uma resposta "STFW".

Inteligente: Usei o Google para procurar na web por "Foonly Flurbamatic 2600", mas não consegui nada útil. Alguém sabe onde posso encontrar informações sobre a programação para este dispositivo?

     Este aqui já fez um STFW e parece que pode ter um problema real.

Estúpida: Não consigo compilar o projeto foo. Porque ele está com problemas?

     Esse está assumindo que alguém fez alguma m... no projeto. Arrogante.

Inteligente: O código do projeto foo não compila sobre o Nulix versão 6.2. Li o FAQ, mas não encontrei nada relacionado a problemas relacionados ao Nulix. Segue um log da minha tentativa de compilação; é alguma coisa que eu fiz de errado?

     Esse outro especificou o ambiente, leu o FAQ, mostrou o erro e não está assumindo que seus problemas são causados por outra pessoa. Esse cara merece alguma atenção.

Estúpido: Tenho problemas com minha placa-mãe. Alguém pode me ajudar?

     A resposta de J. Random Hacker para isso seria parecida com "Certo. Você precisa que te ponham para arrotar e de fraldas também?" seguida de uma tecla de delete.

Inteligente: Tentei X, Y e Z na placa-mãe S2464. Quando isto não funcionou, tentei A, B e C. Perceba o sintoma curioso quando tentei C. Obviamente o florbish está grommicking, mas os resultados não são os que normalmente se espera. Quais são as causas usuais de grommicking em placas-mãe Athlon MP? Alguém tem ideias sobre quais outros testes eu posso executar para encontrar o problema?

     Esta pessoa, por outro lado, parece merecer uma resposta. Ele exibiu inteligência para resolver problemas, ao invés de ficar passivamente esperando que uma resposta caísse do céu.

Perceba, na última pergunta, a sutil mas importante diferença entre dizer "Dê-me uma resposta" e "Por favor ajude-me a descobrir quais testes de diagnóstico eu posso executar para resolver o problema."

Na verdade, a forma da última pergunta é baseada em um incidente real que aconteceu em agosto de 2001 na lista de discussão por email linux-kernel (lkml). Eu (Eric) era a pessoa que estava perguntando dessa vez. Eu experimentava travamentos misteriosos com uma placa-mãe Tyan S2462. Os participantes da lista forneceram as informações essenciais para que eu precisava para resolver o problema.

Perguntando da forma como eu perguntei, eu dei às pessoas algo para mastigar; eu tornei fácil e atrativo para elas se envolverem. Eu demonstrei respeito pela capacidade de meus pares e convidei-os a trabalhar comigo como iguais. Também demonstrei respeito pelo valor do tempo deles, dizendo-lhes quais becos sem saída eu já tinha percorrido.

Depois do problema resolvido, quando eu agradeci a todos e detalhei quão bem o processo tinha funcionado, um participante da lkml disse que achava que o processo tinha funcionado tão bem não porque eu era um "nome famoso" daquela lista, mas sim porque eu tinha perguntado da forma correta.

Hackers são, de um certo ponto de vista, uma meritocracia impiedosa. Tenho certeza de que ele estava certo e que se eu tivesse me comportado como uma ameba teria sido atacado (flamed) ou ignorado, não importa quem eu fosse. Sua sugestão, de que eu escrevesse todo o incidente como um referência para os outros levou diretamente à composição deste guia.

Se você não conseguir uma resposta

Se você não conseguir uma resposta, por favor não tome isso como pessoal e assuma que nós não queremos ajudar você. Algumas vezes, os membros do grupo para o qual você perguntou podem simplesmente não saber a resposta. Não obter nenhuma resposta não é o mesmo que ser ignorado, embora seja reconhecidamente difícil saber a diferença entre os dois.

Em geral, simplesmente reenviar a sua pergunta é uma má ideia. Isto vai ser visto como chateação sem motivo.

Existem outras fontes de ajuda a que você pode recorrer, muitas vezes mais bem adaptadas às necessidades de um principiante.

Existem vários grupos de usuários locais e online que são entusiastas sobre software, mesmo que eles próprios nunca tenham escrito software. Estes grupos se formam para que as pessoas possam ajudar umas às outras e também aos usuários iniciantes.

Há também muitas empresas das quais você pode contratar ajuda, grandes e pequenas (Red Hat e Linuxcare estão entre as mais conhecidas, mas há muitas outras). Não fique desanimado com a ideia de ter que pagar por ajuda! Se o motor de seu carro estourar um cabeçote, certamente você iria a um mecânico e pagaria para consertá-lo. Mesmo que o software não tenha lhe custado nada, você não pode esperar que o suporte seja sempre de graça.

Para softwares populares como o Linux, existem pelo menos 10000 usuários por desenvolvedor. Simplesmente não é possível para uma só pessoa atender a todos os chamados de suporte de 10000 usuários. Lembre-se de que, mesmo que você tenha de pagar pelo suporte, ainda está pagando muito menos do que quando também tinha de comprar o software (e o suporte para o software proprietário é usualmente mais caro e menos competente do que o suporte do software livre).

Como responder de maneira útil

Seja gentil. O estresse causado por problemas pode fazer pessoas parecerem rudes ou estúpidas, mesmo quando não são.

Responda a um verdadeiro principiante em particular. Não há necessidade de humilhar publicamente alguém que cometeu um erro honestamente. Um verdadeiro principiante pode não saber como procurar nos arquivos do fórum ou aonde o FAQ está disponibilizado.

Se você não está bem certo da resposta, diga isso! Uma resposta errada dada com autoridade é pior do que não dar nenhuma resposta. Não guie alguém para um caminho errado simplesmente porque é divertido agir como um expert. Seja humilde e honesto; dê um bom exemplo para o solicitante e para seus próprios colegas.

Se não pode ajudar, não atrapalhe. Não faça piada sobre procedimentos que podem formatar a máquina do usuário - o pobre coitado pode interpretá-los como instruções.

Faça perguntas investigativas para obter mais detalhes. Se você for bom nisto, o solicitante vai aprender - e você também. Tente transformar as perguntas ruins em boas; lembre-se de que todos fomos principiantes um dia.

Mesmo que rosnar RTFM seja justificável quando a resposta for para alguém que é só um negligente preguiçoso, é melhor fornecer uma referência para a documentação (mesmo que seja somente uma sugestão para procurar uma palavra-chave no Google).

Se você vai mesmo responder à pergunta, entregue boas respostas. Não indique soluções ruins quando alguém está usando a ferramenta ou caminhos errados. Sugira boas ferramentas. Reposicione a pergunta.

Ajude a sua comunidade a aprender com a pergunta. Quando responder a uma boa questão, pergunte-se "Qual seria a mudança na documentação ou FAQ para que ninguém precise responder esta pergunta novamente?" Faça as mudanças e envie para o mantenedor dos documentos do projeto.

Se você pesquisou para responder à pergunta, demonstre suas habilidades ao invés de escrever como se tivesse tirado a resposta da sua b... Responder a uma boa questão é como dar um peixe a uma pessoa faminta. Ensinar técnicas de pesquisa através de exemplos é como ensiná-lo a pescar.

Recursos relacionados

Se você precisa de instruções básicas de uso de computadores pessoais, Unix e Internet, veja The Unix and Internet Fundamentals HOWTO.

Quando lançar software ou escrever correções para softwares, tente seguir as linhas detalhadas em Software Release Practice HOWTO.

Agradecimentos

Evelyn Mitchell contribuiu com exemplos de perguntas estúpidas e inspirou a seção "Como responder perguntas de maneira útil". Mikhail Ramendik contribuiu com algumas sugestões de melhorias particularmente valiosas.


Other popular articles:
where are goldfish from
where are my drafts on tiktok 2022
where are outlook signatures stored
where are subaru cars made
where are pit boss grills made
Copyright 2015