Política editorial e processo de revisão técnica

Como um guia é produzido

1. 1

   Escopo antes da escrita

   Um guia só entra na fila quando existe uma pergunta técnica concreta por trás dele, normalmente algo que aparece em projeto real ou em chamado de suporte. Assunto sem pergunta vira texto genérico, e texto genérico não é publicado aqui.

2. 2

   Escrita por quem opera

   Todo conteúdo técnico é escrito por Cesar Gargiulo, que responde pela parte técnica da OpenSourceBrasil. Não há redação terceirizada nem texto assinado por uma "equipe" sem rosto.

3. 3

   Confronto com a documentação oficial

   Cada afirmação sobre comportamento de software é conferida contra a fonte primária: documentação da Netgate para pfSense, documentação do projeto para WireGuard, OpenVPN, Suricata e HAProxy, RFCs para protocolo, NVD para vulnerabilidade, e o texto da lei mais as normas da ANPD para LGPD.

4. 4

   Versão declarada

   Procedimento de pfSense muda entre versões. Quando o passo a passo depende da versão, o guia diz contra qual versão foi escrito. Sem isso, o leitor não tem como saber se o caminho de menu ainda existe.

5. 5

   Revisão técnica datada

   A revisão técnica confere se o procedimento ainda vale na versão atual do software. Ela tem data própria, separada da data de publicação e da data de alteração de texto.

6. 6

   Correção quando erra

   Erro apontado é corrigido, e a correção altera a data de atualização. Se a mudança for relevante para quem já leu, ela é dita no próprio guia em vez de ser apagada em silêncio.

As três datas, e o que cada uma significa

Muito site trata data de atualização como enfeite de frescor. Aqui elas são três coisas diferentes e não se misturam.

Data de publicação

Quando o guia foi ao ar pela primeira vez. Nunca muda.

Data de atualização

Só muda quando o conteúdo muda de fato: seção reescrita, procedimento corrigido, informação adicionada ou removida. Ajuste de vírgula não mexe nessa data.

Data de revisão técnica

Quando alguém conferiu o procedimento contra a versão corrente do software e concluiu que continua válido. É a única data que pode mudar sem o texto mudar, porque conferir também é trabalho.

Fontes que valem aqui

O que este site sempre faz

• Autor identificado, com perfil público e trajetória conferível.
• Fonte primária citada quando a afirmação é sobre comportamento de software, protocolo ou lei.
• Versão do software declarada quando o procedimento depende dela.
• Limite dito na cara: o que a solução não resolve e onde outra opção é melhor.
• Exemplo de rede em faixas de documentação (RFC 5737 e RFC 3849), nunca endereço real.
• Separação clara entre página comercial e conteúdo técnico.

O que este site nunca publica

• Depoimento, cliente, case ou número de projetos que não existam.
• Certificação, prêmio ou parceria que não possa ser conferida em fonte pública.
• Screenshot ou log com IP público real, hostname, domínio privado, chave ou nome de cliente.
• Promessa de segurança absoluta, risco zero ou conformidade garantida.
• Data de atualização mexida só para o conteúdo parecer novo.
• Link de referência colocado apenas para inflar a lista de fontes.
• Página publicada vazia, com aviso de "em breve" ou com conteúdo de enchimento.

Independência e conflito de interesse