homeyou

Seja sensível ao escolher onde você faz sua pergunta. É provável que você seja ignorado, ou seja baixado como um perdedor, se você:

Os hackers explodem questões que são inadequadamente direcionadas para tentar proteger seus canais de comunicação de serem prejudicados de irrelevância. Você não quer que isso aconteça com você.

O primeiro passo, portanto, é encontrar o fórum certo. Novamente, o Google e outros métodos de busca na Web são o seu amigo. Use-os para encontrar a página do projeto mais associada ao hardware ou software, dando-lhe dificuldades. Geralmente, terá links para uma lista de perguntas freqüentes (Perguntas freqüentes) e para projetar listas de discussão e seus arquivos. Essas listas de endereços são os lugares finais para pedir ajuda, se seus próprios esforços (incluindo leitura as perguntas freqüentes que você encontrou) não o acham uma solução. A página do projeto também pode descrever um procedimento de relatório de erros ou ter um link para um; se assim for, siga-o.

Tirar um e-mail para uma pessoa ou fórum que você não conhece é arriscado na melhor das hipóteses. Por exemplo, não assuma que o autor de uma página informativa quer ser seu consultor gratuito. Não faça suposições otimistas sobre se sua pergunta será bem-vinda - se você não tiver certeza, envie-a para outro local ou se abstenha de enviá-la.

Ao selecionar um fórum da Web, um grupo de discussão ou uma lista de discussão, não confie no nome por si mesmo demais; procure uma FAQ ou uma carta patente para verificar se a sua pergunta está no tópico. Leia o tráfego de volta antes de publicar para que você tenha uma idéia de como as coisas são feitas lá. Na verdade, é uma boa idéia fazer uma pesquisa por palavra-chave sobre palavras relacionadas ao seu problema nos arquivos da lista de discussão ou da lista de e-mails antes de publicar. Pode encontrar uma resposta, e se não, isso irá ajudá-lo a formular uma pergunta melhor.

Não espagueie todos os canais de ajuda disponíveis ao mesmo tempo, é como gritar e irritar as pessoas. Passa por eles suavemente.

Saiba qual é seu tema! Um dos erros clássicos é fazer perguntas sobre a interface de programação Unix ou Windows em um fórum dedicado a uma linguagem ou biblioteca ou ferramenta portátil em ambos. Se você não entende por que isso é um erro, você seria melhor não fazer perguntas até que você entenda.

Em geral, as perguntas para um fórum público bem selecionado são mais propensas a obter respostas úteis do que questões equivalentes a uma questão privada. Há várias razões para isso. Um é simplesmente o tamanho do grupo de potenciais entrevistados. Outro é o tamanho da audiência; Os hackers preferem responder a perguntas que educam muitas pessoas do que questões que servem apenas alguns.

Compreensivelmente, hackers qualificados e autores de software popular já estão recebendo mais do que sua parcela justa de mensagens mal direcionadas. Ao adicionar à inundação, você poderia, em casos extremos, mesmo ser a palha que quebra as costas do camelo - algumas vezes, contribuintes para projetos populares retiraram seu apoio porque danos colaterais na forma de tráfego de e-mail inútil para suas contas pessoais tornou-se insuportável.

Pesquise, então pergunte em Stack Exchange

Nos últimos anos, a comunidade de sites da Stack Exchange surgiu como um recurso importante para responder questões técnicas e outras e é mesmo o fórum preferido para muitos projetos de código aberto.

Comece com uma pesquisa do Google antes de examinar o Stack Exchange; O Google indexa isso em tempo real. Há uma boa chance de alguém já ter feito uma pergunta semelhante, e os sites do Stack Exchange estão freqüentemente perto do topo dos resultados da pesquisa. Se você não encontrou nada no Google, procure novamente no site específico mais relevante para sua pergunta (veja abaixo). Procurar com tags pode ajudar a reduzir os resultados.

Se você ainda não encontrou nada, publique sua pergunta sobre o unico site onde é mais tópico. Use as ferramentas de formatação, especialmente para código, e adicione tags relacionadas à substância de sua pergunta (particularmente o nome da linguagem de programação, sistema operacional ou biblioteca com o qual você está tendo problemas). Se um comentarista solicitar mais informações, edite sua postagem principal para incluí-la. Se qualquer resposta for útil, clique na seta para cima para cobrir isso; se uma resposta fornecer uma solução para seu problema, clique no cheque sob as setas de votação para aceitá-lo como correto.

Stack Exchange cresceu mais de 100 sites, mas aqui estão os candidatos mais prováveis:

Vários projetos têm seus próprios sites específicos, incluindo Android, Ubuntu, TeX / LaTeX e SharePoint. Verifique o site do Stack Exchange para obter uma lista atualizada.

O seu grupo de usuários local ou a sua distribuição no Linux podem anunciar um fórum da Web ou um canal IRC onde iniciantes podem obter ajuda. (Em países que não são de língua inglesa, os fóruns de novatos ainda são mais propensos a serem listas de correspondência.) São bons primeiros lugares para perguntar, especialmente se você acha que pode ter tropeçado por um problema relativamente simples ou comum. Um canal IRC anunciado é um convite aberto para fazer perguntas e muitas vezes obter respostas em tempo real.

Na verdade, se você obteve o programa que está lhe dando problemas de uma distribuição Linux (como é comum hoje), talvez seja melhor perguntar no fórum / lista do distro antes de tentar o fórum / lista de projetos do programa. Os hackers do projeto podem simplesmente dizer, “use nossa build”.

Antes de publicar em qualquer fórum da Web, verifique se ele possui um recurso de pesquisa. Se o fizer, experimente algumas pesquisas de palavras-chave para algo como seu problema; só pode ajudar. Se você fez uma busca geral na Web antes (como deveria), procure no fórum de qualquer maneira; seu mecanismo de busca na Web pode não ter todo esse fórum indexado recentemente.

Existe uma tendência crescente de projetos para fazer suporte ao usuário em um fórum da Web ou no canal IRC, com o e-mail reservado mais para o tráfego de desenvolvimento. Então procure esses canais primeiro ao procurar ajuda específica do projeto.

No IRC, provavelmente é melhor não despejar uma descrição do problema longo na primeira coisa do canal; Algumas pessoas interpretam isso como inundações de canais. O melhor para pronunciar uma descrição do problema de uma linha de uma maneira lançada para iniciar uma conversa no canal.

Quando um projeto possui uma lista de endereços de desenvolvimento, escreva para a lista de discussão, não para desenvolvedores individuais, mesmo que acredite que sabe quem pode responder melhor a sua pergunta. Verifique a documentação do projeto e sua página inicial para o endereço de uma lista de discussão do projeto e use-a. Existem várias boas razões para esta política:

Se um projeto tiver um “usuario” e um “desenvolvedor” (ou “hacker”) lista de discussão ou fórum da Web, e você não está pirateando o código, pergunte no “usuario” lista / fórum. Não assuma que você será bem-vindo na lista de desenvolvedores, onde é provável que experimente sua pergunta como o ruído que interrompe o tráfego do seu desenvolvedor.

No entanto, se você esta certo sua pergunta não é trivial e você não obteve nenhuma resposta no “usuario” lista / fórum por vários dias, experimente o do “desenvolvedor”. Você seria aconselhável espreitar por alguns dias ou, pelo menos, rever os últimos dias de mensagens arquivadas, aprender os folkways locais antes de publicar (na verdade, este é um bom conselho em qualquer lista privada ou semi-privada).

Se você não consegue encontrar o endereço da lista de correspondência de um projeto, mas veja apenas o endereço do mantenedor do projeto, vá em frente e escreva para o mantenedor. Mas mesmo nesse caso, não assuma que a lista de endereços não existe. Mencionar em seu e-mail que você tentou e não encontrou a lista de correspondência apropriada. Também mencione que você não se opõe a que sua mensagem seja encaminhada para outras pessoas. (Muitas pessoas acreditam que o e-mail privado deve permanecer privado, mesmo que não haja nada de segredo nele. Ao permitir que sua mensagem seja encaminhada, você dá ao seu correspondente uma escolha sobre como lidar com seu e-mail.)

Em listas de discussão, grupos de notícias ou fóruns da Web, o cabeçalho do assunto é a sua oportunidade de ouro para atrair a atenção dos especialistas qualificados em cerca de 50 caracteres ou menos. Não desperdice isso em balbuciar como “Por favor me ajude” (muito menos “POR FAVOR ME AJUDE!!!!”; mensagens com assuntos como esse são descartadas por reflexos). Não tente nos impressionar com a profundidade da sua angústia; use o espaço para uma descrição de problema super-conciso em seu lugar.

Uma boa convenção para cabeçalhos de assunto, usada por muitas organizações de suporte técnico, é “desvio de objeto”. A parte do “objeto” especifica que coisa ou grupo de coisas está tendo um problema, e o “desvio” parte descreve o desvio do comportamento esperado.

O processo de escrever um “desvio-de-objeto” a descrição o ajudará a organizar seu pensamento sobre o problema com mais detalhes. O que é afetado? Apenas o cursor do mouse ou outros gráficos também? Isso é específico para a versão X.org do X? Para a versão 6.8.1? Isso é específico para chipsets de vídeo Fooware? Para modelar MV1005? Um hacker que vê o resultado pode entender imediatamente o que é que você está tendo um problema com e o problema que você está tendo, de relance.

De forma mais geral, imagine olhar para o índice de um arquivo de perguntas, com apenas as linhas de assunto mostradas. Faça a sua linha de assunto refletir sua pergunta bem o suficiente para que a próxima pessoa que procura o arquivo com uma pergunta semelhante à sua poderá seguir o tópico para uma resposta em vez de postar a pergunta novamente.

Se você fizer uma pergunta em uma resposta, certifique-se de mudar a linha de assunto para indicar que está fazendo uma pergunta. Uma linha de assunto que parece “Re: teste” ou “Re: novo erro” é menos provável atrair quantidades úteis de atenção. Além disso, separe a citação de mensagens anteriores ao mínimo, consistente com a clonagem em novos leitores.

Não basta acertar a resposta a uma mensagem da lista para iniciar um tópico completamente novo. Isso limitará seu público. Alguns leitores de correio, como mutt, permitem ao usuário classificar por segmento e, em seguida, ocultar mensagens em um segmento dobrando o segmento. Pessoas que fazem isso nunca verão sua mensagem.

Alterar o assunto não é suficiente. Mutt, e provavelmente outros leitores de correio, olha outras informações nos cabeçalhos do e-mail para atribuí-lo a um tópico, não à linha de assunto. Em vez disso, comece um e-mail totalmente novo.

Nos fóruns da Web, as regras de boas práticas são ligeiramente diferentes, porque as mensagens geralmente estão muito mais ligadas a discussões de discussão específicas e muitas vezes invisíveis fora desses tópicos. Alterar o assunto ao fazer uma pergunta em resposta não é essencial. Nem todos os fóruns nem permitem linhas de assunto separadas em respostas, e quase ninguém lê-los quando o fazem. No entanto, fazer uma pergunta em uma resposta é uma prática duvidosa em si, porque só será visto por aqueles que estão assistindo esse tópico. Então, a menos que você tenha certeza de você queira perguntar apenas as pessoas atualmente ativas no tópico, começar uma nova.

Finalizando sua consulta com “Envie sua resposta para... ” torna bastante improvável que você obtenha uma resposta. Se você não pode ser incomodado para levar até os poucos segundos necessários para configurar um cabeçalho de resposta correto no seu agente de e-mail, não podemos incomodar levar alguns segundos para pensar sobre seu problema. Se o seu programa de correio não permitir isso, obter um melhor programa de correio. Se o seu sistema operacional não suportar nenhum programa de e-mail que permita isso, obtenha um sistema operacional melhor.

Nos fóruns da Web, pedir uma resposta por e-mail é grosseiro, a menos que você acredite que a informação pode ser sensível (e alguém, por algum motivo desconhecido, deixá-lo, mas não o todo o fórum, conhece). Se você quer uma cópia de e-mail quando alguém responde no tópico, solicite que o fórum da Web o envie; Esse recurso é suportado em quase todos os lugares sob opções como “assista a este tópico”, “envie e-mail às respostas”, etc.

Descobrimos, por experiência, que as pessoas que são escritores descuidados e desleixados geralmente são descuidadas e descuidadas em pensar e codificar (muitas vezes o suficiente para apostar, de qualquer maneira). Responder a perguntas para pensadores descuidados e descuidados não é gratificante; preferimos gastar nosso tempo em outros lugares.

Então, expressar sua pergunta com clareza e bem é importante. Se você não pode ser incomodado para fazer isso, não podemos incomodar-nos a prestar atenção. Gaste o esforço extra para polir seu idioma. Não precisa ser rígido ou formal - na verdade, os valores de cultura de hackers são informados, slangy e linguagem humorística usada com precisão. Mas é preciso ser preciso; tem que haver alguma indicação de que você está pensando e está prestando atenção.

Soletre, pontuar e capitalizar corretamente. Não confunda “its” com “it's”, “loose” com “lose”, ou “discrete” com “discreet”. Não TENTE EM TODOS OS CAPS; isso é lido como gritando e considerado grosseiro. (All-smalls é apenas um pouco menos irritante, pois é difícil de ler. Alan Cox pode fugir com isso, mas você não pode.)

De forma mais geral, se você escrever como um boob semi-alfabetizado, você provavelmente será ignorado. Portanto, não use atalhos de mensagens instantâneas. Ortografia "você" como "você" faz com que você pareça um boob semi-alfabetizado para salvar duas batidas de teclas inteiras. Pior: escrever como um roteiro l33t kiddie hax0r é o beijo absoluto da morte e garante que você não receberá nada além de silêncio pedregoso (ou, na melhor das hipóteses, uma ajuda tremenda de desprezo e sarcasmo) em troca.

Se você está fazendo perguntas em um fórum que não usa seu idioma nativo, você receberá uma quantidade limitada de erros de ortografia e gramática - mas não há folga extra por preguiça (e sim, geralmente podemos detectar essa diferença). Além disso, a menos que você saiba quais são os idiomas do seu respondente, escreva em inglês. Os hackers ocupados tendem a simplesmente resolver perguntas em línguas que não entendem, e o inglês é o idioma de trabalho da Internet. Ao escrever em inglês, você minimiza as chances de sua pergunta ser descartada sem ler.

Se você está escrevendo em inglês, mas é um segundo idioma para você, é uma boa forma de alertar potenciais entrevistados para possíveis dificuldades de linguagem e opções para contorná-los. Exemplos:

Se você faz sua pergunta artificialmente difícil de ler, é mais provável que seja passado em favor de uma que não é. assim:

Se você estiver usando um cliente de correio de interface gráfica e de usuário, como o Netscape Messenger, o MS Outlook ou o seu ilk, tenha cuidado para que possa violar essas regras quando usado com suas configurações padrão. A maioria desses clientes tem um menu baseado “View Source” comando. Use isso em algo na sua pasta de email enviada, verificando o envio de texto sem texto livre.

Faça o melhor que puder para antecipar as perguntas que um hacker perguntará e respondê-las antecipadamente no seu pedido de ajuda.

Dar aos hackers a capacidade de reproduzir o problema em um ambiente controlado é especialmente importante se você estiver relatando algo que você acha que é um erro no código. Quando você faz isso, suas chances de obter uma resposta útil e a velocidade com que você provavelmente receberá essa resposta melhorará enormemente.

Simon Tatham escreveu um excelente ensaio intitulado Como informar erros de forma eficaz. Eu recomendo que você leia.

Você precisa ser preciso e informativo. Este fim não é servido simplesmente despejando grandes volumes de código ou dados em uma solicitação de ajuda. Se você tiver um caso de teste grande e complicado que esteja quebrando um programa, tente cortá-lo e torná-lo o mais pequeno possível.

Isso é útil por pelo menos três razões. Um: ser visto para investir esforços na simplificação da questão, torna mais provável que você obtenha uma resposta, Dois: simplificar a questão torna mais provável que você obtenha uma reposta util. Três: no processo de refinação do relatório de erros, você pode desenvolver uma solução ou solução alternativa.

Quando você está tendo problemas com um pedaço de software, não reivindique que você encontrou um erro a menos que você seja muito, muito com certeza do seu terreno. Dica: a menos que você possa fornecer um patch de código-fonte que corrija o problema ou um teste de regressão contra uma versão anterior que demonstre um comportamento incorreto, provavelmente você não tem certeza do suficiente. Isso se aplica às páginas da web e à documentação também; se você encontrou uma documentação “bug”, você deve fornecer o texto de substituição e quais páginas deve continuar.

Lembre-se, há muitos outros usuários que não estão enfrentando seu problema. Caso contrário, você teria aprendido sobre isso ao ler a documentação e pesquisar na Web (você fez isso antes de reclamar, não foi você?). Isso significa que muito provavelmente é você quem está fazendo algo errado, não o software.

As pessoas que escreveram o software trabalham muito para fazê-lo funcionar o melhor possível. Se você alega que encontrou um bug, você estará impugnando sua competência, o que pode ofendê-los, mesmo que esteja correto. É especialmente desordenado gritar “bug” na linha de assunto.

Ao fazer sua pergunta, é melhor escrever como se você assumisse vocês estão fazendo algo errado, mesmo que você tenha certeza de que você encontrou um erro real. Se houver um bug, você ouvirá sobre isso na resposta. Jogue para que os mantenedores desejem se desculpar com você se o bug for real, e não para que você os devesse pedir desculpas se você esgrimisse.

Algumas pessoas que percebem que não deveriam se comportar rudemente ou arrogantemente, exigindo uma resposta, recuem para o extremo oposto de rastejar. “Eu sei que sou apenas um perdedor patético do novato, mas...”. Isso é uma distração e inútil. É especialmente irritante quando é acompanhada de imprecisão sobre o problema real.

Não desperdice seu tempo, nem o nosso, na política de primatas em bruto. Em vez disso, apresente os fatos de fundo e sua pergunta o mais claramente possível. Essa é uma maneira melhor de posicionar-se do que rastejar.

Às vezes, os fóruns da Web têm lugares separados para questões de iniciantes. Se você sentir que tem uma questão de novato, vá lá. Mas não se agache lá também.

Não é útil dizer aos hackers o que você acha que está causando seu problema. (Se suas teorias de diagnóstico fossem coisas tão gostosas, você estaria consultando os outros para obter ajuda?) Então, certifique-se de que está dizendo-lhes os sintomas crus do que dá errado, ao invés de suas interpretações e teorias. Deixe-os fazer a interpretação e o diagnóstico. Se você achar que é importante declarar o seu palpite, rotulá-lo como tal e descreva por que essa resposta não está funcionando para você.

Uma vez que o ponto anterior parece ser difícil para muitas pessoas entender, aqui está uma frase para lembrá-lo: "Todos os diagnósticos são do Missouri". O lema oficial do estado dos EUA é "Show me" (ganhou em 1899, quando o deputado Willard D. Vandiver disse: "Eu venho de um país que levanta milho e algodão e gambáceas e democratas, e a eloquência espumosa não me convence nem me satisfaz. do Missouri. Você deve me mostrar. ") No caso dos diagnósticos, não é uma questão de ceticismo, mas sim uma necessidade literal e funcional de ver o que for o mais próximo possível da mesma evidência bruta que você vê, em vez disso do que suas surpresas e resumos. Mostre-nos.

As pistas mais úteis para descobrir algo que deu errado geralmente se encontram nos eventos imediatamente anteriores. Então, sua conta deve descrever exatamente o que você fez, e o que a máquina e o software fizeram, levando à explosão. No caso de processos de linha de comando, ter um registro de sessão (por exemplo, usar o utilitário de script) e citar as vinte e duas linhas relevantes é muito útil.

Se o programa que explodiu em você tenha opções de diagnóstico (como -v para verbose), tente selecionar opções que irão adicionar informações de depuração úteis à transcrição. Lembre-se de que mais não é necessariamente melhor; tente escolher um nível de depuração que informará ao invés de afogar o leitor em lixo.

Se a sua conta acabar sendo longa (mais do que cerca de quatro parágrafos), pode ser útil divulgar sucintamente o problema em cima, depois seguir com o conto cronológico. Dessa forma, os hackers saberão o que procurar na leitura de sua conta.

Se você está tentando descobrir como fazer algo (em oposição a relatando um bug), comece por descrever o objetivo. Só então descreve O passo particular em direção a isso que você está bloqueado.

Muitas vezes, as pessoas que precisam de ajuda técnica têm um objetivo de alto nível em mente e ficam presas no que eles pensam ser um caminho particular em direção ao objetivo. Eles vêm para ajudar com o passo, mas não percebem que o caminho está errado. Pode levar um esforço substancial para superar isso.

A segunda versão da pergunta é inteligente. Permite uma resposta que sugere uma ferramenta mais adequada à tarefa.

Os hackers acreditam que resolver problemas devem ser um processo público e transparente durante o qual uma primeira tentativa de resposta pode e deve ser corrigida se alguém mais experiente perceber que está incompleto ou incorreto. Além disso, os ajudantes recebem uma parte da recompensa deles por serem entrevistados serem competentes e conhecedores pelos seus pares.

Quando você pede uma resposta privada, você está interrompendo o processo e a recompensa. Não faça isso. É o respondente escolha de responder em particular - e se ele ou ela faz, geralmente é porque ele ou ela acha que a questão está muito mal formada ou óbvia para ser interessante para os outros.

Existe uma exceção limitada a esta regra. Se você acha que a questão é tal que você provavelmente receberá muitas respostas que são muito parecidas, então as palavras mágicas são “envie-me um e-mail e resumirei as respostas para o grupo”. É cortês tentar salvar a lista de discussão ou o grupo de notícias de um fluxo de postagens substancialmente idênticas - mas você deve manter a promessa de resumir.

As perguntas abertas tendem a ser percebidas como sumidouros de tempo aberto. As pessoas que provavelmente poderão dar uma resposta útil também são as pessoas mais movimentadas (se apenas porque assumem a maior parte do trabalho). Pessoas assim são alérgicas a fendas de tempo abertas, por isso elas tendem a ser alérgicas a questões abertas.

Você é mais provável que obtenha uma resposta útil se você for explícito sobre o que deseja que os inquiridos façam (forneça ponteiros, envie um código, verifique seu patch, seja o que for). Isso focará seu esforço e implicitamente colocará um limite superior no tempo e na energia que o entrevistado deve alocar para ajudá-lo. Isso é bom.

Para entender o mundo em que os especialistas vivem, pense na experiência como um recurso abundante e tempo para responder como escasso. Quanto menos tempo você pedir implícito, mais provável é que você receba uma resposta de alguém realmente bom e realmente ocupado.

Portanto, é útil enquadrar sua pergunta para minimizar o compromisso de tempo exigido para um especialista para enquadrá-lo - mas isso geralmente não é o mesmo que simplificar a questão. Assim, por exemplo, “Você me daria um indicador para uma boa explicação de X?” geralmente é uma questão mais inteligente do que “Você explicaria X, por favor?”. Se você tem algum código defeituoso, geralmente é mais esperto pedir a alguém para explicar o que há de errado do que é pedir a alguém para corrigi-lo.

Não peça a outros que depenhem seu código quebrado, sem dar uma indicação sobre o tipo de problema que devem estar procurando. Publicar algumas centenas de linhas de código, dizendo "isso não funciona", você será ignorado. Publicando uma dúzia de linhas de código, dizendo "depois da linha 7 eu esperava ver <x>, mas <y> ocorreu em vez disso "é muito mais provável que você obtenha uma resposta.

A maneira mais eficaz de ser preciso sobre um problema de código é fornecer um caso de teste mínimo de demonstração de erros. Qual é um caso de teste mínimo? É uma ilustração do problema; Apenas código suficiente para exibir o comportamento indesejável e não mais. Como você faz um caso de teste mínimo? Se você sabe que linha ou seção de código está produzindo o comportamento problemático, faça uma cópia dele e adicione apenas o código de apoio suficiente para produzir um exemplo completo (ou seja, o suficiente para que a fonte seja aceitável para o compilador / intérprete / qualquer aplicativo que o processe) . Se você não pode restringi-lo a uma seção específica, faça uma cópia da fonte e comece a remover pedaços que não afetem o comportamento problemático. Quanto menor for o seu caso mínimo de teste, melhor (veja a seção chamada "Volume não é precisão").

Gerar um caso de teste mínimo muito pequeno nem sempre será possível, mas tentar ser uma boa disciplina. Pode ajudá-lo a aprender o que você precisa para resolver o problema por conta própria - e mesmo quando não, os hackers gostam de ver que você tentou. Isso os tornará mais cooperativos.

Se você simplesmente quer uma revisão de código, diga o máximo da frente e não deixe de mencionar quais áreas você acha que podem ser particularmente necessárias e porque.

Os hackers são bons em detectar questões de lição de casa; A maioria de nós os fez nós mesmos. Essas questões são para você para trabalhar, para que você aprenda com a experiência. É bom pedir sugestões, mas não para soluções inteiras.

Se você suspeita de ter passado uma questão de lição de casa, mas não pode resolvê-la de qualquer maneira, tente perguntar em um fórum de grupo de usuários ou (como último recurso) em um “usuario” lista / fórum de um projeto. Enquanto os hackers vao note-o, alguns dos usuários avançados podem, pelo menos, dar uma sugestão.

Resista à tentação de fechar seu pedido de ajuda com perguntas semânticas como nulas, como “Alguém pode me ajudar?” ou “Existe uma resposta?” Primeiro: se você escreveu sua descrição do problema com meios com competência, essas questões colocadas são, na melhor das hipóteses, supérfluas. Em segundo lugar: porque são supérfluos, os hackers os acham irritantes - e provavelmente retornarão respostas logicamente impecáveis, mas desdenhosas, como “Sim, você pode ser ajudado” e “Não, não há ajuda para você.”

Em geral, fazer perguntas sim-ou-não é uma coisa boa a evitar, a menos que você queira resposta sim-ou-não.

Esse é o seu problema, não o nosso. Reivindicar urgência é muito provável ser contraproducente: a maioria dos hackers simplesmente apagará mensagens como tentativas rudes e egoístas de obter atenção imediata e especial. Além disso, a palavra "Urgente" (e outras tentativas similares para chamar a atenção na linha de assunto) geralmente desencadeia filtros de spam - seus destinatários podem nunca vê-lo!

Existe uma semi-exceção. Vale a pena mencionar se você está usando o programa em algum lugar de alto perfil, um dos quais os hackers se excitarão; nesse caso, se você estiver sob pressão do tempo, e você diz isso educadamente, as pessoas podem se interessar o suficiente para responder mais rapidamente.

Esta é uma coisa muito arriscada, no entanto, porque a métrica dos hackers para o que é excitante provavelmente difere da sua. O lançamento da Estação Espacial Internacional qualificaria, por exemplo, mas publicar em nome de uma causa caritativa ou política de boa vontade quase certamente não. De fato, postando “Urgente: ajude-me a salvar as focas fuzzy!” irá confiavelmente obtê-lo evitado ou inflamado, mesmo por hackers que pensam que os focos fuzzy são importantes.

Se você achar isso misterioso, leia novamente o restante deste modo até que você o compreenda antes de publicar qualquer coisa.

Seja gentil. Use “Por favor” e “Obrigado pela sua atenção” ou “Obrigado pela sua consideração”. Deixe claro que você aprecia o tempo que as pessoas gastam ajudando você de graça.

Para ser honesto, isso não é tão importante quanto (e não pode substituir) sendo gramatical, claro, preciso e descritivo, evitando formatos proprietários, etc .; Os hackers em geral preferem obter relatórios de bugs um tanto bruscos mas tecnicamente afiados do que a imprecisão educada. (Se isso o enrola, lembre-se de que valorizamos uma pergunta pelo que nos ensina.)

No entanto, se você tem seus patos técnicos seguidos, a cortesia aumenta suas chances de obter uma resposta útil.

(Devemos notar que a única objeção séria que recebemos de hackers veteranos para este HOWTO é em relação à nossa recomendação anterior de usar “Desde já, obrigado”. Alguns hackers sentem isso significar uma intenção de não agradecer a ninguém mais tarde. Nossa recomendação é dizer “Desde já, obrigado” primeiro e Alguns hackers sentem isso significar uma intenção de não agradecer a ninguém mais tarde. Nossa recomendação é dizer “Obrigado pela sua atenção” ou “Obrigado pela sua consideração”.)

Envie uma nota após o problema ter sido resolvido para todos os que o ajudaram; deixe-os saber como ele saiu e agradeça-os novamente por sua ajuda. Se o problema atraiu interesse geral em uma lista de discussão ou grupo de notícias, é apropriado publicar o acompanhamento lá.

Otimamente, a resposta deve ser o tópico iniciado pela postagem de pergunta original e deve ter 'FIXED', 'RESOLVED' ou uma tag igualmente óbvia na linha de assunto. Nas listas de correspondência com rápida reviravolta, um potencial entrevistado que vê um tópico sobre “Problema X” terminando com “Problema X - FIXED” não sabe perder o tempo dele mesmo lendo o tópico (a menos que ele pessoalmente encontre o Problema X interessante) e, portanto, pode usar esse tempo resolvendo um problema diferente.

Seu acompanhamento não precisa ser longo e envolvido; um simples “Howdy - foi um cabo de rede com falha! Obrigado a todos. - Conta” seria melhor do que nada. Na verdade, um resumo curto e doce é melhor do que uma longa dissertação, a menos que a solução tenha uma profundidade técnica real. Diga que ação resolveu o problema, mas você não precisa reproduzir toda a seqüência de solução de problemas.

Para problemas com alguma profundidade, é apropriado publicar um resumo do histórico de solução de problemas. Descreva a sua declaração final do problema. Descreva o que funcionou como uma solução e indique becos invisíveis evitáveis depois disso. Os becos cegos devem vir após a solução correta e outro material de resumo, em vez de transformar o seguimento em uma história de detetive. Nomeie os nomes das pessoas que o ajudaram; você fará amigos dessa forma.

Além de ser corteses e informativos, esse tipo de acompanhamento ajudará os outros pesquisando o arquivo da lista de discussão / newsgroup / forum para saber exatamente qual solução o ajudou e, assim, também pode ajudá-los.

Por último, e não menos importante, esse tipo de acompanhamento ajuda todos os que ajudaram a sentir uma sensação satisfatória de fechamento sobre o problema. Se você não é um techie ou hacker você mesmo, confie em nós que esse sentimento é muito importante para os gurus e especialistas que você aproveitou para ajudar. As narrativas problemáticas que se encaminham para o nada resolvido são coisas frustrantes; Os hackers comichão para vê-los resolvidos. A boa vontade que coçar essa coceira ganha você será muito, muito útil para você na próxima vez que você precisa fazer uma pergunta.

Considere como você poderá evitar que outros tenham o mesmo problema no futuro. Pergunte a si mesmo se uma documentação ou um patch de FAQ ajudariam, e se a resposta for sim, envie esse patch para o mantenedor.

Entre os hackers, esse tipo de bom comportamento de acompanhamento é realmente mais importante do que a cortesia convencional. É como você ganha reputação de jogar bem com os outros, o que pode ser um bem muito valioso.

Existe uma tradição antiga e sagrada: se você receber uma resposta que lê “RTFM”, A pessoa que o enviou pensa que você deveria ter Leia The Fucking Manual. Ele ou ela quase certamente está certo. Vá lê-lo.

RTFM tem um parente mais novo. Se você receber uma resposta que lê “STFW”, A pessoa que o enviou pensa que deveria ter procurado The Fucking Web. Ele ou ela quase certamente está certo. Vá procurá-lo. (A versão mais suave disso é quando você é informado “Google é seu amigo!”)

Nos fóruns da Web, você também pode ser informado para pesquisar os arquivos do fórum. Na verdade, alguém pode ser tão gentil quanto fornecer um ponteiro para o tópico anterior onde este problema foi resolvido. Mas não confie nessa consideração; faça o seu arquivo de pesquisa antes de perguntar.

Muitas vezes, a pessoa que lhe diz para fazer uma pesquisa tem o manual ou a página da web com as informações que você precisa abrir e está olhando como ele ou ela digita. Essas respostas significam que o respondente pensa (a) que as informações que você precisa são fáceis de encontrar, e (b) você aprenderá mais se você procurar a informação do que se você a colherasse.

Você não deve se ofender com isso; por padrões de hackers, seu respondente está mostrando um tipo de respeito áspero simplesmente por não ignorá-lo. Você deve, em vez disso, ser grato por essa gentileza grandiosa.

Se você não entender a resposta, não recuse imediatamente uma demanda de esclarecimentos. Use as mesmas ferramentas que você usou para tentar responder sua pergunta original (manuais, FAQs, Web, amigos habilidosos) para entender a resposta. Então, se você ainda precisa pedir esclarecimentos, exiba o que aprendeu.

Por exemplo, suponha que eu lhe diga: “Parece que você tem um zentry preso; você precisará limpá-lo.” Então: aqui está um ma questão a seguir: “O que é um zentry?” Aqui está uma boa questão a seguir: “OK, eu leio a página do manual e os zentros são mencionados somente nas opções -z e -p. Nenhum deles diz nada sobre limpar zentrias. É um desses ou estou faltando alguma coisa aqui?”

Muito do que parece uma descrédita nos círculos de hackers não se destina a ofender. Em vez disso, é o produto do estilo de comunicação direto, cortante e de besteira que é natural para as pessoas que estão mais preocupadas em resolver problemas do que fazer com que os outros se sintam quentes e confusos.

Quando você percebe a grosseria, tente reagir com calma. Se alguém está realmente agindo, é muito provável que uma pessoa seniores na lista ou grupo de notícias ou fórum o ligue. Se isso não faz acontecer e perder o seu temperamento, é provável que a pessoa em que você o perdeu se comportasse de acordo com as normas da comunidade hacker e você será considerado culpado. Isso prejudicará suas chances de obter as informações ou ajudá-lo a querer.

Por outro lado, você ocasionalmente corre por falta de rigor e postura que é bastante gratuita. O flip-side do acima é que é uma forma aceitável para abater os criminosos reais bastante difícil, dissecando o seu mau comportamento com um bisturi verbal afiado. Seja muito, muito certo do seu terreno antes de tentar isso, no entanto. A linha entre corrigir uma incivilidade e começar uma flama flamejante sem sentido é suficientemente fina para que os hackers não se infrinjam raramente por ela; Se você é um novato ou um estranho, suas chances de evitar esse erro são baixas. Se você for depois de informações e não de entretenimento, é melhor manter seus dedos fora do teclado do que arriscar isso.

(Algumas pessoas afirmam que muitos hackers têm uma forma leve de autismo ou síndrome de Asperger e são na verdade, faltam alguns dos circuitos do cérebro que lubrifica “normal” interação social humana. Isso pode ser verdadeiro ou não. Se você não é um hacker, pode ajudá-lo a lidar com nossas excentricidades se você pensa em nós como sendo danificado pelo cérebro. Vá em frente. Não nos importaremos; nós gostamos de ser seja lá o que for, e geralmente tem um ceticismo saudável sobre os rótulos clínicos.)

As observações de Jeff Bigler sobre filtros de tato também são relevantes e valem a pena ler.

Na próxima seção, falaremos sobre uma questão diferente; o tipo de “grosseria” você verá quando você comportar-se mal.