GitHub de órgão público não é balcão: onde reportar bug e onde pedir serviço

O processo da pessoa está parado há dois meses. Ela descobre que o sistema do órgão é código aberto e está no GitHub, abre uma issue, anexa o PDF do processo com nome, CPF e endereço e escreve "favor resolver". Em minutos, todo mundo que acompanha o repositório recebe aquilo por e-mail. O repositório é código, não balcão de atendimento, e o dado ficou público no lugar errado. A resposta curta: issue serve para reportar defeito no software, sem nenhum dado pessoal. Pedido de serviço, reclamação e andamento de processo vão pelo canal oficial do órgão, como a ouvidoria.

Isso vale para quem é cidadão e para quem é desenvolvedor. Muitos devs usam o mesmo atalho para pedir ajuda com integração, colando token e dados de teste reais. O efeito é o mesmo.

Por que o GitHub do órgão não atende o seu pedido

Quando um órgão publica código, o objetivo costuma ser transparência, reuso por outros entes públicos e colaboração técnica. Quem cuida do repositório geralmente é um time de desenvolvimento, às vezes uma equipe pequena ou terceirizada. Essas pessoas não têm acesso ao seu processo, não são a área que decide sobre ele e muitas vezes nem sabem a qual unidade encaminhar.

Já o canal oficial tem obrigação de registrar, dar número de protocolo e responder. Uma issue não gera nada disso. Ela pode ficar meses sem resposta, ser fechada por estar fora do escopo ou simplesmente ignorada, e você não tem como cobrar.

O problema mais grave é a exposição. Uma issue num repositório público é visível para qualquer pessoa, indexada por buscadores e notificada por e-mail a quem acompanha o projeto. Apagar depois reduz o dano, mas não desfaz as cópias já enviadas.

Onde vai cada coisa

• Andamento de processo, pedido de serviço, reclamação: canal de atendimento do órgão. No governo federal, a plataforma Fala.BR concentra manifestações de ouvidoria e pedidos de acesso à informação. Estados e municípios têm suas próprias ouvidorias.
• Dúvida sobre como usar o sistema como cidadão: central de atendimento ou página de ajuda do serviço.
• Defeito no software, sugestão técnica, dúvida sobre o código: issue no repositório, se o projeto aceitar. Leia o README e o arquivo de contribuição antes.
• Falha de segurança: nunca em issue pública. Procure se o projeto tem política de segurança ou canal específico para reporte responsável e use esse caminho.

Como abrir uma issue útil e sem dado pessoal

O exemplo é o Rafael, desenvolvedor numa prefeitura que reutiliza um sistema publicado por um órgão federal. Ele encontrou um erro na geração de relatórios e quer reportar.

1. Leia o README e o CONTRIBUTING. Muitos projetos dizem lá se aceitam issues, em que formato e onde ficam os canais de suporte.
2. Procure issues parecidas, abertas e fechadas. O defeito pode já estar resolvido numa versão mais nova.
3. Reproduza com dados fictícios. Crie um registro de teste com nome "Fulano de Teste" e CPF de teste gerado para desenvolvimento, nunca o de uma pessoa real.
4. Informe versão e ambiente. Tag ou commit usado, banco de dados, sistema operacional.
5. Cole o log revisado. Antes de colar, procure e troque nomes, documentos, e-mails, tokens, senhas e endereços internos.
6. Releia como se fosse um estranho. Se alguém de fora pudesse identificar uma pessoa ou acessar um sistema com o que está ali, edite antes de enviar.

Modelo de issue

Título: Relatório mensal falha com erro 500 quando o período tem mais de 31 dias

Versão: tag v4.2.1 (commit abc1234)
Ambiente: PostgreSQL 16, servidor Linux, instalação via Docker

Passos para reproduzir:
1. Criar unidade de teste "Unidade Exemplo"
2. Cadastrar 3 registros fictícios entre 01/01 e 15/02
3. Gerar relatório de 01/01 a 15/02

Esperado: relatório com 3 registros
Obtido: erro 500

Trecho do log (dados removidos):
  ERROR: date out of range for period filter
  at RelatorioService.gerar (linha 118)

Observação: com período de até 31 dias o relatório funciona.

Repare que nada ali identifica uma pessoa ou dá acesso a um servidor. E o mantenedor tem tudo de que precisa para reproduzir.

Se o dado já foi publicado

Aja rápido. Edite a issue para remover o conteúdo e apague o anexo. Lembre que o histórico de edição de um comentário no GitHub continua mostrando a versão anterior a quem tem acesso à página, então peça ao mantenedor do repositório que apague a issue inteira ou a revisão do histórico. Se houver token ou senha, troque a credencial imediatamente, porque ela pode ter sido copiada antes da remoção. O guia sobre segredo que se troca antes de limpar explica por que a ordem importa. Se o dado era de terceiros e você trabalha num órgão ou empresa, avise o encarregado de dados da instituição.

Antes de reutilizar o código do órgão

O Rafael também precisa decidir se leva o código para produção na prefeitura. Estrela no GitHub não é atestado de que está pronto. Confira a licença, que diz o que você pode fazer e o que precisa manter. Veja a data do último commit e das últimas releases. Use uma versão marcada, não o ramo principal do dia. Leia se o projeto documenta requisitos de segurança e de instalação. O guia código público do governo não é atalho para colar no seu sistema aprofunda essa parte.

Erros comuns

• Anexar documento de processo numa issue. Nome, CPF e endereço ficam públicos, indexáveis e enviados por e-mail a quem acompanha o projeto.
• Usar a issue para cobrar andamento de serviço. Não gera protocolo nem prazo, e o pedido não chega a quem decide. Você perde tempo e não tem como cobrar depois.
• Colar log sem revisar. Tokens, senhas e endereços internos vão junto, e alguém pode usá-los antes de você perceber.
• Reportar falha de segurança em público. A vulnerabilidade fica conhecida antes da correção, e todo sistema que usa o código fica exposto.
• Apagar o texto e achar que resolveu. O histórico de edição e os e-mails de notificação continuam com a versão original.
• Reutilizar o código sem olhar licença e versão. Você pode violar a licença ou levar para produção um ramo sem manutenção.

Checklist

• O que você vai abrir é um defeito no software, não um pedido de serviço.
• Você leu o README e as regras de contribuição do projeto.
• Os dados do exemplo são fictícios, sem CPF, nome ou endereço reais.
• O log foi revisado e não contém token, senha ou endereço interno.
• Versão, ambiente e passos de reprodução estão na issue.
• Falhas de segurança vão pelo canal de reporte responsável, não por issue pública.
• Para pedido de serviço, você tem o número de protocolo do canal oficial.

Para quem cuida de dados numa instituição pequena, o guia por onde começar a adequação à LGPD ajuda a organizar a resposta a incidentes como esse. E antes de clicar em enviar: a issue que você vai abrir contém dado de alguém?