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.
Lembre-se 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
Os projectos apresentados devem satisfazer os seguintes critérios:
Nome
O nome do seu 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 seu projeto. A informação aqui mostrada deve incluir uma descrição das funcionalidades do seu projeto. Os seguintes pontos, se o seu 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 seu 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 seu 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 seu 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 usuários
Servidor que corre no plugin, a servir pedidos de outros serviços
Bot ou relay IRC/Discord/Telegram/WhatsApp
Categoria
A categoria que você escolhe deve ser precisa. O seu projeto deve usar a categoria mais restritiva possível, e não uma categoria que se aplique parcialmente. Se nenhuma categoria parecer apropriada, selecione a categoria Miscellaneous.
Links para descarregar
O Ore providencia, na página de cada projeto, um botão de download que escolhe automaticamente a versão mais recente. Se você desejar adicionar mais links de download, todos estes devem apontar para ficheiros hospedados no Ore. Você pode ainda adicionar links para página não aprovadas, mas não links diretos de ficheiros, mas estes links não podem ser os mais proeminentes. Além disso, você não pode tentar dar a volta a qualquer aviso de plugin no Ore, como avisos que informam que o plugin ainda não foi revisto.
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 contribuidores 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 Usuário 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
Os Forks são permitidos, desde que cumpram todos os requisitos abaixo. O staff tem a palavra final sobre o que é um fork válido. Você deve 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 créditos!”, 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 afirme que um novo plugin é exclusivamente criação sua.
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 do 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 Atualizações
A verificação de atualizações deve ser realizada utilizando a Ore API. O seu plugin não pode tens links para mais lado nenhum exceto para o Ore, quando direcionar os usuários 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 usuários 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.