[ÍNDICE]

[0.0] Consultas
[1.0] Introdução
[1.2] Listas
[2.0] Procedimentos
[2.1] Aplicados ao canal
[2.2] Aplicados aos Usuários
[2.3] Aplicados aos Colaboradores
[3.0] Sistema de Classes
[4.0] Projetos
[4.1] Resoluções
[5.0] Histórico
[5.1] Licenças

[0.0] Novidades

Estas são as novidades desta versão:

v0.83: Retirado o o formulário 1FOR.
v0.83: Nova mensagem do procediment 1US.
v0.83: Nova mensagem do procediment 3US.
v0.83: Novo evento do procedimento 6US.
v0.83: Nova mensagem do procediment 5CO.
v0.83: Novo período de expiração para Classe A de BANs no item 3.0.
v0.83: Retirado item 3.1.
v0.83: Corrigido erro de edição do projeto 4PRO.
v0.83: Novos procedimentos 11US e 12US.
v0.83: Versão finalizada em 23/02/2004às 18:09 com 118kb.

[1.0] Introdução

Ao me tornar operador do #Ajuda, assumi a responsabilidade de fazer o (im)possível para garantir o melhor atendimento no canal. Para isso, sigo alguns procedimentos em algumas situações em prol do #Ajuda. Muitos destes procedimentos podem parecer extremos (e no fundo não são), ou alguns usuários egoístas são incapazes de enxergar a necessidade deles e acabam se sentindo abusados. Para evitar isto, estou publicando meus procedimentos (que eu já anunciei algumas vezes internamente no #Ajuda) por dois motivos: evitar que achem que minhas ações são arbitrárias demais e assumir o compromisso público de proceder como aqui descrito.

Além disto, como não sou dono da razão, este documento pretende tornar de conhecimento público minhas idéias e procedimentos para que sejam comentados, discutidos, sugeridos e utilizados por quem interessar. Ressalto que nenhum destes procedimentos constam nas regras oficiais do canal #Ajuda e muito menos são de uso obrigatório. Porém estão a disposição daqueles que estão interessados em se empenhar e se comprometer com a qualidade do atendimento do canal.

Não é pretensão minha prever tudo que pode acontecer no canal e aplicar um procedimento previsto a todas as situações. Obviamente existem eventos não listados nesses procedimentos que podem ocorrer e mesmo para os eventos listados, novas ações e diferentes tolerâncias também são possíveis. Portanto interprete mais este IPPK como uma diretriz do que como algo que limite minhas ações e procedimentos ao que está aqui descrito.

Se você foi penalizado em um dos procedimentos abaixo e discorda disso, o #Ajuda possui uma Ouvidoria para atender estes casos. Fornecendo o LOG e todas as explicações possíveis sobre o assunto, entre em contato com ouvidoria@brasnet.org

Caso tenha alguma dúvida, sugestão ou qualquer tipo de contato sobre este IPPK, kurtkraut@brasnet.org e será um prazer respondê-lo.

Notas:

• Os procedimentos anti-spam e anti-roubo de registros não serão aqui detalhados por motivos de segurança.
• Este documento por estar na versão inferior a 1.0 está inacabado, faltando alguns itens do índice e ainda contendo alguns erros.

[1.2] Listas

O IPPK oferece dois tipos de lista: o ippk-espelho e ippk-atualizacoes. Confira as descrições abaixo:

ippk-espelho: destina-se ao recebimento da versão atual do IPPK via e-mail. Para isso basta enviar um e-mail para ippk-espelho-subscribe@yahoogrupos.com.br. Você receberá um e-mail de confirmação, pedindo para que acesse uma página da Yahoo!. Após confirmada sua inscrição, a atual versão do IPPK é enviada automaticamente por e-mail. O IPPK será enviado a cada duas semanas. Uma vez inscrito, para receber mais uma vez o IPPK basta descadastrar-se da lista pelo e-mail ippk-espelho-unsubscribe@yahoogrupos.com.br. Ou seja, cada ingresso/egresso o IPPK será enviado, permitindo assim a consulta por e-mail a qualquer momento.

ippk-atualizacoes: destina-se ao recebimento de atualizações do site http://ippk.kurtkraut.cjb.net. Para ingresso, envie um e-mail para ippk-atualizacoes-susbscribe@yahoogrupos.com.br. Para egresso, envie um e-mail para ippk-atualizacoes-unsubscribe@yahoogrupos.com.br.

[2.0] Procedimentos

[2.1] Aplicados ao Canal

Procedimento: 1CA
Evento: O canal conta com um número relativo de colaboradores, porém o volume de perguntas é tão grande que a leitura do canal fica dificultada.
Ação: Definir o modo +f com uma configuração de linhas por segundo que limite significativamente o volume de mensagens no canal. Convocar os colaboradores do canal que desejam prestar atendimentos que já sejam conhecidos para ceder a eles o status de voice. Dessa forma, a quantidade de respostas seja igual ou maior que a quantidade de perguntas. É importante a presença dos colaboradores no canal #Helpers, onde os atendimentos prestados serão comentados e dúvidas dos colaboradores atendidas. Consulte também o documento http://ippk.kurtkraut.cjb.net/1ca-esclarecimentos
Tolerância: Presença de muitos operadores humanos e ativos no canal.
Status: Ativo.

Procedimento: 2CA
Evento: Os servidores apresentam enorme desincronia que praticamente inviabiliza que as perguntas e as respectivas respostas sejam lidas, causando irritação nos usuários por não serem atendidos.
Ação: Definir o modo +m no canal por um pequeno intervalo de tempo (geralmente 5 minutos) para que os dados da rede sejam melhor distribuídos e neste meio tempo orientar o usuário sobre como obter ajuda sozinho e a atual dificuldade de atendimento no canal.
Tolerância: Baixa desincronia e atendentes espalhados pelos hubs e leafs da rede oferecendo um atendimento não tão desincronisado, netsplit na maioria dos hubs ou situação emergencial onde se faz extremamente necessário o atendimento em canal aberto.
Status: Ativo.

Procedimento: 3CA
Evento: Ataque de clones/trojanbots ou similares no canal ou simplesmente o risco deste evento acontecer.
Ação: Manter o modo +R no canal (dependendo da gravidade o modo +m também pode ser aplicado), impedindo o ataque e a remoção do modo até que todos os hosts envolvidos estejam banidos ou o canal esteja seguro. Os hosts envolvidos são adicionados na lista de bans do bot lmt de acordo com o SISTEMA DE CLASSES (vide item 3.0).
Tolerância: Nenhuma.
Status: Ativo

Procedimento: 4CA
Evento: Problemas emergenciais ou peculiares em que o atendimento em canal aberto no #Ajuda torna-se inviável pela privacidade necessária do atendimento ou pelo volume de perguntas no #Ajuda.
Ação: Um canal para atendimento exclusivo emergencial ou para os casos em particular deverá ser aberto, de forma que o nome do canal e/ou a forma em que os usuários são convidados a entrar nele não crie o precedente de canais falsos dessa ordem sejam criados para instruções maliciosas.
Tolerância: Presença de muitos operadores humanos e ativos no canal #Ajuda ou baixíssimo ou nenhum movimento no #Ajuda que viabilize o atendimento do assunto.
Status: Ativo

Procedimento: -
Evento: -
Ação: -
Tolerância: -
Status: -

[2.2] Aplicados ao Usuário

Apesar dos colaboradores do canal possuírem um item de procedimentos exclusivo (2.3), todos os procedimentos de usuário também são aplicáveis a eles.

Procedimento: 1US
Evento: Perguntas no canal que não estão relacionadas com o IRC ou a rede BRASnet.
Ação: A seguinte mensagem é direcionada ao usuário: 'O foco deste canal é o atendimento da BRASnet apenas. Você muito provavelmente não será respondido aqui. Para este assunto, procure um site especializado em www.google.com ou no site de busca de sua preferência.'
Tolerância: Baixíssimo ou nenhum movimento no #Ajuda que viabilize o atendimento do assunto.
Status: Ativo. Consulte resolução 7RE deste documento.

Procedimento: 2US
Evento: Perguntas relacionadas a scripting, eggdrop, ircd e administração de serviços.
Ação: A seguinte mensagem é direcionada ao usuário: 'Para responder melhor a sua pergunta consulte um canal ou site especializado. Digite /list *assunto* para procurar na BRASnet ou o site www.google.com.br'.
Tolerância: Baixíssimo ou nenhum movimento no #Ajuda que viabilize o atendimento do assunto.
Status: Ativo. Consulte resolução 7RE deste documento.

Procedimento: 3US
Evento: O usuário pretende entrar em contato com um Administrador de Serviços, IRCadministrador ou IRCoperador para atendimento.
Ação: A seguinte mensagem é direcionada ao usuário: 'IRCops não tem a função os usuários na BRASnet e nem poderes para ajudá-los. O atendimento da rede é feito pela equipe do #Ajuda. Resuma aqui o seu problema e alguém irá atendê-lo.'
Tolerância: Questões Administrativas, Questões do BotServ, Denúncias de SPAM, Denúncias de Abuso de poder, Denúncias de ataques, Sugestões para a rede, Sugestões para o #Ajuda, Atendimento interno da equipe do #Ajuda, Atendimento aos colaboradores do #Ajuda. Nestes casos o usuário é orientado a entrar em contato via PVT (Private) com um operador do #Ajuda.
Status: Ativo.

Procedimento: 4US
Evento: Qualquer tipo de ofensa ou palavra de baixo calão proferida a entidades que envolvam ou não o IRC de forma explícita ou implícita.
Ação: O usuário é banido e/ou expulso (KICK) do canal.
Tolerância: Baixíssimo ou nenhum movimento no #Ajuda em que a ofensa/palavra tenha sido feita/usada de forma subjetiva o que permite uma repreensão em canal aberto ao invés de uma punição.
Status: Ativo.

Procedimento: 5US
Evento: Solicitação de atendimento via PVT (private).
Ação: A seguinte mensagem é direcionada ao usuário: 'O atendimento da rede BRASnet é feito no canal #Ajuda. Por gentileza, faça sua pergunta lá e não responda esta mensagem aqui. Grato pela compreensão. (mensagem automática)'
Tolerância: Questões Administrativas, Questões do BotServ, Denúncias de SPAM, Denúncias de abuso de poder, denúncias de ataques, sugestões para a rede, sugestões para o #Ajuda, atendimento interno da equipe do #Ajuda, atendimento aos colaboradores do #Ajuda.
Status: Ativo.

Procedimento: 6US
Evento: Tentativa de roubo de registros, envio de vírus/trojans, citação de códigos maliciosos, instruções maliciosas, instruções que coloquem em risco a segurança do usuário. Exemplos: //say $ip; /quit não intencional; /disconnect não intencional; /run com efeitos indesejados; /write e /load não intencional; ALT+F4
Ação: O usuário é banido e/ou expulso (KICK) do canal.
Tolerância: Nenhuma.
Status: Ativo

Procedimento: 7US
Evento: O usuário se excede na pontuação. Na mesma frase, mais de três pontos de interrogação ou exclamação ou final.
Ação: O usuário é expulso (KICK) do canal com o motivo: 'Não exagere na pontuação. Três pontos de interrogação/exclamação/final são mais que necessários. Você está banido por 2 minutos.'
Tolerância: Baixíssimo ou nenhum movimento no #Ajuda.
Status: Ativo

Procedimento: 8US
Evento: O usuário menciona em canal aberto o nome de um canal sendo precedido ou não por # ou &.
Ação: O usuário é banido e/ou expulso (KICK) do canal com o motivo 'Propaganda'
Tolerância: A menção dos canais #Ajuda, #BRASnet, #Help, #RadioBRASnet, #BotServ, #Brasil, #SIB, #Helpers, canais com nome de capitais do país ou participantes do Plano de Desenvolvimento Regional da BRASnet. Caso o usuário tenha mencionado o canal ao colar uma mensagem do servidor ou dos Serviços da Rede, demonstrando que a menção não foi intencional, a expulsão (KICK) é aplicada e o BAN somente em caso de reincidência.
Status: Ativo

Procedimento: 9US
Evento: O usuário menciona em canal aberto um endereço de website (http://, ftp://) que não esteja relacionado a algum assunto tratado no canal, caracterizando uma propaganda explícita.
Ação: O usuário é banido e/ou expulso (KICK) do canal com o motivo 'Propaganda'
Tolerância: Os sites www.brasnet.org, http://ippk.kurtkraut.cjb.net, http://suporte.kurtkraut.cjb.net, www.mirc.com, http://windowsupdate.microsoft.com não são interpretados como propaganda. Baixíssimo ou nenhum movimento no #Ajuda onde o site seja mencionado durante uma conversa entre colaboradores do #Ajuda.
Status: Ativo

Procedimento: 10US
Evento: O usuário faz uma oferta, proposta ou similar em canal aberto caracterizando uma propaganda implícita.
Ação: O usuário é banido e/ou expulso (KICK) do canal com o motivo 'Não faça ofertas no #Ajuda'.
Tolerância: Baixíssimo ou nenhum movimento no #Ajuda.
Status: Ativo

Procedimento: 11US
Evento: O usuário solicita suporte a um produto da Microsoft.
Ação: A seguinte mensagem é direcionada ao usuário: 'Dúvidas sobre produtos da Microsoft devem ser tiradas no suporte da Microsoft. Consulte www.microsoft.com/brasil/suporte ou o telefone (11) 3444-6844 em horário comercial de segunda a segunda.'
Tolerância: Nenhuma.
Status: Ativo

Procedimento: 12US
Evento: O usuário faz perguntas sobre tarifas telefônicas, datas e horas de tarifas ou pulso único.
Ação: A seguinte mensagem é direcionada ao usuário: 'Dúvidas sobre tarifas telefônicas devem ser tiradas no atendimento de sua operadora telefônica. Ligue para lá e pergunte. O atendimento é 24h.'
Tolerância: Nenhuma
Status: Ativo

Procedimento: -
Evento: -
Ação: -
Tolerância: -
Status: -

[2.3] Aplicados aos Colaboradores

São caracterizados como colaboradores do canal aqueles que estejam dando instruções em canal aberto, mesmo que uma pergunta tenha sido feita ou não.

Procedimento: 1CO
Evento: O colaborador indica o comando /ircops ou qualquer outro meio em que o usuário seja atendido por um IRCoperador, IRCadministrador ou Administrador de Serviços como indicado no Evento do Procedimento 3US.
Ação: O colaborador é expulso (KICK) do canal com o motivo 'Instruções Maliciosas' por oferecer riscos aos usuários na medida em que os encaminha para um atendimento não supervisionado.
Tolerância: Questões Locais do Servidor que envolvam os poderes de KILL/KLINE/REHASH/REDIRECT de um IRCoperador ou IRCadministrador específico.
Status: Ativo

Procedimento: 2CO
Evento: O Colaborador atende o usuário com instruções maliciosas mesmo que essa seja a vontade do mesmo e/ou a instrução implique em riscos e danos a alguma parte envolvida (BRASNet/Usuário/#Ajuda/Colaborador). Exemplo: //say $ip; /quit não intencional; /disconnect não intencional; /run com efeitos indesejados; /write e /load não intencionais; ALT+F4
Ação: O colaborador é banido e/ou expulso (KICK) do canal com o motivo 'Instruções Maliciosas'. Em caso de reincidência os devidos mecanismos serão acionados para que ele fique permanentemente banido do #Ajuda.
Tolerância: Nenhuma.
Status: Ativo.

Procedimento: 3CO
Evento: O colaborador pede publicamente (em canal aberto) ou particularmente (em PVT) o status de voice/operador.
Ação: Caso o pedido tenha sido feito publicamente, o usuário é expulso (KICK) do canal com o motivo 'Solicitação Pública de Status'. Se o pedido foi feito via PVT, o colaborador é orientado sobre o funcionamento e a proposta do #Ajuda e mesmo que faça por merecer, não receberá voice pelas próximas 24h. 'Melhor merecer a honra sem possui-la do que possui-la sem merecê-la.' (Camões)
Tolerância: Voices ou operadores registrados na lista de acesso do #Ajuda solicitando o respectivo status na ausência ou lentidão dos serviços da rede, procedimento 1CA sendo executado no canal.
Status: Ativo

Procedimento: 4CO
Evento: O colaborador indica um endereço de servidor para conexão que não seja um redirecionamento *.brasnet.org - Isto além de implicar em riscos de segurança pode dar margem para que propagandas de servidores sejam feitas no #Ajuda.
Ação: O colaborador é banido e/ou expulso (KICK) do canal com o motivo 'Propaganda'.
Tolerância: Todos os redirecionamentos *.brasnet.org não estejam funcionando adequadamente.
Status: Ativo.

Procedimento: 5CO
Evento: O colaborador encaminha o usuário para outro canal, um site ou qualquer outro meio de comunicação quando a pergunta do usuário envolve um assunto pertinente ao #Ajuda e o atendimento da rede BRASnet. Pergunta desta natureza devem ser respondidas no canal e o encaminhamento para qualquer outro lugar oferece risco ao usuário, podendo receber informações erradas ou maliciosas.
Ação: O colaborador é banido e/ou expulso (KICK) do canal com o motivo 'Propaganda'. Em caso de reincidência os devidos mecanismos serão acionados para que ele fique permanentemente banido do #Ajuda.
Tolerância: Nenhuma.
Status: Ativo. Consulte a resolução 7RE.

Procedimento: -
Evento: -
Ação: -
Tolerância: -
Status: -

[3.0] Sistema de Classes

Para garantir melhor segurança ao canal #Ajuda, nos BANs adicionados na lista do bot lmt o Sistema de Classes é adotado. Este sistema compreende na classificação em Classes A, B, C, D e S. O motivo do BAN explicita a Classe em que o HOST foi envolvido e o e-mail da Ouvidoria do #Ajuda para contato de acordo com cada classe. Vale ressaltar que esta nomenclatura não se refere as classes de IP do protocolo TCP/IP.

Classe A: São aplicados a HOSTs internacionais, que geralmente possuem reverso e não são pertencentes a provedores de acesso à internet exclusivamente. Expiram em 365 dias.

Classe B: São aplicados a HOSTs internacionais, que geralmente não possuem reverso e/ou pertencem a provedores de acesso à internet exclusivamente. Expiram em 60 dias.

Classe C: São aplicados a HOSTs nacionais que iniciem em 200.* ou o reverso evidencia que pertence exclusivamente a um provedor de acesso à internet. Expiram em 15 dias.

Classe D: São aplicados a HOSTs nacionais que iniciem em 200.* ou o reverso evidencia que pertence exclusivamente a um provedor de acesso à internet. Estes HOSTs possuem autorização para conexões múltiplas na BRASnet pelo OperServ. Expiram em 2 dias.

Classe S: São aplicados a HOSTs envolvidos com SPAM. Para HOSTs internacionais, expiram em 15 dias. Para HOSTs nacionais, expiram em 2 dias. A medida que se tornam reincidentes são promovidos para a Classe A e para Classe B respectivamente.

[4.0] Projetos

Algumas idéias antes de serem colocadas em prática devem ser amplamente revisadas, discutidas e testadas. Este espaço se dedica a isto. Se você tem algum comentário ou idéia sobre os projetos aqui listados, faça a gentileza de entrar em contato via kurtkraut@brasnet.org

Projeto: 1PRO
Data & Hora: 21/01/2003 @ 18:33
Descrição:

Desde que o uso de cores foi proibido no #Ajuda os usuários tem procurado outros recursos para chamar mais atenção para suas mensagens. O uso de negrito e sublinhado passou a ser utilizado e conseqüentemente proibido. O que intensificou um processo que vinha ocorrendo desde antes do abuso de cores causado pelo alto tráfego de canal: o excesso de pontuação.

O uso de um ponto de interrogação/exclamação/final já deixa bem clara a mensagem que o usuário pretende passar. O uso de três pontos sucessivos claramente e comedidamente intensifica a pergunta, a exclamação ou hesitação do usuário. Porém infelizmente a pontuação tem sido usada abusivamente, chegando até 52 pontos seguidos, o que só acarreta problemas ao canal sem necessidade. Para quem usa resoluções baixas, a quantidade de linhas ocupadas na tela pela mensagem exagerada é bem maior, aumentando a velocidade que o texto rola no canal dificultando sua leitura. Além disto, como os exageros causam uma poluição visual, quem está tentando ler as perguntas para responder é atrapalhado e quem quer ler as respostas também, complicando a comunicação no canal. Frustrado o usuário além de cometer floods e ofensas passa a tentar 'competir' com mais caracteres repetidos. Nos logs deste projeto você irá verificar que geralmente o número de caracteres repetidos é crescente.

Tomemos um exemplo: um usuário ao ver outro perguntando com 7 pontos de interrogação tende a fazer sua pergunta com 10 pontos de interrogação (instintivamente) para que sua pergunta chame mais a atenção do que a do usuário anterior, criando assim um ciclo crescente de exageros.

Por praticamente uma hora coletei no #Ajuda entre às 15:56 e às 16:49 do dia 18/01/03 todas as mensagens que continham mais de 3 pontos de interrogação/exclamação/final seguidos. Separadamente em outro arquivo coloquei apenas as pontuações exageradas, o que me permitiu o cálculo de que a pontuação exagerada equivale a 40,62% do texto das mensagens exageradas, ou seja, quase a metade do conteúdo das mensagens são totalmente inúteis e só atrapalham o canal. Consulte no tópico Comentários deste projeto os arquivos anexados e note que o intervalo entre um exagero e outro geralmente gira em torno de 2 ou 3 minutos, o que evidencia que um exagero induz que outro seja cometido. Veja também que é comum que os usuários que cometem exageros facilmente repetem suas mensagens num curto espaço de tempo, demonstrando o propósito de chamar mais a atenção.

Como as regras do #Ajuda proíbem que os operadores venham a punir este tipo de comprometimento do canal e abuso por parte dos usuários, minha proposta é permitir que os operadores possam banir por um curto período de tempo ou expulsar (KICK) os usuários do canal que se excederem em 3 (ou 5, um valor mais brando) pontos de interrogação/exclamação/final com um motivo de KICK explicativo como, por exemplo, o proposto no procedimento 7US do item 2.2 deste documento.

Comentários:

Para os interessados, eis os logs que permitiram meu cálculo de 40,62% de caracteres ocupados pelos exageros:

{anexo-pro1-1.txt} com 4.313 bytes
{anexo-pro1-2.txt} com 1.752 bytes

Para manter a proporção relativa do exagero por mensagem os TIMESTAMPs e os nicks dos usuários que se excederam foram repetidos no arquivo anexo-pro1-2.txt permitindo o cálculo exato da porcentagem dos exageros em relação as mensagens. Durante o período avaliado o #Ajuda atingiu o pico de 88 usuários simultâneos.

Status: Aprovado pela Ouvidoria e Equipe de Masters.

Projeto: 2PRO
Data & Hora: 16/05/2003 @ 22:00
Descrição:

A quantidade de usuários da rede BRASnet tem se apresentado de forma crescente, porém o número de pessoas dispostas a ajudar ao próximo no canal #Ajuda está bem aquém deste crescimento. Isso implica, ao passar do tempo, em uma queda de qualidade e principalmente agilidade do atendimento da rede. No canal #Ajuda especificamente este problema é mais grave. O usuário enquanto aguarda sua resposta nota que muitos outros usuários, que geralmente já perguntaram há muito tempo, são respondidos. Mas infelizmente a imensa maioria dos que procuram o #Ajuda não são capazes de considerar que todas as respostas a que assiste já foram perguntadas há algum tempo atrás e passa a sentir que sua pergunta está sendo ignorada. Em resposta a esta sensação o usuário tende a um comportamento abusivo no #Ajuda, com repetições, flood, excesso de caracteres e até ofensas.

Para solucionar este problema proponho um sistema de previsão de atendimento, que batizei de HPREV. O HPREV é um sistema que estima o tempo máximo em que o usuário será atendido. Esta previsão é exibida no tópico do canal e/ou na mensagem de entrada do canal enviada por PVT. Tendo uma estimativa do tempo de atendimento o usuário fica menos ansioso, reduzindo o comportamento abusivo no canal e de uma forma geral facilitando todas as atividades do #Ajuda.

O HPREV não tem a intenção de calcular e sim de estimar o tempo máximo de atendimento. Calculando algumas especulações, o HPREV pode estimar com uma margem segura a previsão de atendimento. O HPREV especula que para cada Potencial Humano é capaz de fazer quatro atendimentos por minuto. O Potencial Humano é uma variável sem unidade que mensura a capacidade de atendimento do canal. Cada voice no canal soma um ponto ao Potencial Humano e cada operador, tendo em vista que este deve estar mais ocupado com o controle do canal, tem um valor inferior de 0.8 (20% menor) somado ao Potencial Humano. Para exemplificar, dez operadores humanos gerariam um Potencial Humano igual a 8 e dez voices gerariam um Potencial de 10 pontos.

Já que a especulação é de 4 atendimentos por minuto e que cada usuário (desconsiderando operadores, bots e voices) possui uma pergunta, o Potencial Humano é multiplicado por 4 e dividido pela quantidade de usuários, equacionando assim a previsão de atendimento em minutos. Com estas especulações podemos criar a seguinte fórmula geral do HPREV: Previsão=(Potencial Humano * 4)/Usuários. Vale ressaltar que este cálculo possui arredondamento ao final.

O que garante a margem de segurança da Previsão são as ponderações que podemos fazer acerca das especulações que o HPREV faz. Um voice e até um operador podem muito bem fazer mais do que 4 atendimentos por minuto. Além disso, a quantidade de usuários que fazem perguntas é menor do que o número total de usuários (ressaltando: desconsiderando operadores, voices e bots deste número). Estas duas ponderações garantem que a previsão é relativamente superior ao tempo real de atendimento, que além de oferecer segurança na estimativa, proporciona ao usuário a surpresa de ser atendido antes do tempo previsto.

Para ilustrar essa margem de segurança a tabela abaixo irá mostrar as previsões de tempo de atendimento para as quantidades de voices rotuladas na primeira coluna vertical e para as quantidades de operadores rotulados na primeira linha horizontal. Por uma limitação de eixos foi tomada como base a quantidade de 100 usuários simultâneos no canal #Ajuda, um valor médio dos horários de pico do canal.

* = Na ausência de operadores humanos e voices identificados, como o canal sempre conta com um fiel grupo de colaboradores, é muito provável que o usuário seja atendido. Dessa forma o maior tempo de previsão (um operador e nenhum voice) é repetido para este momento.

FAQ versão 0.1:

1- Qual é a diferença do HPREV para o HPREVT ?
HPREV é o nome do projeto de previsão máxima de atendimento no canal #Ajuda da rede BRASnet. HPREVT é um script temporário que apenas calcula o tempo máximo de atendimento a partir da entrada de alguns dados.

2- Por que ainda não foi disponibilizado um script que calcule o tempo máximo de atendimento em tempo real ?
Porque o script que foi elaborado não está matematicamente atualizado e possui alguns erros. Quem se oferecer a ajudar será muito bem-vindo.

3- Qual é o futuro do HPREV ?
Como você deve ter notado, esta versão é a 0.1. Com o decorrer das versões, novas adequações matemáticas serão feitas. Estou pensando em fazer uma equação exponencial para deixar mais tênue a variação da previsão. Outro detalhe importante que quero considerar nas ponderações do HPREV é o lag, que interfere e muito nas previsões de atendimento. Depois de um amadurecimento matemático do HPREV o próximo passo é o desenvolvimento de uma TCL para eggdrop que irá informar os usuários sobre a previsão máxima de atendimento

4- O que é Potencial Humano ?
Potencial Humano é uma variável sem unidade que visa mensurar a capacidade de atendimento dos operadores e voices do canal. Cada operador ativo no canal soma ao Potencial Humano o valor 0.8 unidade e cada voice soma 1 unidade. Ou seja, dois operadores e um voice totalizam 2.6 pontos de Potencial Humano. Ao multiplicar o Potencial Humano por quatro, como faz a fórmula do HPREV, obtém-se a previsão mínima de atendimentos por minuto.

5- Por que quanto maior a quantidade de operadores e voices simultâneos a variação no tempo de atendimento é menor ?
Porque é praxe no #Ajuda um único usuário ser atendido por mais de um operador, ou voice ou colaborador. E outros fenômenos podem ser constatados quando há uma grande quantidade de operadores e voices presentes. Por exemplo, se temos muitos voices e uma quantidade razoável de operadores a tendência é a especiação, ou seja, os voices se dedicarem totalmente ao atendimento no canal e os operadores se dedicarem totalmente ao controle e ordem do canal, o que afeta diretamente o atendimento. Além disso grandes quantidades de operadores simultâneos tendem a criar conversas em ONOTICE sobre o #Ajuda ou não, reduzindo também a variação do tempo de atendimento.

6- Por que o tempo previsto é muito alto ?
Porque a intenção do HPREV por enquanto não é prever exatamente o tempo de atendimento e sim estipular um tempo *máximo* de atendimento. Caso esse tempo máximo seja extrapolado há muito provavelmente uma falha no atendimento: ou por parte do usuário ou da equipe do canal. Isso permite que, mediante estes eventos, seja feia uma análise da condição do canal e que se pesquise os motivos que levaram um determinado usuário a não ser atendido como deveria ser.

7- Por que o Potencial Humano é multiplicado por quatro ?
Porque nas ponderações do HPREV, cada Potencial Humano é capaz de fazer no mínimo quatro atendimentos por minuto.

8- Os cálculos do HPREV são utilizados como base para os procedimentos 1CA e 2CA ?
No caso do 1CA (vide item 2.1 deste documento) isso ainda está sendo estudado. Para o procedimento 2CA isso só será possível quando o LAG for considerado na fórmula do HPREV. Porém ambas são perspectivas para o futuro do HPREV no IPPK.

9- O HPREV pode ser usado por canais de suporte de outras redes ou outros canais ?
Sim. Desde que me informem e se comprometam a me auxiliar em melhorias no sistema de previsão no atendimento.

10- O que posso fazer para contribuir com o HPREV ?
No item Comentários desse projeto existe o pacote desta versão do HPREV. Baixe o pacote e analise os arquivos. Naquilo que você puder colaborar, com sugestões matemáticas, de scripting, de TCL ou de qualquer outra natureza são muito bem-vindos. No presente momento preciso urgentemente de um programador em TCL que me auxilie. Para todos os casos, meu e-mail para contato é kurtkraut@brasnet.org

11- Por que o tempo previsto para nenhum operador e nenhum voice é igual ao tempo para um único operador ?
Isso é uma adequação a intenção que tenho de, numa futura versão do HPREV, usar uma função exponencial. Como o gráfico deste tipo de função não toca o eixo das abscissas, este momento @0+0 não poderia ser previsto. Logo, por convenção, o maior tempo previsto (@1+0) é utilizado.


Comentários:

Abaixo está o link para download do Pacote HPREV v0.1, que contém um script para mIRC do HPREVT (calculadora do HPREV), uma planilha XLS para ensaios matemáticos e as licenças do HPREV.

{hprevt-pct-v0.1.zip} com 15.114 bytes

Status: Em desenvolvimento e testes.

Projeto: 3PRO
Data & Hora: 22:22 @ 06/06/2003
Descrição: Curiosamente os 3 primeiros projetos do IPPK têm uma origem comum: a falta de atendentes no canal #Ajuda. Esse projeto pretende atuar diretamente nesta causa, diferentemente dos dois anteriores que visam reduzir as conseqüências. Pelas péssimas condições da rede nesses últimos meses (o que causou até evasão da nossa Equipe) e também a falta de perspectiva de ascensão no canal por decorrência de duas administrações de Mastering problemáticas o número de colaboradores reduziu drasticamente.

Para aumentar o número de colaboradores e Potencial Humano do canal proponho o 'Programa Treineiros'. Esse programa se apresenta de forma mensal, com 3 vagas de treineiros (trainees). Os 3 colaboradores com os melhores índices de atendimento nas estatísticas do canal, que não tenham um histórico de mau comportamento que implique em problemas, são convidados a participar do programa. Eles seriam adicionados na lista de acesso do canal com um nível igual ou superior de AUTOVOICE para que sejam voices do canal, porém, com um nível inferior ou igual ao de AUTODEOP, para que sejam operadores em hipótese nenhuma.

Transcorrido um mês, se o treineiro tiver maturidade suficiente para entrar para equipe do canal, ele será promovido a voice. Caso ainda não tenha condições de entrar na equipe há dois caminhos a se seguir: se o treineiro não permanecer entre os 3 melhores ranqueados do canal, ele é excluído do programa e da lista de acesso, cedendo a vaga para um dos três mais ranqueados nas estatísticas do mês. Se o treineiro permanecer ranqueado entre os 3 melhores nas estatísticas do canal ele continua no Programa de Treineiros até 3 meses, pois se nesse tempo ainda não atingiu maturidade para ser voice seria melhor que cedesse a oportunidade a alguém mais capaz.

Só para ressaltar, os treineiros não poderiam ser definidos temporariamente como operador por proteção do ChanServ. Isso seria a diferença básica entre um voice e um treineiro. Além disso, os treineiros seriam adicionados na lista de e-mail (MAILING LIST) de voices onde receberiam instruções oficiais e poderiam tirar suas dúvidas. Dessa forma estaríamos estimulando os colaboradores a terem altos índices de atendimento no #Ajuda além de dar-lhes uma perspectiva de crescimento no canal.

Comentários: nenhum.
Status: Aprovado pela Equipe de Masters. Aguardando aprovação da Ouvidoria do canal.

Projeto: 4PRO
Data & Hora: 31/10/2003 @ 11:52
Descrição: O projeto 4PRO, de apelido NOMA - Nova Metodologia de Atendimento - possui uma página exclusiva de endereço www.ajuda.org/noma - Como o site mencionado é bastante amplo e foi publicado antes da versão do IPPK em que consta o projeto 4PRO, esta parte do projeto se destinará as perguntas mais freqüentes sobre a NOMA. Segue o FAQ:

1- Qual é a intenção dessa nova forma de atendimento ?
São sete pontos principais:
- Reeducar o usuário, fazendo com que ele leia primeiro a documentação disponível para depois perguntar no #Ajuda.
- Condicionar o usuário a procurar ajuda sozinho e na eventualidade de encontrar dificuldades, recorrer ao #Ajuda.
- Popularizar a documentação existente.
- Dar autonomia ao usuário, para que ele não dependa do #Ajuda quando quiser aprender novos recursos.
- Reduzir o tráfego repetitivo do #Ajuda.
- Elevar o nível de atendimento do canal. De questões simples e corriqueiras para situações mais elaboradas e raras.
- Elevar o nível de conhecimento do usuário oferecendo-o a documentação completa sobre o assunto.

2- Como seria o funcionamento da NOMA no #Ajuda ?
Todos que estão no #Ajuda para responder as perguntas deverão responder no formato proposto (/service help), incluindo ouvidores, masters, operadores, voices registrados, voices temporários e colaboradores. Os que não pariticipam oficialmente da equipe do canal seriam orientados pelo IPPK, outros sites e/ou canal #Helpers a como proceder no #Ajuda além de serem sensibilizados sobre a importância de reeducar e condicionar os usuários.

3- Qual seria o efeito da proposta no canal ?
- Redução drástica no volume de perguntas repetidas e simples.
- Maior capacidade de atendimento simultâneo, tendo em vista a redução do volume desnecessário.
- Menor congestionamento e menor necessidade de fechamento do canal nos fins de semana.
- Possível aumento de colaboradores e até integrantes da equipe do canal, já que o #Ajuda retornaria a ser um canal humanamente possível de se frequentar.
- Menor volume de ofensas, repetições e flood.

4- Qual seria o efeito da NOMA no usuário ?
No primeiro momento o usuário poderá até ficar irritado ou frustrado. Mas da mesma forma que todos os usuários se adaptaram aos modos +c, +d e +f eles também irão se adaptar na mesma velocidade à nova realidade do canal. O segredo é que a partir do momento que se torna FUNDAMENTAL para o usuário uma mudança de hábito, ele irá mudar para se adaptar à nova realidade. A partir do momento que ele notar que é fundamental consultar a documentação para resolver o problema dele, ele irá consultar a documentação. Até que esse momento de condicionamento chegue, é importante a insistência de todos no canal para continuar orientando os usuários a consultar a documentação.

5- Qual seria o efeito da NOMA na Equipe do #Ajuda e seus colaboradores ?
Como o canal terá uma redução no volume de perguntas simples, as perguntas mais elaboradas irão elevar significativamente o nível dos colaboradores do canal, pois da mesma forma que os usuários se adaptarão à nova realidade do atendimento, os colaboradores também irão se adaptar, aprendendo mais sobre casos raros e peculiaridades. Depois dos usuários, os colaboradores serão o grupo que maior sofrerá mudanças com essa proposta, pois sua conduta mudará: de um simples cidadãos que lêm perguntas, clicam em pop-ups e usam aliases respondendo mecanicamente, agora com perguntas de maior nível, serão obrigados a refletir, pensar e tomar decisões sobre como orientar melhor os usuários.

Quanto a Equipe do #Ajuda, os integrantes que haviam se afastado por falta de tempo ou até por descontentamento poderão retornar pois o canal se apresentará de forma mais tranqüila e menos desagradável, permitindo até uma participação esporádica dos mais ocupados ou uma pariticipação mais ativas daqueles que estavam descontentes com o rumo que o canal tomava.

6- A NOMA irá mudar a forma de atendimento para sempre ?
Não. Uma vez que o #Ajuda retornar aos moldes de antigamente, onde se era humanamente possível atender à todos os casos, o método antigo de
atendimento poderá ser retornado. A proposta pretende acabar com a situação de caos no canal, principalmente nos fins de semana e outros horários de congestionamento. Tendo o caos cessado, não há uma grande necessidade de se manter o atendimento no formato /service help.

7- Então como será orientado o atendimento com essa nova proposta ?
Será da seguinte forma:

Para dúvidas sobre o sistema regulador de canais: /ChanServ help
Para dúvidas sobre o sistema regulador de nicks: /NickServ help
Para dúvidas sobre o sistema de mensagens offline: /MemoServ help
Para dúvidas sobre os modos de canal: /helpsys chanmodes
Para dúvidas sobre os modos de nick: /helpsys umodes
Para dúvidas sobre o serviço de BotServ: /BotServ help

Os comandos de HELP serão acompanhados de sua sintaxe completa. Por exemplo, uma dúvida de MLOCK será respondida com /ChanServ help set MLOCK e não apenas /ChanServ help.

*** PARA TODAS AS DÚVIDAS EM QUE AS DOCUMENTAÇÕES NÃO AS RESPONDAM SATISFATORIAMENTE, A PERGUNTA PODERÁ SER RESPONDIDA COM O COMANDO COMPLETO (metodologia antiga de atendimento) SEM QUALQUER PREJUÍZO ***. A intenção não é deixar de responder o usuário e sim dar a ele uma autonomia. Se essa autonomia não for possível, cabe então ao atendente sanar a dúvida do usuário. Caso a dúvida seja reincidente no canal, isso aponta a necessidade de se reformular ou criar uma documentação sobre o assunto.

8- A NOMA não 'acabaria' com o #Ajuda ?
Em hipótese alguma. Documentação nenhuma conseguirá abranger todos os casos e todas as dúvidas possíveis, por isso SEMPRE se fará necessária a presença do #Ajuda, sua equipe e seus colaboradores. A proposta de forma alguma ameaça a existência do canal.

9- O #Ajuda não deixaria de cumprir o seu papel ao adotar a NOMA ?
Não. O papel do #Ajuda é atender os usuários e o atendimento será realizado da melhor forma possível: o usuário será apresentado à toda documentação oficial sobre o assunto desejado contento todas as informações possíveis sobre o tema. Além de atender o #Ajuda estará educando, para não só o benefício do usuário mas também para o benefício do #Ajuda. Garanto que o usuário prefere ser respondido, mesmo com uma documentação, do que perguntar inúmeras vezes no #Ajuda e não ser respondido de forma alguma.

10- Como é que o atendimento poderia mudar para essa nova metodologia de imediato ?
Através da publicação deste projeto como procedimento dentro do IPPK, o qual tem sido uma referência para muitos colaboradores, anúncios no tópico indicando uma URL que contenha uma carta aos usuários explicando os motivos da nova metodologia e uma carta aos colaboradores, convocando-os a participar da proposta, artigos em sites de imprensa especializados e *um script de ajuda em aliases e POP-UP que já contenha as respostas no formato /service help*. Se mesmo em caráter de teste proposto em alguns momentos por mim no canal os colaboradores, operadores e voices foram capazes de MANUALMENTE responder com essa nova metodologia, que dirá a partir do momento que terão recursos de automação e embasamento oficial para fazer isso, prova de que a implementação da metodologia poderá ser IMEDIATA.

Comentários: -
Status: Aprovado e em uso.

Projeto: -
Data & Hora: -
Descrição: -
Comentários: -
Status: -

[4.1] Resoluções

Este item dedica-se às Resoluções que tenho sobre os assuntos tangíveis ao canal #Ajuda e a rede BRASnet de IRC. O propósito é compartilhar com os interessados a minha opinião sobre assuntos que não podem ser rotulados como procedimentos e muito menos são projetos. A motivação deste item é a enorme quantidade erros, contradições e falta de informação no atendimento do canal. A resoluções abaixo listadas podem ser úteis para a padronização do atendimento no canal e futuramente podem amadurecer e tornarem-se procedimentos.

Resolução: 1RE
Título: MLOCK segura
Data & Hora: 03/06/2003 @ 13:14
Expira: não expira
Descrição: Muitas respostas no #Ajuda passam através das gerações de operadores, voices e colaboradores sem uma reflexão à respeito. Um caso curioso e importante que cabe nesta situação são as respostas das perguntas sobre MLOCK. A imensa maioria dos usuários não tem conhecimento do funcionamento e até da existência da MLOCK e recorrem ao #Ajuda reclamando/relatando de que ao definir um modo com trava padrão negativa o ChanServ desfaz a alteração. Para ilustrar, consideremos a situação:

<Guest7418> eu tento colocar o modo +m e o ChanServ tira... como ponho ?

Geralmente os atendentes do canal responderiam /ChanServ set #canal mlock +m e inconscientemente cometem dois graves erros. O primeiro grande erro é a natureza da resposta. O usuário quer apenas definir o modo +m e não travá-lo. O segundo erro e mais grave é a descaracterização da MLOCK antiga. Muita gente não nota que o comando MLOCK é sobrescretivo e não aditivo. Ou seja, toda vez que o comando MLOCK é usado a trava de modos antiga é apagada. Na situação ilustrada, se o usuário seguir a orientação comum, a trava de modos do canal dele seria unicamente +m, desfazendo toda a segurança oferecida pela trava padrão de modos (+nt-impsklR).

Portanto proponho duas formas de responder a esse tipo de pergunta (em ordem de preferência):

1- /ChanServ set #canal mlock +nt-ipsklR e depois /mode #canal +m: onde a MLOCK padrão é repetida apenas omitindo o modo -m.
2- /ChanServ set #canal mlock +ntm-ipsklR: se a intenção for de fato travar o modo +m

Em linhas gerais o ideal seria manter o máximo possível as travas padrão de modo de canal.

Status: Ativo


Resolução: 2RE
Título: MLOCK +k
Data & Hora: 05/06/2003 @ 12:10
Expira: não expira
Descrição: É comum o desejo de fundadores determinar quem tem acesso ou não ao seu canal. Muitas vezes recorrem ao #Ajuda perguntando como podem definir uma senha para acesso ao canal. Comumente os colaboradores respondem com o comando /ChanServ set #canal mlock +k senha, resposta triplamente errada. Os dois primeiros erros estão expostos na resolução 1RE e recomendo que a leia agora. O problema que esta resolução pretende abordar é a ineficácia do comando indicado. Travas de modo só surtem efeito quando pelo menos um usuário está presente no canal. Isso significa que mesmo o modo +k exija uma senha para entrar no canal, ele só será definido pelo ChanServ quando o primeiro usuário entrar no canal. Isso permite que esse primeiro usuário não só entre sem a senha como a veja no momento em que o ChanServ define o modo, que além de representar um risco de segurança, é bem diferente do desejo do fundador de controlar exatamente quem pode entrar no canal.

Para essa situação eu proponho duas respostas (em ordem de preferência):

1- /ChanServ help set restricted: ou qualquer instrução que combine os comandos RESTRICTED e ACCESS, permitindo que o usuário defina até 1024 nicks que poderiam ter acesso ao canal.
2- /HelpSys chanmodes: onde o usuário será apresentado à documentação de modos que além de listar o modo +k e explicar seu funcionamento, possui um parágrafo introdutório explicando a existência da MLOCK.
Status: Ativo


Resolução: 3RE
Título: Modo +e
Data & Hora: 05/06/2003 @ 12:31
Expira: não expira
Descrição: A invulnerabilidade é um desejo muito procurado por usuários no IRC. É intensa (e em vão) a busca por meios de não ser expulso (KICK) ou banido de um canal. Com o aparecimento do modo +e (EXCEPTION) muitos usuários enxergaram uma solução para este desejo. O modo +e é nada mais que uma exceção de banimento. Se o modo +b *!*@* (que bane todos os usuários do canal) for aplicado e em seguida o modo +e a*!*@* for definido, todo nick que começar pela letra 'a' poderá entrar no canal. É dessa forma que funciona a exceção de banimento. Esses usuários recorrem ao #Ajuda perguntando geralmente pelo 'modo anti-ban' e infelizmente recebe a resposta /mode #canal +e seunick!*@*. Não é necessário raciocinar muito para notar que isso seria uma proteção 'anti-ban' inútil. Qualquer um que pode definir o modo +b pode muito bem setar o modo -e. Ou seja, qualquer outro operador que queira banir o usuário ou outro operador pode remover a dita 'proteção' e bani-lo logo em seguida. Eu costumo comparar isso como se esconder durante um esconde-esconde atrás da cortina com os pés para fora. Vale ressaltar também que o modo +e não impede que a expulsão (KICK) seja aplicada.

Propostas de resposta (em ordem de preferência):

1- Explicar ao fundador/operador que não existe uma proteção 100% efetiva e que a melhor opção é selecionar melhor os operadores do canal e/ou estabelecer regras rígidas de conduta
2- Se o usuário procura exatamente pelo tal modo 'anti-ban' ou menciona exatamente o modo +e seria uma ocasião de explicá-lo o real funcionamento deste modo como na descrição desta resolução

Status: Ativo

Resolução: 4RE
Título: Endereço do Perfil
Data & Hora: 05/06/2003 @ 12:42
Expira: não expira até que os motivos técnicos em que se baseiam essa resolução invalidem-na.
Descrição: Embora existam vários endereços que aparentemente garantem acesso ao site do Perfil da BRASnet apenas um é oficial e deve ser indicado: http://perfil.brasnet.org. Esse endereço é o único que possui o mecanismo de redirecionamento para a página do Perfil. Mesmo que outros endereços como www.brasnet.org/profile.php exibam a página do Perfil, esses outros endereços não são acessíveis para todos os usuários e não fazem parte dos procedimentos de emergência da BRASnet que migram de local e endereço a página em questão.
Status: Ativo

Resolução: 5RE
Título: LEVELs para usuários não registrados
Data & Hora: 05/06/2003
Expira: não expira até que os motivos técnicos em que se baseiam essa resolução invalidem-na.
Descrição: Para a lista de LEVELs dos serviços da BRASnet (/ChanServ LEVELS) o nível 0 corresponde exclusivamente qualquer nick que não esteja registrado no canal ou que não tenha nenhum privilégio (como o AUTOOP) associado a um nível registrado. Tanto que não é possível registrar nicks na lista de acesso (/ChanServ ACCESS) com nível 0. Portanto qualquer privilégio que se deseja associar a qualquer usuário não registrado no canal o nível a ser indicado deve ser 0. Três motivos orientam essa resolução:

1- Se esse nível é o padrão e o mais correto ele deve ser respondido.
2- É a menor resposta possível, implicando em um comando menor para digitação
3- Na possibilidade dos Serviços da rede migrarem para outra plataforma ou mudarem a forma de gerenciamento de níveis e privilégio aquilo que estiver mais próximo do padrão está menos passível de erros.

Veja abaixo as perguntas mais comuns e as respostas propostas por essa resolução:

<Guest7418> como faço para que todos os usuários que entrem no meu canal ganhem voice automaticamente?
<Guest7418> como faço para que todos os usuários que entrem no meu canal ganhem op automaticamente?

Propostas de resposta (respectivamente):

1- /ChanServ levels #canal set autovoice 0
2- /ChanServ levels #canal set autoop 0

Status: Ativo


Resolução: 6RE
Título: Triagem de novos servidores para a rede
Data & Hora: 06/06/2003 @ 21:55
Expira: não expira
Descrição: Para todo servidor que propõe uma adesão à rede BRASnet de IRC é necessária uma triagem detalhada. Alguns colaboradores tendem a encaminhar para o atual responsável sem essa fundamental triagem, atitude que além de distanciar-se do propósito do #Ajuda de fazer o atendimento oficial da rede BRASnet nada mais é apenas mudar um problema de lugar. Confira os procedimentos de triagem propostos abaixo:

Triagem para servidores virtuais:
1- Verificar se o servidor pertence a um provedor de acesso à internet ou empresa de telecomunicações.
2- Verificar se quem está fazendo contato é funcionário ou dono do provedor. Os ditos 'amigos' ou clientes não podem responder legalmente e tecnicamente pelo provedor/empresa.
3- Verificar se o provedor/empresa possui um domínio devidamente registrado que não faz uso de serviços e mecanismos gratuitos.
4- Preferencialmente (e não obrigatoriamente) a criação do servidor virtual deve ter o aval do administrador técnico indicado nos dados do domínio.
5- Verificar se o subdomínio irc.domínio.estenção está apontando para o endereço irc.brasnet.org ou UF.brasnet.org (onde UF é a sigla do estado do servidor).
6- Tomar nota do e-mail oficial para contato, nome do responsável técnico, nome do provedor, cidade, estado, endereço completo, telefone para contato, telefone de conexão e IPs dial-up.

Triagem para servidores físicos:
1- Verificar se o servidor pertence a um provedor de acesso à internet ou empresa de telecomunicações.
2- Verificar se quem está fazendo contato é funcionário ou dono do provedor. Os ditos 'amigos' ou clientes não podem responder legalmente e tecnicamente pelo provedor/empresa.
3- Verificar se o provedor/empresa possui um domínio devidamente registrado que não faz uso de serviços e mecanismos gratuítos.
4- Preferencialmente (e não obrigatoriamente) a criação do servidor físico deve ter o aval do administrador técnico indicado nos dados do domínio.
5- Verificar se o provedor/empresa dispõe de um link igual ou superior à 2mb/s e uma máquina linux/freebsd disposta exclusivamente para o servidor de IRC.
6- Tomar nota do e-mail oficial para contato, nome do responsável técnico, nome do provedor, cidade, estado, endereço completo, telefone para contato, telefone de conexão e IPs dial-up.

Se qualquer um desses itens não for atendido pelo servidor candidato à adesão, a triagem o desclassifica como candidato e o mesmo deixa de ser encaminhado. Mas na eventualidade de todos esses itens serem atendidos, os dados do procedimento de triagem número 6 devem ser encaminhados para o e-mail billy@brasnet.org para que se dê continuidade ao processo de candidatura à adesão. Vale ressaltar que não há sentido em fazer qualquer tipo de encaminhamento que não seja para adesão ou se o candidato a servidor não atende as exigências desta triagem.

Status: Ativo


Resolução: 7RE
Título: Mau uso dos procedimentos 1US e 2US.
Data & Hora: 17/06/2003 @ 22:34
Expira: Sendo criado o procedimento 5CO, esta resolução expira na versão 1.0 do IPPK.
Descrição: Uma das motivações do IPPK é promover o compartilhamento de minhas idéias com colaboradores, voices e operadores. Porém tenho ficado consternado com as reclamações que tenho recebido e as constatações que tenho feito sobre o mau uso dos procedimentos 1US e 2US. A intenção desses dois procedimentos, além de desveicular do suporte da BRASnet questões que nada tem a ver com o IRC, oferecer uma resposta mais completa através de um site ou canal especializado. Nenhuma resposta dentro do #Ajuda irá superar todas as explicações oferecidas em um site especializado no assunto ou um canal mais apropriado para isso.

Porém essa não é a minha maior preocupação. Se eu não gostasse de ajudar, não estaria no canal #Ajuda. Seria um imenso prazer poder responder as dúvidas de outros assunto, porém quanto mais se responde perguntas de outros assuntos, maior será o volume dessas perguntas. Fato que o nível de saturação do canal não permite. Sendo o #Ajuda um canal oficial, eu o entendo como um canal de atendimento e suporte da BRASnet. Qualquer outro tipo de pergunta que venha a comprometer o atendimento dos usuários da BRASnet, ao meu ver, deve ser evitada tendo em vista a atual realidade do canal. Vale ressaltar também que a BRASnet não pode se responsabilizar por serviços e produtos oferecidos por empresas, comunidades ou grupos.

O que lamentavelmente tem ocorrido é o uso inadequado dos procedimentos 1US e 2US, fora das descrições acima. Infelizmente, para qualquer tipo de pergunta em que não saibam, muitos colaboradores estão usando as mensagens dos procedimentos em questão até para assuntos da própria BRASnet ou instruções simples sobre o uso do mIRC que deveriam ser respondidos no canal.

Com os motivos expostos, espero que daqui em diante um bom uso seja feito destas mensagens. O IPPK não deve ser utilizado como pretexto para imperícia e omissão. Na eventualidade desses problemas persistirem, um procedimento prevendo ações que impeçam o mau uso do 1US e 2US serão adicionados no IPPK. Qualquer dúvida sobre o uso destes procedimentos e de todo o IPPK, não hesitem em entrar em contato via kurtkraut@brasnet.org

Status: Ativo


Resolução: 8RE
Título: Requisitos sugeridos para um atendente do #Ajuda
Data & Hora: 24/06/2003 @ 22:17
Expira: não expira
Descrição: Muitos usuários que pretendem colaborar com o #Ajuda e a BRASnet me perguntam quais são os requisitos mínimos de um colaborador. Eu tracei um perfil mínimo e ideal de um atendente do #Ajuda e expus nessa resolução como sugestão. O propósito é apontar algumas habilidades, competências e conhecimentos de uso freqüente no #Ajuda para que os colaboradores possam se preparar e se aperfeiçoar melhor. Vale lembrar que esta resolução como todo IPPK está passível de atualizações e alterações, portanto fique atento às novidades. Estão enumerados abaixos 3 eixos do perfil de um atendente ideal: Aptidões, Habilidades e Competências; Conhecimentos, Tecnologias e suas Aplicabilidades Genéricos e Conhecimento, Tecnologias e suas Aplicabilidades Específicas. Confira:

1- Aptidões, Habilidades e Competências.
Das Aptidões, Habilidades e Competências que um atendente do canal #Ajuda possa ter, as listadas abaixo são fundamentais:

Aptidões, Habilidades e Competências Lingüisticas: capacidade de inferir, adaptar, analisar, relatar, sintetizar, contrastar e interpretar textos, mensagens, documentações e manuais. Também o atendente deve ser capaz de diferenciar ambiguidades, possuir o poder de argumentação e explanação didática. Reconhecer sintaxes e usá-las de acordo com uma documentação. Além disso, o conhecimento das formas polidas, educadas e respeitosas da Língua Portuguesa e sua instrumentabilidade.

Aptidões, Habilidades e Competências Matemáticas: noções de proporção, grandeza e álgebra. Capacidade de interpretação de gráficos e dados estatísticos. Conhecimento das operações aritiméticas de soma, substração, multiplicação e divisão com algarismos pertencentes ao grupo dos números reais. Conhecimento das unidades de armazenamento como bit, byte kilobyte, megabyte, gigabyte, seus respectivos valores e conversões.

Aptidões, Habilidades e Competências Morais: noções de ética, respeito, hieriarquia, dignidade e cidadania para que se possa reconhecer, aplicar e exigir o uso destas prerrogativas. Reconhecimento e uso de valores morais e humanísticos.

Aptidões, Habilidades e Competências de atendimento: estar apto a identificar problemas, solicitar mais informações, diagnosticar e orientar o usuário sobre como resolver o problema ou sanar uma dúvida. Caso o problema exija uma apuração, o atendente deve ser capaz de investigar o problema, entrar em contato com os responsáveis ou especialistas e dar um retorno (FEEDBACK) ao usuário. Também o atendente deve ter a habilidade de conduzir, gerenciar e operar o atendimento no canal em situações de congestionamento ou emergência e tomar medidas apropriadas para que o atendimento em massa seja normalizado. Nessas situações, o atendente deve estar apto a agir com tranqüilidade e agilidade respondendo pela BRASnet e seus serviços.

2- Conhecimentos, Tecnologias e suas Aplicabilidades Genéricos.
Dos Conhecimentos, Tecnologias e suas Aplicabilidades Genéricos que um atendente deve ter e saber fazer uso, os listados abaixo são fundamentais:

Conhecimentos, Tecnologias e suas Aplicabilidades em Computação: noções do funcionamento de um microcomputador e seus componentes como processador, memória, CPU, BIOS entre outros. Noções da diferença entre componentes lógicos (SOFTWARE) e físicos (HARDWARE). Capacidade de aplicar estes conhecimentos na identificação da origem de um problema físico de um microcomputador.

Conhecimentos, Tecnologias e suas Aplicabilidades em Informática: noções de informática, informações, dados, banco de dados, sistemas operacionais e aplicativos. Estes conhecimentos devem ser aplicados no processamento de dados, instalação e desinstalação de sistemas operacionais e seus aplicativos bem como a configuração dos mesmos. Capacidade de aplicar estes conhecimentos na identificação e solução um problema lógico de um aplicativo ou sistema operacional.

Conhecimentos, Tecnologias e suas Aplicabilidades em Telecomunicações: noções de telecomunicações, BACKBONES, roteamentos, internet e seus meios de conexão (discada, ISDN/ADSL, rádio, satélite e etc). Conhecimento geral sobre o funcionamento do protocolo TCP/IP, números de IP e funções como PING, TRACE. Conhecimento das diferenças entre a internet e uma rede local. Conhecimento suficiente para uso ou identificação de tecnologias como HTTP(S), FTP, STMP/POP3 e DNS. Conhecimento do funcionamento de registro de domínios, propagações de endereço, redirecionamentos e uso das ferramentas de WHOIS nos serviços da FAPESP e INTERNIC. O atendente deve aplicar esses conhecimentos na identificação e resolução de problemas no ambiente de usuário ou fazer os devidos encaminhamentos e orientações se o problema se encontra em provedores de acesso, empresas de telecomunicações ou outros serviços.

3- Conhecimento, Tecnologias e suas Aplicabilidades Específicas.
Dos Conhecimentos, Tecnologias e suas Aplicabilidades Específicas que um atendente deve ter e saber fazer uso, os listados abaixo são fundamentais:

Conhecimento, Tecnologias e suas Aplicabilidades em clientes de IRC: saber identificar os clientes mais comuns como mIRC, pIRCH, BitchX, XChat, KVirc e Webchat da BRASnet, seus respectivos sistemas operacionais, características gerais e problemas comuns no acesso à BRASnet através destes clientes e suas respectivas soluções. Conhecer os mais usados comandos de usuário, todos os recursos do IRCd da BRASnet e seus serviços (SERVICES) gratuitos e não-gratuitos, problemas comuns e as respectivas soluções.

Conhecimento, Tecnologias e suas Aplicabilidades no mIRC: Conhecer todos os comandos do programa ou estar apto a consultar a documentação disponível. Estar apto a realizar todas as configurações possíveis no programa, através dos menus acessíveis pelos atalhos ALT+O, ALT+B, ALT+S, ALT+C, ALT+K, ALT+V, ALT+I, e ALT+A. Conhecer problemas comuns no acesso à BRASnet, no uso de DCCs e suas respectivas soluções.

Conhecimento, Tecnologias e suas Aplicabilidades em rotinas (SCRIPTING) do mIRC: Conhecer e identificar o funcionamento geral de uma rotina, estar apto a ativa-la ou desativa-la (/LOAD, /UNLOAD, /REMOTE ON e /REMOTE OFF). Conhecer, identificar e diferenciar ALIASES, REMOTES e variáveis (VARIABLES). Conhecer o funcionamento dos códigos maliciosos mais comuns e poder orientar os usuários como previnir e remediar problemas dessa ordem. Identificar e solucionar conflitos mais comuns entre rotinas e o IRCd ou os serviços da BRASnet.

Conhecimento, Tecnologias e suas Aplicabilidades no sítio (SITE) da BRASnet: Conhecer todo o conteúdo do site, suas divisões, redirecionamentos, atalhos e endereços. Conhecer todo o funcionamento do Perfil (http://perfil.brasnet.org), seu uso geral, problemas comuns e suas respectivas soluções. Estar apto a dar orientações sobre as solicitações de serviços não-gratuitos e seus respectivos meios de pagamento. Conhecer toda a documentação publicada, de suporte e regras e estar apto a indicá-las a qualquer momento.

Status: Ativo.


Resolução: -
Título: -
Data & Hora: -
Expira: -
Descrição: -
Status: -

[5.0] Histórico

v0.82: Atualização da resolução 8RE.
v0.82: Adicionado projeto 4PRO (NOMA).
v0.82: Adicionado procedimento 4CA.
v0.82: Correções ortográficas no procedimento 5US.
v0.82: Atualizada ação do procedimento 7US.
v0.82: Atualizada a tolerância do procedimento 3CO.
v0.82: Atualizado o status do procedimento 1PRO.
v0.82: Versão finalizada em 29/12/2003 às 21:15 com 128kb.
v0.81: Atualização do 1CA.
v0.81: Correção léxica no 2CA.
v0.81: Nova edição e reativação do procedimento 7US.
v0.81: Nova ação para o procedimento 1CO.
v0.81: Corrigidos os links do projeto 1PRO.
v0.81: Retirado o item 'Aptidões, Habilidades e Competências Motoras e Físicas' da resolução 8RE.
v0.81: Atualizada resolução 6RE.
v0.81: Corrigido contador de visitas.
v0.81: Adicionado item 5.1.
v0.8 Adicionado item de Listas 1.3.
v0.8: Nova geração de versões: letras identificam correções e atualizações - números identificam novo conteúdo
v0.8: Adicionado formulário 1FOR.
v0.8: Criado item de formulários 1.2.
v0.8: Versão finalizada em 28/06/2003 às 02:53 com 112kb
v0.76: Adicionados 6 BANs para nicks ofensivos no item 3.1.
v0.76: Atualizado o 'Expira' da resolução 7RE.
v0.76: Nova resolução 8RE e novo procedimento 5CO.
v0.76: Correção ortográficas na resolução 4RE (agradecimentos ao _virus).
v0.76: Versão finalizada em 26/06/2003 às 13:05 com 109kb
v0.75b: Nova resolução 7RE.
v0.75b: Nova ação no procedimento 2US.
v0.75b: Versão finalizada em 18/06/2002 às 22:04
v0.75a: Correções ortográficas e de digitação nas resoluções 2RE e 3RE.
v0.75a: Correções ortográficas e de digitação nos projetos 1PRO, 2PRO e 3PRO.
v0.75a: Correções ortográficas e de digitação nos procedimentos 1CA, 2CA, 1CO.
v0.75a: Correções ortográficas e de digitação nos itens 1.0, 2.2, 3.0, 3.1 e 5.0.
v0.75a: Novo evento para o procedimento 2CO e nova tolerância para o procedimento 4CO.
v0.75a: Novas ações nos procedimentos 3CA, 4US, 8US, 9US, 2CO e 4CO.
v0.75a: Novo parágrafo no item 1.0.
v0.75a: Adicionado os bans _I_*!*@*, *_I_!*@* e *_|_*!*@* no item 3.1 (agradecimentos ao _virus).
v0.75a: Adicionado dos bans no item 3.1.
v0.75a: Alterado o modo de descendência de versões. De números decimais agora letras passam a indicar versões com pequenas alterações do IPPK.
v0.75a: Versão finalizada em 16/06/2003 às 17:20
v0.75: Adicionados o procedimento 6RE e 3PRO.
v0.75: Correções na resolução 1RE.
v0.75: Melhorado sistema de navegação para procedimentos, projetos e resoluções: http://ippk.kurtkraut.cjb.net/1ca redireciona para o procedimento 1CA e assim por diante.
v0.75: Versão finalizada em 06/06/2003 às 22:48 com 90kb
v0.7: Adicionadas as resoluções 1RE, 2RE, 3RE, 4RE e 5RE.
v0.7: Criado o item de resoluções 4.1
v0.7: Nova pergunta adicionada no FAQ do 2PRO.
v0.7: Adicionadas âncoras de navegação de procedimentos, projetos e itens - http://ippk.kurtkraut.cjb.net/index.html#item aponta para o item indicado, como 31 para o item 3.1, 10us para o procedimento 10US e 2pro para o projeto 2PRO.
v0.7: Versão finalizada em 05/06/2003 às 12:59 com 83kb
v0.612: Nova tolerância para o item 4CO.
v0.612: Correção ortográfica no procedimento 3CO.
v0.612: Novos evento e tolerância no procedimento 8US.
v0.612: Correção de concordância no item 1.0.
v0.612: Adicionadas introduções nos itens 2.2 e 2.3.
v0.612: Lançado novo pacote do HPREV e adicionado FAQ no projeto 2PRO.
v0.612: Versão finalizada em 30/05/2003 às 16:32 com 70kb
v0.611: Correções ortográficas e atualização da descrição do projeto 2PRO (agradecimentos ao shoes).
v0.61: Adesão do projeto 2PRO.
v0.61: Adicionado links no item 5.0.
v0.61: Atualizada Ação do procedimento 3CA (agradecimentos ao Delegad0)
v0.61: Correção ortográfica no item 5.0.
v0.61: Versão finalizada dia 17/05/2003 às 01:11
v0.6: Adesão do procedimento 10US.
v0.6: Novo evento no procedimento 2CO.
v0.6: Nova tolerância e novo evento para o procedimento 8US.
v0.6: Novas tolerâncias nos procedimentos 2CA e 3CO.
v0.6: Correções ortográficas nos procedimentos 1US, 3US, 2CA e no item 5.0.
v0.6: Ativados os procedimentos 1CA, 1US e 2US.
v0.6: Substituição do título 'O que há de novo na versão' por 'Histórico' no item 5.0.
v0.6: Adicionado os créditos da frase de Camões no item 3CO.
v0.6: Correção em alguns eventos de BAN do item 3.1, duas adesões e uma remoção.
v0.6: Alterado o nick do bot de Helpinho para lmt nos itens 3.0 e 3.1.
v0.6: Alterada nota no item 1.0 e introdução do item 3.0.
v0.531: Adicionado contador de visitas no fim do documento com valores indicados pelo serviço kit.net.
v0.531: Adicionado o segundo parágrafo da Introdução.
v0.531: Desativado os procedimentos 1US e 2US a pedido da Equipe de Masters do #Ajuda.
v0.53: Atualização do status de 1PRO.
v0.53: Correções léxicas, ortográficas e concordâncias (agradecimentos ao site www.lol.pro.br).
v0.52: Correções léxicas, ortográficas e Atualização em 1PRO.
v0.52: Correção ortográfica no item 3.1.
v0.52: Correção léxica do item 3.0.
v0.52: Correção léxica do 3CO.
v0.52: Correção léxica do 2CO.
v0.52: Atualização do 1CO.
v0.52: Atualização do 9US.
v0.52: Atualização do 8US.
v0.52: Correção léxica em 4US.
v0.52: Correção ortográfica na Introdução (agradecimentos ao |MALA|).
v0.52: Correções ortográficas em 1CA.
v0.51: Adesão do 1PRO (agradecimentos a Manuela, Kabelo e _virus pelas discussões, sugestões e apoio).
v0.51: O item 1.1 foi movido para o 5.0.
v0.51: Adesão do item 0.0.
v0.5: Correção ortográfica em 2CA (agradecimentos ao fbs).
v0.5: Adesão do 9US.
v0.5: Adesão do 4CO (agradecimentos ao badw0lf pelas discussões sobre o assunto).
v0.5: Nova versão do 1CA (agradecimentos ao canzil pela sugestão).

[5.1] Licenças

O IPPK pode ser livremente usado e adaptado em outras redes/canais desde que os seguintes critérios sejam atendidos:

1- O grupo ou pessoa que pretende utilizar o IPPK deve manifestar este desejo pelo endereço eletrônico kurtkraut@brasnet.org, fornecendo informações sobre o local de uso do IPPK, suas características e intenções.
2- Receber do autor do IPPK uma autorização para o uso do material intelectual alheio.
3- Indicar no IPPK copiado ou adaptado o link original deste IPPK, a versão na qual se baseou, e os devidos créditos (nome do autor do IPPK original, correio eletrônico e etc.).
4- Estar devidamente listado neste item como cópia/adaptação autorizada.

Cópias e Adaptações autorizadas do IPPK

[página inicial]

acessos desde abril/2003

[M.A.G.I © - MCMXCIX/MMIII - Thiago Ayub (KurtKraut)]