Pautas de Presentacion del Complemento Ore

Advertencia

This document refers to an outdated SpongeAPI version and is no longer actively maintained. The policies, guidelines, and some links have changed. Please refer to the latest version of the documentation instead.

Bienvenido a las pautas de presentación de Ore. Este documento contiene un resumen de nuestras expectativas tanto para el proyecto como para el archivo de las presentaciones.

Recuerda que estos son sólo directrices y el equipo de Ore, referido como el «personal» a través de estas directrices, puede optar por permitir o no permitir una acción que no aparezca explicitamente aquí a nuestra propia discreción.

Proyectos

Los proyectos presentados deben cumplir con las siguientes expectativas:

Nombre

El nombre de tu proyecto presentado no debería incluir una versión, lema u otra descripción. El nombre debe ser único y original y no debe tener un nombre que implique que es un proyecto de Sponge (por ejemplo SpongeWarp no se permite, Comba Fresca para Sponge si).

Pagina de Documentación Principal (Inicio)

Esta es la primera página que nadie ve cuando visita tu proyecto. La información debe incluir una descripción de las características de tu proyecto. El siguiente, si está presente en tu complemento, deberá ser documentado en la página principal si no es documentado en otra parte en el proyecto Ore: comandos, configuración y nodos de permiso. Además, la siguiente información deben estar documentada en la página principal si es relevante:

Conexiones Externas

Si su proyecto utiliza una API web, teléfonos de hogar para recopilar datos o de lo contrario se conecta a un sistema externo al servidor en el que se está ejecutando, la presencia de esta función, así como la información sobre cómo activarlo o desactivarlo debe mostrarse en un lugar destacado en la página principal. Si el único propósito de su proyecto implica utilizar un sistema externo (como un complemento de Sponge que traduzca el chat entre idiomas), una opción de configuración para hacer conexiones a este servicio no es necesaria. Si tu complemento envía información (por ejemplo, complemento reproductor o lista de datos), la información recopilada debe estar listada en la Página principal.

Ejemplos de sistemas que requieren documentación:

  • Recopilación de información estadística o de uso (‘metricas’)

  • Geolocalización

  • Servicio de traducción

  • Servidor web que se ejecuta en el complemento, sirviendo información a los usuarios

  • Servidor que se ejecuta en el complemento, escuchando las peticiones de otros servidores

  • IRC/Discord/Telegram/WhatsApp bot o relé

Categoria

La categoría que elijas debe ser precisa. Tu proyecto debe utilizar la categoría más exacta posible en lugar de cualquier categoría que aplique poco. Si ninguna categoría parece ser exacta, debe utilizarse la categoría Miscelánea.

Monetización / Publicidad

Las presentaciones no pueden ser vendidas, ni pueden tener opciones adicionales desbloqueables mediante pago. No se permiten anuncios y otros enlaces de generación de ingresos (por ejemplo adfly). La documentación puede contener un enlace a una página para donar al responsable del proyecto o a otros colaboradores como agradecimiento, pero esa página no puede ofrecer características adicionales u otros complementos/modificaciones para la venta.

“Cracked” / Offline-mode / online-mode=false Support

Los proyectos que de forma explícita declaran ser diseñados para esos usos no son permitidos. Algunos proyectos, tales como sistemas de autenticación, pueden tener una funcionalidad que puede ser útil para los servidores independientemente de la utilización del servidor de autenticación de Mojang, pero no pueden promover este uso adicional o ser diseñados específicamente para servidores evitando la autenticación de Mojang. proyectos diseñados para servidores proxy que requieren modo online = false son permitidos, siempre y cuando no estén escritos para facilitar la elusión de la propiedad de cuenta de Minecraft.

EULA

Nuestro objetivo es cumplir a totalidad con el Acuerdo de Licencia con el Usuario de Mojang. Cualquier extensión, servicio, publicación, y/o enlace que se sospeche que viole el acuerdo debe ser removido a discreción del Equipo de Sponge o a solicitud de Mojang AB.

Bifurcaciones

Las bifurcaciones son permitidas, siempre que cumplan con todos los elementos de la lista a continuacion. El personal tiene la ultima palabra en lo que constituye una bifurcación aceptada. Sigue adecuadamente la licencia del proyecto padre.

Either:

  • Contiene cambios significativos que justifiquen la creación de un nuevo proyecto. Esto es para evitar «Yo he cambiado los colores de mensaje en la extensión X ¡y ahora reclamar crédito!», o

  • Continuar una extensión que ha sido abandonada, con la prueba de que el autor no ha estado respondiendo mensajes o ha declarado que el proyecto ya no se actualizará.

Reconocer o dar crédito a la extensión anterior y los desarrolladores. Esencialmente, no afirmar que es una nueva extensión y exclusivamente su creación.

Archivos

Los archivos presentados deben seguir las siguientes expectativas:

Ofuscación

Un archivo que utiliza ofuscación será rechazado a menos que recurra bajo la siguiente excepción:

Ofuscacion NMS

Esto sólo se aplica para las extensiones que referencian a Minecraft o una modificación de Forge. Algunos ejemplos serían una extensión que use Mixins o una extensión que funcione como una modificación de Forge (extensión híbrida). Siempre que las únicas referencias ofuscadas sean para ofuscar fuentes generadas mediante ForgeGradle o VanillaGradle, la extensión puede proceder al proceso de revisión.

Las Modificaciones de Núcleo y Mixins: Modificaciones del Código Base de Minecraft

Las extensiones y modificaciones que utilizan un sistema que modifica el código base de Minecraft en tiempo de ejecución (como modificaciones de núcleo y mixins) deben revelar las ediciones que hacen al código de Minecraft, y su razonamiento para ellos. Las extensiones de Sponge deben utilizar la API de Sponge siempre que sea posible. Las implementaciones de Sponge pueden implementar restricciones técnicas para evitar que dichas modificaciones se apliquen por defecto. Los archivos no están autorizados a tratar de evitar estas restricciones, pero pueden notificar al usuario que la funcionalidad puede activarse a través de las opciones de configuración suministradas por Sponge.

Conexiones Externas (API Web, Llamar a Casa, etc.)

Muchas características geniales pueden ser escritas haciendo llamadas a sistemas externos. Además de ser claramente documentadas en las descripciones del proyecto, dicha funcionalidad debe ser configurable y estar deshabilitada de forma predeterminada. Si la unica finalidad de tu proyecto consiste en utilizar un sistema externo (como una extension de Sponge que traduce el chat entre idiomas), la conexión a este sistema no necesita ser desactivable. Si tu extensión envía información (por ejemplo una lista de extensiones, datos del jugador o datos del mapa) a sistemas externos, la información recopilada debe estar listada en la página principal (véase arriba).

Ejecución de Código Descargado

Este es un riesgo de seguridad que no toleraremos. Esto incluye descargar archivos jar o de clases, la generación de bytecode desde fuentes descargadas, y la ejecución de scripts de shell.

Monetización / Publicidad

Toda funcionalidad presente en tu extensión debe ser usable sin restricción, y no puede requerir una clave de licencia para operar. APIs externas, como servicios de traducción o geolocalización, que requieran pago para su funcionalidad pueden ser permitidas pero deben ser discutidas con el personal antes de su aprobación. Las extensiones no deben ser usadas para mostrar publicidad.

Actualización de Revisión

La comprobación de actualizaciones se debe realizar mediante la API proporcionada por Ore. La extensión no puede enlazar a otro lugar que no sea Ore al dirigir a los usuarios de tu extensión para descargar nuevas versiones. Ten en cuenta que esta comprobación de actualizaciones cuenta como una conexión externa, que debe estar documentada y para la que debe existir una configuración para ser deshabilitada.

Concesión de Privilegios

Las extensiones no deben conceder o denegar el acceso a características a ningún usuario o grupo de usuarios en particular determinados por el desarrollador de la extensión. Esto incluye al autor concediéndose a si mismo un nombre especial o permitiéndose usar un comando especial. Las características, cuando sea aplicable, deberían bloquearse a través nodos de permiso, en lugar de que el acceso sea predeterminado por el autor. Comandos para otorgar poderes o permisos pre-programados a ciertos usuarios no son aceptables.