Política Interna de Criação de Repositórios no Github Organizations

Versão: 1.0
Data de Criação: 08/05/2025
Última Atualização: 08/05/2025

1. Objetivo

Esta política define as diretrizes para a criação, configuração e manutenção de repositórios na organização PSTG Tech no GitHub.

O objetivo é garantir organização, segurança, conformidade e alinhamento com as melhores práticas, enquanto se permite flexibilidade para equipes que utilizam diferentes tecnologias e linguagens de programação (Python, Go, Javascript, etc.), respeitando as práticas recomendadas por suas respectivas comunidades.

2. Escopo

Esta política aplica-se a todos os membros da PSTG no GitHub

3. Diretrizes Gerais

3.1. Quem Pode Criar Repositórios

• A criação de repositórios é restrita aos desenvolvedores software da PSTG e membros com a função de coordenador / gestor de infraestrutura
• Exceções podem ser concedidas para equipes ou projetos específicos, mediante aprovação prévia do time de governança de TI ou de infraestrutura

3.2. Criação de Repositórios

Os desenvolvedores que desejarem criar o repositório poderão fazê-lo livremente, no entanto, devem submeter para o e-mail

• Nome proposto para o repositório (Usar nome descritivo porém curto e objetivo) em kebab-case (ex: billing-service-api)
• Descrição do propósito do repositório
• Para que || quem || projeto destina-se esse repositório
• Necessidade a ser atendida
• Detalhes de uso (instalação, dependências, ambiente necessário, infraestrutura necessária, etc.)
• Data de validade e justfificativa (finita / infinita a depender do projeto)
• Principais linguagens de programação que serão utilizadas com justificativa
• Nome e usuário do github do responsável pelo repositório

Todas as informações acima deverão estar presentes no arquivo README.MD principal do repositório.

3.3 Sobre a manutenção do repositório:

• É responsabilidade do mantenedor garantir a segurança mínima dos dados presentes no repositório
• Nunca trabalhar em branch principal (master). Sempre criar uma branch para desenvolvimento e fazer Pull Request após passar nos testes internos (mesmo se estiver em projeto solo)
• Repositórios inativos por mais de 12 meses devem ser revistos e ações corretivas devem ser tomadas.
• Repositórios de projetos concluídos devem ter apenas um branch
• Repositórios de projetos pausados ou descontinuados, devem ter o status “pausado” / “descontinuado” presente no arquivo README.MD
• Repositórios descontinuados devem ser arquivados e marcados como obsoletos no README.
• Cada responsável por seus repositórios devem revisar os repositórios sob a sua tutela a cada 6 meses para identificar repositórios inativos, mal configurados ou não conformes com essa documentação.

3.3.1 Não subir para o repositório:

• variáveis de ambiente
• Senhas (de qualquer espécie)
• Dados pessoais seus ou de terceiros: Nome, e-mail, telefone, endereço, etc.