Baixe Como fazer perguntas inteligentes e outras Exercícios em PDF para Informática, somente na Docsity!
Como Fazer Perguntas Inteligentes
Sobre direitos autorais e cópias deste guia
Todos os direitos deste guia pertencem a Eric Steven Raymond. De uma forma geral, seu desejo é que o maior número de pessoas o leiam, portanto você é livre para linkar e copiar este conteúdo. Entretanto, cópias estáticas não podem ser produzidas sem sua autorização. Se algum leitor vir seu nome em um documento, ele precisa ver todas as atualizações que este documento sofreu. Nada de cópias abandonadas e desatualizadas espalhadas pela Internet. A versão em português deste guia foi produzida por Marcos Machado. Da mesma forma, você é livre para copiar ou linkar este documento. Da mesma forma, mantenha sua versão atualizada (traduções também sofrem revisões!). O modo mais fácil de fazer isso é apenas linkar este documento, mas se preferir copiá-lo, visite regularmente esta página para se certificar de que possui a última versão. Jamais remova estes avisos de direitos autorais e os links para o documento original.
Introdução
No mundo dos hackers , o tipo de resposta que você obtém as suas perguntas técnicas depende muito mais de como você faz a pergunta do que da dificuldade em preparar a resposta. Este guia ensinará a você como fazer perguntas do jeito mais indicado para conseguir uma resposta satisfatória. Agora que o uso do open source está bastante difundido, é mais comum você encontrar respostas de outros usuários, mais experientes, do que dos hackers. Isto é uma Coisa Boa: usuários tendem a ser um pouco mais tolerantes com os tipos de problemas que os novatos enfrentam. E ainda, tratar estes usuários como hackers, da maneira como recomendamos aqui é, geralmente, a maneira mais efetiva de conseguir respostas úteis deles também. A primeira coisa que você deve saber é que hackers realmente gostam de problemas difíceis e questões boas e intrigantes sobre estes problemas. Senão, nós não estaríamos aqui. Se você nos der uma questão interessante para mastigar nós ficaremos gratos à
você; boas perguntas são um estímulo e um presente. Boas perguntas nos ajudam a desenvolver nosso entendimento, e freqüentemente revela problemas que não conhecíamos ou sobre os quais nunca pensamos. Entre hackers, "boa pergunta" é um forte e sincero elogio. Apesar disso, hackers têm a reputação de encarar perguntas simples com arrogância e hostilidade. De vez em quando aparentamos ser rudes com novatos e ignorantes. Mas isto não é verdade. Nós somos, sim, hostis com pessoas que não querem pensar nem fazer seu dever de casa antes de fazer perguntas. Pessoas assim são dissipadoras de tempo - elas pegam e não devolvem, elas desperdiçam tempo que pode ser usado em questões de gente que que merece uma resposta. Nós chamamos pessoas assim de "losers" (e por uma razão histórica, algumas vezes grafamos como "lusers"). N.T.: "Luser" é um trocadilho com as palavras "user" (usuário) e "loser" (perdedor, otário). Nós percebemos que existem muitas pessoas que querem apenas usar os softwares que escrevemos e não têm nenhum interesse em aprender detalhes técnicos. Para muitas pessoas, um computador é apenas uma ferramenta, um meio para um fim; eles têm coisas mais importantes para fazer nas suas vidas. Nós reconhecemos isso e não esperamos que todos tenham interesse nas questões técnicas que nos fascinam. Entretanto, nosso estilo de resposta é ajustado para aqueles que possuem este tipo de interesse e que desejam participar da solução de problemas. Isto não vai mudar. Nem deveria; se isso acontecesse, nós nos tornaríamos menos eficazes naquilo que sabemos fazer de melhor. Nós somos (na maioria dos casos) voluntários. Nós reservamos um tempo nas nossas ocupadas vidas para responder perguntas e, às vezes, ficamos sobrecarregados delas. Então nós as filtramos sem dó nem piedade. Em particular, nós jogamos fora questões de pessoas que aparentam ser "losers", para que possamos gastar nosso tempo de forma mais eficiente, em questões de "winners". (N.T.: vencedores) Se você acha essa atitude condenável ou arrogante, reveja seus conceitos. Nós não estamos pedindo que se curve diante de nós - na verdade, o que muitos de nós mais queremos é tratá-lo como igual e recebê-lo em nossa cultura, se você fizer o esforço necessário para que isso seja possível. Mas é simplesmente inútil para nós tentar ajudar pessoas que não estão dispostas a ajudar a si mesmas. Tudo bem ser ignorante; mas não é legal bancar o estúpido.
Use táticas como pesquisar no Google com o texto de qualquer mensagem de erro que você receba (e pesquise no Google Groups assim como na web). Isto pode levá-lo diretamente ao documento ou à thread da lista que irá responder à sua pergunta. Mesmo que isto não aconteça, é legal dizer "Eu pesquisei no Google a seguinte frase mas não encontrei nada útil" na sua mensagem quando pedir ajuda. Prepare sua pergunta. Pense além. Perguntas corridas recebem respostas corridas, ou nenhuma. Quanto mais você demonstrar que investiu tempo e neurônios na solução do seu problema antes de pedir ajuda, mais provável será que você consiga nossa ajuda. Tome cuidado com perguntas erradas. Se você fizer uma pergunta baseada em pressupostos equivocados, um hacker qualquer vai enviar uma resposta literal inútil enquanto pensa "Que pergunta idiota...", esperando que a resposta ao que você perguntou, mesmo que não seja a resposta que você espera, te ensine alguma coisa sobre como fazer perguntas. Nunca assuma que você merece uma resposta. Você não merece; você não está, afinal de contas, pagando por este serviço. Você irá ganhar uma resposta, se ganhar, fazendo perguntas substanciais, interessantes e intrigantes - uma que contribua com a experiência da comunidade ao invés de apenas extrair conhecimentos dos outros. Por outro lado, deixar claro que você pode e quer ajudar no processo de desenvolver uma solução é um ótimo começo. "Alguém pode me indicar uma direção?", "O que está errado no meu exemplo?" e "Qual site eu devia ter verificado?" é mais provável de receber uma resposta do que "Por favor, envie o procedimento exato que eu devo usar", pois assim fica claro que você está disposto a completar o processo se alguém apenas indicar a direção certa.
Quando você perguntar
Escolha cuidadosamente seu fórum
Seja cuidadoso ao escolher onde você vai enviar sua pergunta. Você será ignorado ou tachado de idiota se você:
- enviar sua pergunta em um fórum que não trata do assunto
- enviar uma questão muito básica em um fórum onde são esperadas questões tecnicamente mais avançadas, ou vice-versa.
- enviar a mesma pergunta para diversos fóruns ou newsgroups.
- enviar um email pessoal para alguém que não seja seu conhecido nem responsável direto por resolver seu problema. Hackers detonam questões que estão inapropriadamente direcionadas para evitarem que seus canais de comunicação de se tornem irrelevantes. Você não quer que isso aconteça contigo. O primeiro passo é, portanto, escolher o fórum certo. Novamente, Google e outros mecanismos de pesquisa são seus amigos. Use-os para encontrar os sites dos projetos que estejam mais intimamente relacionados aos softwares ou hardwares que estão lhe causando problemas. Normalmente eles possuem links para um FAQ (Resportas à Perguntas Freqüentes), para listas de discussão e seus respectivos históricos. Estas listas de discussão são o último lugar onde pedir ajuda se seus esforços anteriores (incluindo ler o FAQ) não lhe trouxerem uma solução. A página do projeto também pode descrever como reportar um bug; se for o caso, siga as instruções. Enviar uma mensagem para uma pessoa ou um fórum com o qual não está familiarizado é o mais arriscado. Por exemplo, não pense que o autor de uma página informativa quer ser seu consultor gratuitamente. Não faça projeções otimistas sobre sua mensagem ser bem aceita - se você não tiver certeza, envie sua mensagem em outro lugar, ou não envie. Quando escolher um fórum web, um newsgroup ou uma lista de discussão, não leve estes nomes a sério tão rapidamente; dê uma olhada no FAQ ou na descrição da lista para ter certeza de que sua mensagem faz parte do tipo de assunto tratado no local. Ler algumas mensagens antigas antes de enviar a sua pode lhe ajudar a descobrir como as coisas funcionam na comunidade. Na verdade, é uma excelente idéia fazer uma pesquisa sobre as palavras-chaves relacionadas ao seu problema antes de enviar uma mensagem. Se isto não lhe ajudar a encontrar uma resposta, vai lhe ajudar a formular melhor sua pergunta. Não dê uma rajada de perguntas em todos os canais de comunicação de uma só vez, isto é o mesmo que sair gritando e acaba irritando as pessoas. Vá com calma. Saiba como classificar sua mensagem! Um dos erros clássicos é enviar perguntas sobre interface de programação Unix ou Windows em um fórum sobre a linguagem de programação, que é portável para ambas as plataformas. Se você não compreende o problema neste exemplo, é melhor não fazer nenhuma pergunta até cair a ficha.
Como segundo passo, use a lista de discussão do projeto
Quando um projeto possuir uma lista de discussão, escreva para a lista, não para um determinado desenvolvedor, mesmo que você acredite saber quem melhor pode responder sua pergunta. Procure na documentação do projeto e visite seu site para descobrir o endereço da lista. Existem várias boas razões para se fazer isso:
- Qualquer questão que seja boa para um determinado desenvolvedor tem muito valor também para o resto do grupo. Por outro lado, se você acha que sua questão é idiota demais para enviar ao grupo, isto não é uma desculpa para atormentar um determinado desenvolvedor.
- Fazer perguntas na lista divide o trabalho entre os desenvolvedores. Um único desenvolvedor (especialmente se ele for o líder do projeto) pode estar muito ocupado para responder suas perguntas.
- Muitas listas são arquivadas e indexadas por ferramentas de pesquisa na web. Alguém pode encontrar sua pergunta e a resposta apenas pesquisando ao invés de perguntar a mesma coisa na lista.
- Se algumas perguntas são feitas com muita freqüência, os desenvolvedores podem usá-las para melhorar a documentação ou modificar o próprio sistema para torná-lo menos confuso. Mas se a pergunta for feita individualmente, ninguém poderá ter uma visão geral do problema. Se um projeto possui um fórum ou lista dividido entre usuários e desenvolvedores (hackers), se você não está modificando o código (hacking), use o fórum/lista para usuários. Não pense que você será bem-vindo na lista de desenvolvedores, pois eles considerarão sua mensagem como um ruído atrapalhando o tráfego de desenvolvimento. Entretanto, se você tem certeza de que sua questão não é banal e você não conseguiu ajuda na lista de usuários por vários dias, tente a de desenvolvedores. Uma boa recomendação é dar uma olhada na lista por alguns dias, antes de enviar sua mensagem, para aprender os modos do pessoal que a freqüenta (esta dica é válida para qualquer lista privada ou semi-privada). Se você não encontrar um endereço do fórum/lista de um determinado projeto, mas encontrar o endereço do mantenedor do projeto, vá em frente e faça sua pergunta a ele. Mas, mesmo neste caso, não assuma que a lista não existe. Deixe claro na sua mensagem que você tentou mas não encontrou a lista apropriada. Diga também que você
não se importa de ter sua mensagem encaminhada para outras pessoas. (Muitas pessoas acreditam que emails devem permanecer privados, mesmo que não tenham nenhuma informação secreta neles. Permitindo que sua mensagem seja encaminhada você dá ao destinatário a opção de como tratá-la.)
Use um subject específico e com significado
Em listas de discussão, newsgroups ou fórum web, o título da mensagem é sua chance de ouro para atrair, com 50 caracteres ou menos, a atenção de especialistas qualificados. Não desperdice este oportunidade com "Por favor, me ajudem" (muito menos "PRECISO DE AJUDA!!!"; mensagens assim são descartadas por reflexo). Não tente nos impressionar com sua angústia; ao invés, use este espaço para uma descrição super- concisa do seu problema. Uma boa convenção para títulos/assuntos de mensagens, usada pelo suporte técnico de muitas organizações, é o "objeto - anomalia". A parte "objeto" especifica o que está com problemas e a "anomalia" descreve como o comportamento diverge o esperado. Estúpido: AJUDA! Vídeo não funciona direito no meu laptop! Inteligente: XFree86 4.1 cursor do mouse distorcido, Fooware MV1005 vid. chipset Mais inteligente: XFree86 4.1 cursor do mouse na Fooware MV1005 vid. chipset - distorcido O processo de organizar o título no modelo "objeto - anomalia" vai ajudar você a organizar seu raciocínio sobre o problema. O que é afetado? Só o mouse ou outros gráficos também? Isto é específico do XFree86? Só da versão 4.1? Será que é específico do chipset Fooware? Só no modelo MV1005? Um hacker que olha esta mensagem pode imediatamente entender, de uma tacada só, o que está lhe causando problema e qual o problema que você está enfrentando. De uma maneira geral, se imagine olhando para um índice de um arquivo de perguntas, só com o título delas sendo exibido. Faça seu título refletir sua questão de forma que o próximo cara com uma pergunta semelhante a pesquisar o arquivo de perguntas consiga seguir esta thread até a resposta final, ao invés de enviar a mesma pergunta novamente.
está presente em quase todos os fóruns sob o nome de "Monitorar tópico", "Enviar email de aviso de resposta" etc.
Escreva de modo claro, gramatical e sintaticamente correto
Nós descobrimos, por experiência, que pessoas que são preguiçosas e não tomam cuidado com a escrita são, em geral, preguiçosas e sem cuidado com o ato de pensar ou programar (pode apostar nisso). Responder perguntas de preguiçosos descuidados não é compensador; preferimos gastar nosso tempo em outro lugar. Expressar sua dúvida bem e de forma clara é importante. Se você não quer se importar com isso, nós não queremos nos importar com você. Gaste algum tempo aprimorando seu linguajar. Ela não precisa ser dura ou formal - na verdade, a cultura hacker dá valor à linguagem informal, casual e com humor usada com precisão. Mas ela deve ser precisa; ela deve indicar que você está pensando e prestando atenção. Soletre, pontue e use maiúsculas e minúsculas corretamente. Não DIGITE TUDO EM MAIÚSCULAS, isto é lido como grito e é considerado grosseria. (Tudo em minúsculas é só um pouco menos chato, pois é difícil de ler) De uma forma geral, se você escreve como um semi-analfabeto muito provavelmente será ignorado. Escrever como "l33t script kiddie hax0r" é o absoluto beijo da morte e garante que você não receberá resposta nenhuma (ou, no máximo, uma pilha de escárnios e sarcasmos). Se você está fazendo perguntas em um fórum que não está na sua língua natal, você tem direito de errar um pouco na gramática ou na sintaxe das palavras - mas não nos casos de preguiça (e sim, nós conseguimos perceber a diferença). Além disso, a não ser que você saiba que idioma seu correspondente fala, escreva em inglês. Hackers atarefados costumam descartar mensagens em línguas que não entendem, e inglês é a língua padrão da Internet. Escrevendo em inglês você minimiza as chances de ter sua mensagem descartada sem ser lida.
Envie perguntas em formatos acessíveis e padronizados
Se você tornar sua mensagem difícil de ser lida, é muito provável que ela seja passada para trás em prol de mensagens mais fáceis de se ler. Então:
- Envie mensagens em plain text, não em HTML. (não é difícil desligar o HTML )
- Anexos no formato MIME tudo bem, desde que eles contenham algo realmente útil (como um código-fonte ou um patch), não uma bugiganga qualquer gerada pelo seu programa de email (como uma cópia da sua mensagem em outro formato).
- Não envie mensagens em que os parágrafos são muito longos e sem quebras de linhas. (Isto torna difícil responder apenas parte da mensagem) Considere que seus correspondentes lerão seus emails em telas com no máximo 80 colunas e configure a quebra de linha para este valor ou menos.
- No entanto, não quebre linhas de dados (como trechos de log ou transcrições de sessões). Dados devem ser incluídos como eles são, pois seus correspondentes terão certeza de estar vendo o que você viu.
- Não envie mensagens codificadas em MIME Quoted-Printable para uma lista em língua inglesa. Esta codificação é necessária quando você está enviando em uma língua que não pode ser representada pela codificação ASCII, mas muitos programas de email não a suportam. Quando isso acontece, aqueles = espalhados pelo texto atrapalham a leitura - ou podem sabotar a semântica.
- Nunca, jamais espere que hackers leiam documentos criados em aplicações proprietárias como o Microsoft Word ou Excel. Muitos hackers reagem a isso da mesma forma que você reagiria se jogassem uma montanha fedorenta de esterco de porco na sua porta. Mesmo que eles possam escalar a montanha, eles não vão querer fazer isso.
- Se você está enviando sua mensagem de uma máquina Windows, desligue os estúpidos "Smart Quotes" da Microsoft. Com isto você vai evitar espalhar lixo pelo seu email.
- Em fóruns web, não abuse dos "smiles" e das formatações HTML (quando forem permitidas). Um smile ou dois tudo bem, mas um texto colorido e cheio de carinhas fazem as pessoas pensarem que você é um retardado. Abuse de cores, fontes e smiles e você será tratado como uma adolescente cacarejando, o que não é uma boa idéia a não ser que esteja mais interessado em sexo do que em respostas. Se você está usando um programa de email com interface gráfica (como o Netscape Messenger, o MS Outlook ou semelhantes) saiba que você pode estar violando estas regras com as configurações default. Quase todos estes programas possuem a função de ver os fontes da mensagem. Dê uma olhada na pasta de mensagens enviadas e veja se você está mandando texto puro ou mensagens incrustadas de lixo.
provavelmente não tem certeza o suficiente. Isto se aplica também a páginas web e a documentação; se você encontrou um "bug" na documentação, você deve fornecer um texto para substituição e em quais páginas a correção deve ser feita. Lembre-se, existem muitos outros usuários que não estão passando pelo mesmo problema que você. Do contrário você teria notado isso lendo a documentação ou pesquisando na Web (você já fez isso, não fez ?). Isso significa que é muito provável que é você quem está fazendo algo de errado, não o software. O pessoal que escreveu o software se dedicou muito para fazer o melhor possível. Se você diz que encontrou um bug, isto significa que eles fizeram algo de errado, e você quase sempre irá ofendê-los - mesmo que você esteja certo. Não é nada diplomático gritar "bug" no assunto da mensagem. Ao escrever sua mensagem, é melhor escrever imaginando que você fez algo de errado, mesmo que intimamente você saiba que encontrou um bug. Se for mesmo um bug, você vai ouvir isso na resposta. Faça dessa maneira e os desenvolvedores irão se desculpar com você no caso de um bug, ao invés de você ter que se desculpar com eles caso você tenha bagunçado as coisas.
Curvar-se não é um substituto para fazer o dever de casa
Algumas pessoas, quando percebem que não podem ser rudes ou arrogantes são o extremo oposto, submissos e suplicantes. "Eu sei que sou um patético novato, mas...". Isto não ajuda em nada. Pior ainda quando isto é acompanhado de informações vagas sobre o problema. Não perca seu tempo, nem o nosso, com comportamento primata. Ao invés, apresente o histórico e os fatos da forma mais clara possível. Isto é bem melhor do que curvar-se. Algumas vezes os fóruns web possuem áreas específicas para novatos. Se você acha que tem uma pergunta muito elementar, se encaminhe para lá. Mas também não chegue lá se curvando.
Descreva os sintomas do seu problema, não o que você "acha"
Não ajuda em nada dizer a hackers o que você acha que está causando problema. (Se suas teorias sobre o diagnóstico fossem tão boas, você estaria pedindo ajuda?) Portanto, certifique-se de que está relatando apenas os sintomas como eles se apresentam e não sua interpretação dos fatos ou teorias. Deixe eles interpretarem e darem o diagnóstico. Se
você acha que é importante dar sua opinião, deixe isto claro e explique porque esta resposta não serve para você. Estúpido: Estou tendo erros aleatórios de SIG11 na compilação do kernel, e suspeito que alguma trilha da minha placa-mãe está quebrada. Como posso verificar isso? Inteligente: Meu K6/233 em uma placa-mãe FIC-PA2007 (chipset VIA Apollo VP2) com 256MB Corsair PC133 SDRAM está provocando erros de SIG aproximadamente 20 minutos depois de ligado durante a compilação do kernel, mas nunca antes de 20 minutos. Um reboot não afeta essa contagem de tempo, mas deixá-la desligada de noite sim. Troquei todos os pentes RAM e não ajudou. Os logs relevantes da sessão de compilação seguem abaixo. Falta traduzir: Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us.
Descreva os sintomas do seu problema em ordem cronológica
As melhores dicas do que está acontecendo quando algo dá errado estão em eventos imediatamente anteriores. Portanto, sua mensagem deve conter o que você fez e o que a máquina fez, do início ao fim. No caso de processos via linha de comando, ter um log da sessão (ex.: utilitário script) e citar as 20 principais linhas é muito útil. Se o programa que está apresentando problemas possui uma opção de diagnóstico (tipo -v para verbose), tente selecionar opções que adicionarão informações úteis de debug. Lembre-se de que mais não é necessariamente melhor. Escolha um nível de debug que irá informar ao invés de afogar o leitor em lixo.
respondendo - e, se ele assim o fizer, provavelmente é porque considerou a questão muito mal feita ou óbvia demais para ser útil aos demais participantes. Existe uma única exceção à esta regra. Se você acha que o tipo de pergunta fará com que você receba diversas respostas parecidas, então as palavras mágicas são "mandem para meu email e farei um resumo para o grupo". Isto é bem visto por tentar salvar a lista de uma avalanche de mensagens substancialmente idênticas - mas você precisa cumprir a promessa de mandar o resumo.
Seja específico com relação à sua pergunta
Perguntas vagas tendem a ser consideradas perda de tempo. As pessoas que melhor podem te dar uma resposta são, geralmente, as mais ocupadas (justamente por fazerem todo o trabalho). Pessoas assim são alérgicas à perda de tempo, e conseqüentemente as perguntas vagas. É mais provável que você consiga uma resposta sendo específico com relação ao que você espera que seus correspondentes façam (dar dicas, enviar um código, verificar seu patch etc.). Isto vai fazer com que eles concentrem seus esforços e estabeleçam um limite sobre o tempo e energia necessários para te ajudar. Isso é bom. Para entender o mundo em que os especialistas vivem, imagine que a sabedoria é um recurso abundante e o tempo é muito escasso. Quanto menos tempo for necessário para atender seu pedido, maior a chance de conseguir uma resposta de alguém realmente bom e realmente ocupado. Portanto, é melhor posicionar sua pergunta de forma que ela exija o menor tempo possível para um especialista analisar - mas isto não é mesma coisa que simplificar a questão. Por exemplo, "Você pode me mostrar onde encontro informações sobre X?" é uma pergunta mais inteligente do que "Você pode me explicar X?". Se você tem algum código que não está funcionando, é mais inteligente perguntar o que está errado nele do que pedir para que o consertem.
Não mande seus deveres de casa
Hackers são bons em descobrir perguntas feitas nos deveres de casa; muitos de nós fizemos os nossos próprios deveres. Estas questões existem para que você faça o trabalho, para que você aprenda com a sua experiência. Tudo bem pedir dicas, mas não a resposta completa.
Se você suspeita de ter enviado uma questão do seu dever de casa, mas mesmo assim não souber resolvê-la, tente perguntar em um grupo de usuários ou (como último recurso) em uma lista usuários de um projeto. Mesmo que os hackers percebam este tipo de questão, alguns usuários avançados podem pelo menos lhe dar umas dicas.
Remova as perguntas inúteis
Resista à tentação de terminar sua mensagem com perguntas semanticamente nulas, como "Alguém pode me ajudar?" ou "Existe uma resposta?". Primeiro: se você descreveu seu problema razoavelmente bem, estas questões são, na melhor das hipóteses, supérfluas. Segundo: por elas serem supérfluas, hackers as consideram irritantes - e tendem a enviar resposta logicamente impecáveis mas igualmente inúteis como "Sim, posso te ajudar" e "Não, não há ajuda aqui para você". Evite perguntas de "sim/não" a não ser que queira uma resposta do tipo " sim/não ".
Não marque sua mensagem como "Urgente", mesmo que ela o
seja para você
Isso é problema seu, não nosso. Alegar urgência é normalmente contra-producente: muitos hackers simplesmente apagarão a mensagem por causa do egoísmo na tentativa de atrair atenção especial e imediata. Existe uma "semi-exceção". Se você estiver com problemas em alguma lugar de alto- nível, onde um hacker se interessaria em ajudar; neste caso, se você estiver com o prazo sob pressão, e se você disser isso educadamente, o pessoal talvez se interesse o suficiente para acelerar a ajuda. No entanto, isto é muito arriscado, pois a métrica dos hackers sobre o que é ou não interessante provavelmente difere da sua. Mensagens vindo da Estação Espacial Internacional podem ser qualificadas como interessante, por exemplo, mas mensagens sobre caridade ou causa política quase certamente não. Vejamos, enviando "Urgente: Me ajudem a salvar a pele dos bebês focas!" fará você ser evitado ou insultado mesmo por hackers que consideram os bebês focas importantes. Se você acha isso um mistério, releia todo este documento repetidamente até entendê-lo, antes de enviar qualquer mensagem.
último, depois da solução correta e do sumário. Evite transformar sua mensagem em uma história de detetive. Dê nome as pessoas que te ajudaram; assim você fará muitos amigos. Além de ser cortês e informativo, este tipo de mensagem ajudará outras pessoas que estejam procurando no histórico da lista/grupo/fórum a conhecerem que solução foi útil para você e qual será útil para elas. Por último, mas igualmente importante, esta mensagem faz com que todos os que ajudaram se sintam satisfeitos por terem ajudado a solucionar seu problema. Se você não é um techie ou um hacker, confie em nós quando dizemos que este sentimento é importante para os gurus e experts a quem pediu ajuda. Narrativas de problemas que não levam a nenhuma solução são frustrantes; hackers se coçam até ver isto resolvido. Você acumulará uma bom karma se ajudá-los a se sentirem bem, o que será muito, mas muito importante na próxima vez que precisar de ajuda. Considere fazer com que outras pessoas não passem pelo mesmo problema que você. Se você achar que criando um patch ou um FAQ ajudará o próximo, faça-o e mande para o fabricante. Entre os hackers, este tipo de atitude é mais importante do que uma boa educação. É assim que você adquire uma reputação, o que pode ser um bem muito valioso.
Como interpretar respostas
RTFM e STFW: Como dizer que você está realmente enrolado
Existe uma antiga e sagrada tradição que diz: se você recebe uma resposta com as letras RTFM, a pessoa que as enviou acha que você precisa "ler a porra do manual" (Read The Fucking Manual). Ele deve estar certo. Vá ler o manual. RTFM tem um irmão mais novo. Se você recebe uma resposta com as letras STFW, a pessoa que as enviou acha que você precisa "procurar na porra da web" (Search The Fucking Web). Ele deve estar certo. Vá procurar na web. (Uma versão mais leve é "Google é seu amigo!") Em fóruns web, você também pode ser convidado a pesquisar nos arquivos de mensagens anteriores. De fato, alguém pode até mesmo lhe indicar o link da conversa onde seu assunto já foi discutido. Mas não dependa deste comportamento. Faça sua própria pesquisa antes de perguntar.
Muitas vezes a pessoa que te mandou ler o manual ou procurar na web está com o manual aberto na página que você precisa ler ou tem o link de onde a resposta pode ser encontrada enquanto digita sua mensagem. Estas respostas significam que ele acha que (a) a informação que você precisa é fácil de encontrar, e (b) você irá aprender mais se procurar a informação por contra própria do que se recebê-la de mão beijada. Não se sinta ofendido por causa disso; para os padrões do hacker, ele está demonstrando um certo tipo de respeito por não ignorar você. Você deve agradecê-lo por tamanha generosidade.
Se você não entender...
Se você não entender a resposta, não mande imediatamente um pedido de explicação. Use as mesmas ferramentas que você usou antes de fazer sua pergunta (manuais, FAQ, web, amigos experientes) para entender a resposta. Então, se você ainda assim precisar de explicações, demonstre que você aprendeu. Por exemplo, suponha que eu te diga: "Me parece que você ficou preso no zentry; você precisa limpá-lo." Aqui está uma péssima réplica: "O que é um zentry?" E aqui está uma boa réplica: "Ok, eu li o manual e zentries são mencionados apenas nas opções -z e -p. Nenhuma delas diz como limpar o zentry. É alguma dessas opções ou deixei passar alguma coisa?"
Lidando com grosserias
Muito do que se parece com grosserias no círculo hacker não tem o objetivo de ofender. Pelo contrário, isto é um produto de um estilo de comunicação direta, sem rodeios, que é natural em pessoas que estão mais preocupadas em resolver problemas do que fornecer carinho e afeto. Se você se sentir agredido, tente reagir calmamente. Se alguém está realmente te agredindo é mais provável que um membro sênior da lista ou do fórum acalme o atacante. Se isto não acontecer e você revidar, é provável que seu suposto agressor esteja agindo de acordo com as normas da comunidade hacker e então você será o errado na história. Isto afetará suas chances de conseguir a ajuda que procura. Por outro lado, você ocasionalmente verá agressões no grupo. Esta é uma forma aceitável de rebater os que realmente ofendem o grupo, dissecando seu comportamento de forma ríspida, como se o escalpelassem verbalmente. Entretanto, muito cuidado ao
