Directives de Soumission de Plugins Ore

Avertissement

Cette documentation est faire pour une ancienne version de SpongeAPI et n’est plus maintenue. Même si les examples de code fonctionnent toujours pour cette version de l’API, les politiques, lignes de conduite, et quelques liens peuvent avoir changé. Veuillez vous rendre sur la dernière version de la documentation pour ces derniers.

Bienvenue aux directives de soumission d’Ore. Ce document donne un aperçu de nos attentes pour les soumissions de projets et de fichiers.

Souvenez-vous que ce sont juste des directives et que l’équipe d’Ore, dénommée comme « staff » tout au long de ces directives, peut choisir d’autoriser ou d’interdire une action qui n’est pas explicitement répertoriée ici, à notre propre discrétion.

Projets

Les projets soumis doivent répondre aux attentes suivantes :

Nom

Le nom de votre projet ne doit pas inclure de version, slogan, ou autre description. Le nom doit être unique et original et ne doit pas avoir de nom l’impliquant comme un projet Sponge (par exemple SpongeWarp n’est pas autorisé, Cool Warps for Sponge l’est).

Page de Documentation Principale (Accueil)

C’est la première page que les gens verront lors de la visite de votre projet. Les informations ici devraient inclure une description des fonctionnalités du projet. Ce qui suit, si c’est présent dans votre projet, doit être documenté sur la page principale si ce n’est pas documenté autre part dans le projet Ore : Les commandes, la configuration et les nodes de permission. En outre, les informations ci-dessous doivent figurer sur la page d’accueil si c’est pertinent :

Connexions Externes

Si votre projet utilise une API web, du « phoning home » pour collecter des données, ou alors se connecte à un système externe au serveur sur lequel il est exécuté, la présence de cette fonctionnalité ainsi que les informations sur comment l’activer ou la désactiver doivent être affichés bien en évidence sur la page d’accueil. Si les seules fins de votre projet impliquent l’utilisation d’un système externe (comme un plugin Sponge qui traduit le chat entre plusieurs langues), une option de configuration pour activer/désactiver les connexions à ce service n’est pas requise. Si votre plugin envoie des informations (par exemple, la liste des plugins ou les données de joueurs), le informations collectées doivent être listées sur la page principale.

Exemples de systèmes qui nécessitent une documentation :

  • Statistiques ou collecte d’informations sur l’utilisation (’metrics’)

  • Géolocalisation

  • Service de traduction

  • Serveur Web qui s’exécute sur le plugin, servant des informations aux utilisateurs

  • Serveur qui s’exécute sur le plugin, écoutant les requêtes d’autres services

  • Bot IRC/Discord/Telegram/WhatsApp ou relais

Catégorie

La catégorie que vous choisissez doit être précise. Votre projet doit utiliser la catégorie la plus étroite possible plutôt que de mettre n’importe quelle catégorie qui s’applique légèrement. Si aucune catégorie ne vous semble précise, la catégorie Miscellaneous (divers) doit être utilisée.

Monétisation / Publicité

Les soumissions ne peuvent pas être vendues, ni posséder des fonctionnalités additionnelles qui peuvent être débloqués en payant. Les publicités et autres liens générant des revenus (par exemple adfly) ne sont pas autorisés. La documentation peut contenir un lien vers une page pour faire un don au responsable du projet ou à d’autres contributeurs comme remerciement, mais la page ne peut pas offrir de fonctionnalités additionnelles ou d’autres plugins/mods à vendre.

Support « Cracké » / Offline-mode / online-mode=false

Les projets qui stipulent explicitement qu’ils sont conçus pour de tels usages ne sont pas autorisés. Certains projets, comme les systèmes d’authentification, peuvent avoir une fonctionnalité qui peut s’avérer utile pour les serveurs indépendamment de l’utilisation de l’authentification de Mojang sur le serveur, mais ils ne peuvent pas promouvoir cette utilisation supplémentaire ou être spécifiquement conçus pour les serveurs qui évitent l’auth de Mojang. Les projets pour les proxys exigeants le online-mode=false sont autorisés, à condition qu’ils ne soient pas écrits pour faciliter le contournement de la propriété de comptes Minecraft.

EULA (CLUF)

Nous sommes complètement d’accord avec l’EULA de Mojang. Tous plugins, services ou liens qui seraient soupçonnés d’enfreindre l’EULA sont susceptibles d’être supprimés sur décision du staff de Sponge ou à la requête de Mojang AB.

Forks

Les Forks sont autorisés, pourvu qu’ils respectent tous les éléments de la liste ci-desous. Le Staff a le dernier mot en ce qui constitue un fork accepté. Suivez la licence du projet parent convenablement.

Soit :

  • Il contient des changements significatifs qui justifient la création d’un nouveau projet. Ceci permet d’éviter les “J’ai changé les couleurs des messages dans le Plugin X, et maintenant je m’attribue les crédits ! », ou soit

  • Continuer un plugin qui a été abandonné, avec la preuve que l’auteur ne répond pas aux messages ou qu’il a déclaré que le projet ne sera plus mis à jour.

Remerciez ou créditez le dernier plugin et les développeurs. Essentiellement, ne prétendez pas que c’est un nouveau plugin et que c’est exclusivement votre création.

Fichiers

Les fichiers soumis doivent répondre aux attentes suivantes :

Offuscation

Un fichier qui utilise l’offuscation sera refusé sauf si il est visé par l’exception suivante :

Offuscation des NMS

Cela s’applique seulement sur les plugins qui font référence à Minecraft ou un mod Forge. Par exemple, un plugin qui utilise les Mixins ou un plugin qui est doublé d’un mod Forge (plugin hybride). À condition que les seules références offusquées soient les sources offusquées générées à l’aide de ForgeGradle ou VanillaGradle, le plugin est autorisé à procéder au processus d’examination.

Mods Core et Mixins : Modifications du Code de Base de Minecraft

Les plugins et mods qui utilisent un système qui modifie le code de base de Minecraft à l’exécution (comme les mods core et les mixins) doivent divulguer les modifications qu’ils font au code de Minecraft, et la raison de ces modifications. Les plugins Sponge doivent utiliser l’API Sponge lorsque c’est possible. Les implémentations de Sponge peuvent împlémenter des restrictions techniques afin d’éviter que de telles modifications soient appliquées par défaut. Les fichiers ne sont pas autorisés à essayer de contourner ces restrictions, mais peuvent notifier l’utilisateur qu’une fonctionnalité améliorée peut être activée via les options de configuration fournies par Sponge.

Connexions Externes (API Web, « Phoning Home », etc…)

De nombreuses grandes fonctionnalités peuvent être écrites en faisant des appels vers des systèmes externes. Ainsi que de devoir clairement être documentées dans les descriptions du projet, ce type de fonctionnalité devrait être configurable et désactivé par défaut. Si les fins de votre projet impliquent l’utilisation d’un système externe (comme un plugin Sponge qui traduit le chat entre plusieurs langues), la connexion à ce système n’a pas besoin d’être désactivable. Si votre plugin envoie des informations (par exemple la liste des plugins, des données de joueurs, ou des données de la map) à des systèmes externes, les informations collectées doivent être listées sur la page principale (voir ci-dessus).

Exécution du Code Téléchargé

C’est un risque de sécurité que nous ne tolérerons pas. Cela inclut le téléchargement de jar ou de fichiers . class, la génération de bytecode depuis les sources téléchargées, et l’exécution de scripts shell.

Monétisation / Publicité

Toutes les fonctionnalités présentes dans votre plugin doivent être utilisables sans restriction, et ne peuvent pas exiger une clé de licence pour leur fonctionnement. Les APIs externes, comme des services de traduction ou de géolocalisation, qui nécessitent un paiement pour les fonctionnalités peuvent être autorisées, mais cela doit être discuté avec le staff avant l’approbation. Les plugins ne peuvent pas être utilisés pour afficher des publicités.

Vérification de Mises à Jour

La vérification de vos mises à jour doit être effectuée en utilisant l’API Ore fournie. Votre plugin ne peut pas envoyer de lien de nulle part sauf d’Ore lorsqu’il dirige les utilisateurs du plugin pour télécharger les nouvelles versions. Notez que la vérification des mises à jours compte en tant que connexion externe, ce qui doit être documenté et pour laquelle une configuration doit exister pour la désactiver.

Accorder des Privilèges

Les plugins ne doivent pas accorder ou révoquer l’accès à des fonctionnalités à des utilisateurs ou groupes d’utilisateurs particuliers déterminés par le développeur du plugin. Cela inclue l’auteur s’accordant à lui-même un nom spécial ou lui laissant utiliser lui-même une commande spéciale. Les fonctionnalités, le cas échéant, doivent être verrouillées derrière des nodes de permission, plutôt que d’avoir les accès prédéterminés par l’auteur. Les commandes pour accorder des permissions ou rendre OP des utilisateurs spécifiques préprogrammés ne sont pas acceptables.