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

Your project’s submitted name should not include a version, tagline, or other description. The name should be unique and original and must not have a name implying it is an official Sponge project.

Examples of names that are not acceptable:

  • SpongeWarp
  • SpongeHome
  • SpongeEssentials
  • SpongeCloud

Examples of names that are acceptable:

  • CoolWarps-Sponge
  • MoneyMiner-Sponge
  • Golfball-for-Sponge
  • Calendar-for-Sponge

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

Plugins and mods that use a system that modifies the Minecraft base code at runtime, (such as core mods and mixins) must disclose the edits that they make to the Minecraft code, and their reasoning for them. Sponge plugins should use SpongeAPI where possible. Sponge implementations may implement technical restrictions to prevent such modifications from being applied by default. Files are not permitted to attempt to work around these restrictions, but can notify the user that enhanced functionality can be enabled via the Sponge provided configuration options.

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 (Data Collection)

Whenever data collected about the server (often referred to as « stats » or « metrics » data, such as server or plugin versions, as well as usage information) is to be sent to an external service, the plugin must first query the Sponge API MetricsConfigManager. Documentation on doing so can be found Here. This API must be checked each time data is sent, not only once. Plugins may not modify the values the API returns, but may encourage users to make the decision to enable the collection and sending of this data for their plugin.

Note

This API was added in API 7.1.0. Plugins built against older API versions must instead check against a variable in a configuration file unique to that plugin for the enabled/disabled status, which must also default to disabled.

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é

All functionality present in your plugin should be usable without restriction, and cannot require a license key to operate. External APIs, such as translation or geolocation services, that require payment for functionality can be allowed but must be discussed among staff prior to approval. Plugins may not be used to display advertisements.

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.