Reglas de publicación de plugins
Todos los plugins publicados aquí cumplen estas reglas. Las secciones A a D se basan en las reglas de publicación de Poggit, con los mismos códigos, actualizadas para PocketMine-MP 5; la E y la F son nuestras.
Las reglas marcadas como automáticas se comprueban al subir; el resto lo comprueba un moderador. Un moderador que rechaza una versión indica qué reglas incumple.
A. Sobre el plugin
La idea del plugin. Los plugins cuyo propósito incumple estas reglas no se aceptan.
A1 Completo y útil se rechaza
El plugin tiene que estar completo y servir para algo. Puede tener partes sin terminar si están desactivadas por defecto.
A2 Un propósito concreto se rechaza
El plugin tiene que servir para algo concreto y útil para la mayoría de servidores. No se aceptan plugins "core" hechos para un servidor privado ni paquetes de funciones sin relación entre sí.
A3 Sin duplicados se rechaza
Si otro plugin de aquí ya hace todo lo que hace el tuyo, no publiques el tuyo, salvo que ese esté desactualizado y abandonado. Explica en la descripción qué aporta el tuyo.
A4 Sin ejecución de código remoto se rechaza
Los servicios externos tienen que ser de confianza o totalmente transparentes, y el plugin nunca debe poder usarse como puerta trasera. Está prohibido descargar y ejecutar código, también los actualizadores automáticos que descarguen de cualquier sitio que no sea este repositorio.
A5 El pago es opcional se rechaza
El plugin tiene que poder usarse sin pagar, al menos en un servidor pequeño (unos 5 jugadores). Un servicio externo de pago necesita un plan gratuito razonable.
A6 Las librerías son virions se rechaza
Las librerías se publican como virions, no como plugins. La única excepción son los plugins de API que hacen que otros plugins funcionen juntos; necesitan documentación clara para desarrolladores.
A7 Solo tus propios plugins se rechaza
No publiques plugins de otros sin su permiso. Para hacerte cargo de un plugin abandonado, sigue la regla F3.
B. Sobre el código
Si el código incumple estas reglas, la versión se rechaza: cambia el código y sube una versión nueva.
B1 Solo versiones de API publicadas se comprueba automáticamente se rechaza
plugin.yml solo puede indicar versiones de API ya publicadas, y solo la más antigua de cada versión mayor (5.0.0, no 5.0.0 y 5.3.0).
B2 Sin ofuscación se comprueba automáticamente se rechaza
El código tiene que ser legible. No se acepta código ofuscado ni minificado.
B3 Sin mensajes inútiles al arrancar se comprueba automáticamente se rechaza
No muestres mensajes como "plugin activado" o el nombre del autor al arrancar o parar, ni añadas comandos que solo enseñen la versión. Los avisos y errores reales sí están permitidos.
B4 Inglés por defecto se rechaza
Las traducciones son bienvenidas, pero el idioma por defecto de los mensajes y la configuración tiene que ser el inglés.
C. Sobre la compatibilidad
Para que los plugins funcionen bien juntos. Si el código incumple estas reglas, la versión se rechaza.
C1 Un espacio de nombres único se comprueba automáticamente se rechaza
Usa un espacio de nombres como AutorNombre\NombrePlugin (nunca pocketmine). Todas las clases del plugin, también las librerías incluidas, tienen que estar dentro. No lo cambies entre versiones.
C2 Comandos se rechaza
Los comandos registrados directamente en el CommandMap usan el nombre del plugin como prefijo (no iniciales), y todos los comandos implementan PluginOwned.
C3 Permisos se comprueba automáticamente se rechaza
Los nombres de permisos empiezan por el nombre del plugin y solo usan letras, dígitos, guiones y puntos.
C4 Eventos se rechaza
Elige @priority y @handleCancelled a conciencia (NORMAL si dudas), y nunca modifiques un evento con prioridad MONITOR.
C5 Archivos y datos guardados se rechaza
Escribe archivos solo dentro de la carpeta de datos del plugin (salvo gestores de plugins), no uses chdir(), y guarda los datos que el plugin añade a mundos, entidades u objetos bajo una etiqueta con el nombre de su espacio de nombres.
D. Sobre la ficha
La información de la página del plugin. Si incumple estas reglas, el moderador la devuelve: corrige el formulario y sube el mismo archivo otra vez.
D1 Una descripción detallada se comprueba automáticamente corregir la ficha
Explica qué hace el plugin y por qué es útil, sin dar por hecho que el lector conoce los términos.
D2 Descripción en inglés corregir la ficha
La descripción tiene que estar disponible en inglés. Puede incluir traducciones después.
D3 Una descripción limpia corregir la ficha
Solo información sobre el plugin: sin publicidad ni contenido ajeno. Se permiten unos pocos enlaces de contacto.
D4 Una descripción bien formateada corregir la ficha
Usa títulos, listas y bloques de código de Markdown para que la página se lea con facilidad.
D5 Un registro de cambios informativo se comprueba automáticamente corregir la ficha
Cada actualización necesita un registro de cambios que diga qué cambia para los usuarios, no líneas como "Updated README.md".
D6 Una licencia de verdad se comprueba automáticamente corregir la ficha
Elige una licencia real (un identificador SPDX como MIT, GPL-3.0 o LGPL-3.0). No se aceptan licencias informales inventadas.
E. Seguridad y privacidad
Los dueños de servidores tienen que poder fiarse de lo que instalan. Incumplir estas reglas hace que se retire la versión y puede suponer el baneo de la cuenta.
E1 Sin comportamiento malicioso se comprueba automáticamente se rechaza
Nada de puertas traseras, dar operador o permisos a escondidas, colgar o ralentizar servidores a propósito, minar criptomonedas ni ejecutar programas del sistema sin un motivo claro y documentado.
E2 Declarar el acceso a la red y los datos se comprueba automáticamente se rechaza
Si el plugin se conecta a Internet, indica en la descripción a qué servicios, para qué y qué datos envía. Las estadísticas y la telemetría tienen que ser opcionales o fáciles de desactivar, y nunca deben enviar direcciones IP, XUIDs ni el chat a terceros sin el consentimiento del dueño del servidor.
E3 Sin código oculto o generado se comprueba automáticamente se rechaza
Nada de código PHP escondido en archivos que no son PHP, ni escribir archivos PHP mientras se ejecuta, ni bloques codificados que se decodifican y ejecutan.
E4 Avisar de vulnerabilidades se rechaza
Si encuentras un problema de seguridad en tu plugin, publica pronto una versión corregida y avisa a los moderadores, para que se muestre un aviso de seguridad a los servidores que lo usan.
F. Nombres y propiedad
Los nombres de los plugins son únicos y los servidores descargan los plugins por nombre, así que los nombres se tratan con cuidado.
F1 No acaparar nombres se rechaza
No reserves nombres que no vas a usar ni uses un nombre que se haga pasar por otro plugin o autor. Los nombres que nunca se aprobaron se liberan cuando se rechazan sus versiones.
F2 Plugins de Poggit se rechaza
El nombre de un plugin publicado en Poggit pertenece a su autor en Poggit. Si otra persona lo ha cogido aquí, el autor original puede reclamarlo a los moderadores con pruebas (por ejemplo, el repositorio).
F3 Adoptar un plugin abandonado se rechaza
Un plugin se puede adoptar si lleva 14 días sin funcionar con la última API de VanillaMine, o si un fallo grave lleva 28 días abierto. Corrígelo en un fork, ofrece la corrección al autor y pídelo a los moderadores. El autor tiene 7 días para oponerse o publicar un arreglo. La primera versión adoptada solo puede actualizar el plugin, sin funciones nuevas, y tiene que respetar la licencia.
Basado en las reglas de publicación de plugins de Poggit (A-D) y en su política de adopción de plugins abandonados (F3).