Diretrizes de Submissão de Plugins no Ore

Bem-vindo às diretrizes de submissão de plugins do Ore. Este documento descreve as nossas expectativas para submissões de ficheiros e de projetos.

Lembra-te que isto não passam de orientações e que a equipa do Ore, doravante chamada staff, pode escolher se aceita ou não qualquer ação que não esteja aqui explicitamente descrita segundo o seu próprio critério.

Projetos

Projectos apresentados devem satisfazer os seguintes critérios:

Nome

O nome do teu projeto não deve conter a versão, uma tag ou qualquer outra descrição. O nome deve ser único e original e não pode ter um nome a implicar que se trata de um projeto Sponge oficial.

Exemplos de nomes não são aceitáveis:

  • SpongeWarp

  • SpongeHome

  • SpongeEssentials

  • SpongeCloud

Exemplos de nomes são aceitáveis:

  • CoolWarps-Sponge

  • MoneyMiner-Sponge

  • Golfball-for-Sponge

  • Calendar-for-Sponge

Página Principal de Documentação (Home)

Esta é a primeira página que qualquer pessoa verá ao visitar o teu projeto. A informação aqui mostrada deve incluir uma descrição concisa das funcionalidades e dos propósitos do teu projeto. Se o teu plugin suportar os pontos seguintes, estes devem estar documentados na página principal, se aplicáveis:

Ligações Externas

Se o teu projeto utiliza uma Web API, faz chamadas a um servidor privado para recolher dados, ou de outra forma se liga a um sistema externo ao servidor em que está a correr, a presença desta funcionalidade, bem como informação sobre como esta pode ser ativada/desativada, deve ser bem assinalada na página principal. Se o principal propósito do teu projeto envolve a utilização de um serviço externo (como, por exemplo, um plugin do Sponge que traduz entre idiomas do chat), não é necessária a presença de uma configuração que permita desativar a criação dessas ligações. Por outro lado, se o teu plugin envia informação (como, por exemplo, uma lista de plugins ou dados dos jogadores), a informação recolhida deve ser indicada na página principal.

Exemplos de sistemas que requerem documentação:

  • Estatísticas ou recolha de informação de utilização (metrics)

  • Geolocalização

  • Serviços de tradução

  • Servidor Web que corre no plugin, fornecendo informação para os utilizadores

  • Servidor que corre no plugin, a servir pedidos de outros serviços

  • bot ou relay IRC/Discord/Telegram/WhatsApp

Exemplos de sistemas que não requerem documentação:

  • Bases de dados locais ou ligações a bases de dados especificadas pelo utilizador final

Categoria

A categoria que escolhes deve ser precisa. O teu projeto deve usar a categoria mais restritiva possível, e não uma categoria que se aplique parcialmente. Se nenhuma categoria parecer apropriada, seleciona a categoria Miscellaneous.

Monetização / Publicidade

Submissões não podem ser vendidas, nem podem haver funcionalidades adicionais desbloqueáveis mediamente pagamento. Propagandas e outros links de geração de receitas (por exemplo, adfly) não são permitidos. A documentação pode conter um link para uma página para doar para o desenvolvedor do projeto ou para outros contribuintes como agradecimento, mas essa página não pode oferecer recursos adicionais ou outros plugins/mods para venda.

Suporte para «cracked» / Modo Offline / online-mode=false

Projetos que afirmam explicitamente que são feitos para tais usos não são permitidos. Alguns projetos, como os sistemas de autenticação, podem ter a funcionalidade que pode ser útil para os servidores, independentemente do uso do servidor de autenticação da Mojang, mas eles não podem promover esse uso adicional ou ser projetados especificamente para servidores evitando Mojang auth. Projetos concebidos para proxies, que exijam online-mode=false são permitidos, desde que eles não estejam feitos de modo a facilitar a evasão de propriedade de conta de Minecraft.

EULA (Contrato de Licença de Utilizador Final)

Tencionamos obedecer integralmente ao EULA da Mojang. Quaisquer plugins, serviços, posts e/ou links suspeitos de violarem o EULA poderão ser removidos a critério do Staff, ou a pedido da Mojang AB.

Forks

Forks são permitidos, desde que cumpram todos os requisitos abaixo. O staff tem a palavra final sobre o que é um fork válido. Deves seguir a licença do projeto pai adequadamente.

Ou:

  • Contém modificações suficientes, justificando a criação de um novo projeto. Isto serve para evitar situações como: «Mudei as cores das mensagens do plugin X e agora fico com os louros!», ou

  • Continua um plugin que foi abandonado, com prova de que o autor não tem respondido a mensagens, ou afirmou que o projeto não será atualizado daí em diante.

Reconhece ou dá o devido crédito ao plugin original e aos seus desenvolvedores. Isto é, não alegues que um novo plugin é exclusivamente criação tua.

Ficheiros

Os ficheiros apresentados devem satisfazer os seguintes critérios:

Obfuscação

Um ficheiro obfuscado será recusado a menos que caia na seguinte exceção:

Obfuscação NMS

Isto só se aplica a plugins que façam referência ao Minecraft ou a um Forge Mod. Possíveis exemplos são plugins que usem Mixins ou um plugin que também seja um Forge Mod(plugin híbrido). Desde que a as únicas referências obfuscadas sejam a código fonte obfuscado gerado pelo ForgeGradle ou VanillaGradle, o plugin pode prosseguir pelo processo de revisão.

Core Mods e Mixins: Modificação do Código Base do Minecraft

Plugins e mods que usem um sistema que modifique o código base do Minecraft em runtime (como core mods e mixins) devem divulgar as edições que fizeram, bem como o motivo para as terem feito. Os plugins Sponge devem usar a SpongeAPI sempre que possível. Algumas implementações do Sponge podem ser feitas de modo a impedir que estas modificações sejam aplicadas por predefinição. Os ficheiros não podem contornar estas restrições, mas podem notificar o utilizador que há mais funcionalidades que podem ser ativadas através das opções de configuração fornecidas pelo Sponge.

Ligações externas (Web API, Phoning Home, etc.)

Há muitas funcionalidades excelentes que podem ser feitas com recurso a chamadas a sistemas externos. Para além de estarem claramente explicitadas na documentação, estas funcionalidades devem ser configuráveis e devem estar desativadas por omissão. Se o principal propósito do teu projeto envolve a utilização de um serviço externo (como, por exemplo, um plugin do Sponge que traduz entre idiomas do chat), não é necessária a presença de uma configuração que permita desativar essas ligações. Por outro lado, se o teu plugin envia informação (como, por exemplo, uma lista de plugins, dados dos jogadores, ou dados do mapa) para sistemas externos, a informação recolhida deve ser indicada na página principal (ver acima).

Metrics (Recolha de Dados)

Sempre que são recolhidas informações sobre o servidor (geralmente chamados «stats» ou «metrics», tais como versões de servidor ou de plugins, bem como estatísticas de utilização) para um serviço externo, o plugin deve primeiro consultar a API do Sponge MetricsConfigManager. A documentação sobre este procedimento pode ser encontrada aqui. Esta API deve ser consultada de cada vez que são enviados dados, e não somente uma vez. Os plugins não podem alterar os valores que a API retorna, mas podem encorajar os utilizadores a tomarem a decisão de ativarem a recolha e envio de dados para o seu plugin.

Nota

Esta API foi adicionada na API 7.1.0. Os Plugins compilados com versões mais antigas da API devem antes verificar uma variável num ficheiro de configuração único para esse plugin para saber o estado ativado/desativado, sendo que a pré-definição deve ser desativado.

Execução de código descarregado

Não conseguimos garantir que conteúdo que é descarregado e executado durante a execução é seguro e cumpre as nossas diretrizes. Qualquer projeto que execute descarregamentos durante a execução do código terá avisos na página do projeto e um aviso antes da descarga para assegurar que os utilizadores estão cientes do risco.

As condições seguintes também devem ser seguidas pelo projeto:

  • O conteúdo descarregado deve ter sempre e necessariamente a verificação de hash SHA256 (ou melhor)

  • O conteúdo descarregado deve ser explicado na página principal do projeto sobre o que é descarregado e qual o propósito que serve

  • O conteúdo descarregado deve sê-lo feito em ligações HTTPS

  • O conteúdo descarregado não pode estar alojado em sítios que possam vir a limitar as descargas (ex. Dropbox, Google Drive)

  • O descarregamento de outro plugin deve ser feito de modo que passe pela API do Ore, tal como a verificação de atualizações.

Monetização / Publicidade

Todas as funcionalidades presentes no teu plug-in devem ser utilizáveis sem qualquer restrição e não podem exigir uma chave de licença para operar. APIs externas, tais como tradução ou serviços de geolocalização, que exigem o pagamento para funcionar, podem ser permitidos, mas terão de ser discutidos pelo staff antes da aprovação. Os plugins não podem ser utilizados para exibir anúncios.

Verificação de Updates

A verificação de atualizações deve ser realizada utilizando a Ore API. O teu plugin não pode tens links para mais lado nenhum exceto para o Ore, quando direcionar os utilizadores para descarregarem uma nova versão. Nota que esta verificação de updates conta como uma ligação externa, que deve ser documentada, e para a qual deve existir uma configuração que permita desativá-la.

Concessão de privilégios

Os plugins não podem dar ou revogar acesso a funcionalidades a qualquer utilizador ou grupo com base em configurações do desenvolvedor. Isto inclui o autor dar a si próprio um nome especial ou permitirem que eles usem um comando especial. Privilégios, quando aplicável, devem ser atribuídos por intermédio de nós de permissão, e não pré-determinados pelo autor do plugin. Também não é aceite a presença de comandos para dar permissões ou OP a um conjunto de utilizadores pré-programado.