Diretrizes de Submissão de Plugins no Ore

Aviso

Este documento refere-se a uma versão desatualizada da SpongeAPI e não é mais mantida. As políticas, diretrizes e alguns links foram alterados. Consulta a versão mais recente da documentação, por favor.

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 (ex. SpongeWarp não é permitido, Cool Warps for Sponge é).

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

Esta é a primeira página que qualquer pessoa vê ao visitar o teu projeto. A informação aqui mostrada deve incluir uma descrição das funcionalidades do teu projeto. Os seguintes pontos, se o teu plugin os suportar, devem estar documentados na página principal se não estiverem noutro sítio do projeto: comandos, configuração, nós de permissão. Além disso, a informação abaixo deve ser documentada na página principal, se aplicável:

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

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).

Execução de código descarregado

Este é um risco de segurança que não será tolerado. Isso inclui descarregar ficheiros jar ou de classe, geração de bytecode de fontes descarregadas e scripts de shell.

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.