Governança

OSIRIS JSON é um Open Standard pensado para ser revisável de forma aberta e guiado pela comunidade.
Esta página explica como mudanças são propostas, revisadas e publicadas.

[!Info] Modelo atual de manutenção Atualmente, o OSIRIS JSON é mantido por uma única lead maintainer. Contribuições são bem-vindas desde o início, mas o processo é intencionalmente leve para manter a v1.0 administrável e consistente.

Papéis

Maintainer

Responsável pela qualidade e coerência do texto da especificação, schemas, producers, exemplos e release notes. Garante que as mudanças preservem vendor-neutrality, clareza e expectativas de compatibilidade.

Contributor

Propõe melhorias por meio de issues e pull requests: correções, esclarecimentos, novos exemplos, novos producers e orientações de implementação.

Reviewer

Membros da comunidade que fornecem visão técnica, revisão e feedback. A revisão é especialmente valiosa para mudanças normativas e impactos de versionamento.

Onde as decisões acontecem

GitHub discussions: discussões de design, perguntas e feedback inicial.
GitHub issues: bugs, inconsistências e propostas para mudar a especificação.
Pull requests: o local autoritativo onde texto, schemas e exemplos são alterados e revisados.

Princípios de tomada de decisão

OSIRIS JSON segue os princípios de design da especificação com foco em:

Simplicidade
Neutralidade em relação a vendors
Extensibilidade sem fragmentação
Explícito em vez de implícito
Estabilidade e compatibilidade

O modelo padrão de decisão é rough consensus por meio de discussão pública e revisão. Quando não é possível alcançar consenso, a lead maintainer toma uma decisão e documenta a justificativa na PR ou issue.

Processo de mudança

Discutir

Abrir uma issue (ou discussion) descrevendo o problema e a mudança pretendida

Implementar

Enviar uma PR atualizando o texto da spec e, quando aplicável, schemas/examples

Revisar

Revisar correção, consistência e impacto na compatibilidade

Merge & release

Mudanças incorporadas são publicadas de acordo com SemVer e regras de depreciação

Tipos de mudanças

Editorial (não normativa)

Corrigir typos, melhorar clareza, reestruturar seções, melhorar exemplos sem alterar requisitos.

Normativa

Mudanças que alteram requisitos ou interpretação (regras MUST/SHOULD/MAY), comportamento de validação ou expectativas de compatibilidade. OSIRIS JSON usa o formato JSON amplamente suportado e se alinha a convenções estabelecidas, incluindo JSON Schema para validação estrutural e palavras-chave da RFC 2119 para requisitos normativos.

Taxonomy / registry / orientações de extensão

Atualizações que afetam a interpretação de tipos padrão, namespaces recomendados ou melhores práticas para extensões.

Versionamento, compatibilidade e releases

OSIRIS JSON usa Semantic versioning 2.0.0 para releases da especificação.
O campo version em um documento OSIRIS JSON declara a qual versão da especificação ele está em conformidade, e espera-se que producers/consumers sigam o comportamento de compatibilidade descrito na spec.

Versões draft e pre-release

Durante o desenvolvimento, versões MAY usar a notação de pre-release do SemVer (por exemplo, 1.0.0-DRAFT). Versões draft/pre-release não são consideradas estáveis e podem mudar de forma incompatível até que uma release estável seja publicada.

Política de depreciação

Features deprecated seguem um ciclo de vida definido: anúncio, documentação + orientação de migração, período de transição (pelo menos um ciclo MINOR) e remoção apenas na próxima release MAJOR.

Governança de extensões

OSIRIS JSON define as namespace rules e, quando aplicável, a política de registry para prefixos de extension namespace bem conhecidos, mas não governa a semântica interna de extensões de vendor/organização. Consumers devem tratar valores dentro de extensões como opacos, a menos que deem suporte explícito àquele namespace.

Registro de namespace (v1.0)

Para o OSIRIS JSON v1.0, o registro de namespace é informal e orientado pela comunidade:

Documentar publicamente o uso do namespace
Publicar extension schemas para referência de consumers (quando aplicável)
Coordenar com a comunidade OSIRIS JSON para evitar colisões

Namespaces recomendados

Organization namespaces devem usar padrões reverse-domain (por exemplo, osiris.com.<org>) para reduzir colisões.
osiris.custom.* pode ser usado para experimentos de curta duração e drafts da comunidade, mas não é resistente a colisões. Producers devem migrar para organization namespaces em usos persistentes/de produção.

Código de Conduta

A participação na comunidade OSIRIS JSON é regida pelo Code of Conduct.
Read the Code of Conduct