Directives de Soumission de Plugins Ore

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 inclure ni version, slogan ou autre description. Ce nom doit être unique et ne doit pas faire penser que c’est un projet officiel de Sponge.

Exemples de noms qui ne sont pas acceptables:

  • SpongeWarp

  • SpongeHome

  • SpongeEssentials

  • SpongeCloud

Exemples de noms acceptables:

  • CoolWarps-Sponge

  • MoneyMiner-Sponge

  • Golfball-for-Sponge

  • Calendar-for-Sponge

Page de Documentation Principale (Accueil)

C’est la première page que tout le monde en visitant votre projet. Il devrait y avoir une description claire et concise des caractéristiques et des objectifs de votre projet. Les éléments suivants, s’ils sont présents dans votre plugin, devraient être documentés sur la page principale, le cas échéant :

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

Exemples de systèmes qui ne nécessitent pas de documentation :

  • Base de données locale ou connexions de base de données spécifiées par l’utilisateur final

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 modifient le code de minecraft durant l’exécution, (comme les coremods et les mixins) doivent rendre clair les modification effectuées et la raison pour laquelle ils en ont besoin. Les plugins Sponge doivent utiliser le plus possible SpongeAPI. Les implémentations de Sponge peuvent implémenter des contraintes techniques pour empêcher de telles modifications d’être appliquées par défaut. Il n’est pas autorisé de tenter d’éviter ces restrictions, mais vous pouvez notifier l’utilisateur que certaines fonctionnalités peuvent être activées via la configuration de 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).

Metrics (Collection de données)

Dès que des données à propos du serveur (souvent nommées « stats » ou « metrics », comme la version du serveur ou du plugin ainsi que des informations sur leur utilisation) est envoyée à un service externe, le plugin doit d’abord l’indiquer au MetricsConfigManager. La documentation sur comment procéder se trouve ici. Cette API doit être vérifiée à chaque fois qu’une information est envoyée, pas juste une fois. Les plugins ne doivent pas modifier les valeurs que l’API retourne, mais peuvent inviter l’utilisateur à activer la collecte et l’envoi de ces informations pour leur plugin.

Note

Cette API a été ajoutée en 7.1.0. Les plugins compilés sur des versions antérieures doivent vérifier une variable stockée dans un fichier de configuration propre à ce plugin pour permettre d’activer ou désactiver la collecte de données, celle-ci doit être désactivée par défaut.

Exécution du Code Téléchargé

Nous ne pouvons pas nous assurer que le contenu téléchargé et exécuté à l’exécution est sûr et conforme à nos lignes directrices. Tout projet qui effectue des téléchargements et exécute du code externe aura des avertissements sa page et un avertissement avant le téléchargement pour s’assurer que les utilisateurs aient pris connaissance des risques.

Les conditions suivantes doivent également être remplies par le projet:

  • Le contenu téléchargé doit être validé en se basant sur un hash SHA256 (ou meilleur) codé en dur

  • Le contenu téléchargé doit être expliqué dans la page principale du projet quant à ce qui est téléchargé et à quel but il sert

  • Le contenu téléchargé doit être effectué via des connexions HTTPS

  • Le contenu téléchargé ne doit pas être hébergé dans un emplacement qui limite les téléchargements (par exemple DropBox, Google Drive)

  • Le téléchargement d’un autre plugin doit passer par l’API d’Ore de la même manière que la vérification des mises à jour

Monétisation / Publicité

Toutes les fonctionnalités présentes dans votre plugin doivent être utilisables sans restrictions, et ne doivent pas demander un licence pour être utilisable. Les API externes comme les services de traduction ou de géolocalisation qui doivent être payés pour être utilisé sont autorisés mais doivent être discuté par le staff avant d’être approuvé. 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.