En mi opinión, creo que la etiqueta Theme component serviría mejor a su propósito como subcategoría. Al menos para mí, son más fáciles de encontrar en comparación con las etiquetas, y en los últimos años, los componentes temáticos se han vuelto cada vez más significativos en contraste con sus contrapartes de Plugin (muchos de los cuales se están convirtiendo en componentes temáticos para un uso más fácil). Por falta de un término mejor, merecen… un trato “igual”. Después de todo, son extremadamente populares y son una parte integral de Discourse hoy en día.
Espero que lo tengan en consideración. No soy hablante nativo de inglés, así que disculpen mi falta de articulación.
En aras de la simplicidad, me preguntaría si tiene sentido dar un paso más para etiquetar la categoría como personalizar y luego hacer que estas cuatro etiquetas funcionen en su lugar.
Estoy de acuerdo en que los componentes de temas son un poco más valiosos para la mayoría de los sitios de Discourse en estos días.
Creo que ese lenguaje va a crear confusión. Admin->Customize es solo para temas y componentes de temas. Theme contiene todo lo que se puede introducir en un sitio a través de esa interfaz de usuario.
Ya vemos problemas ocasionales con usuarios que ponen temas en su YML e intentan agregar repositorios de git para plugins a través de la interfaz de usuario. Eliminar la delimitación solo hace que esos errores sean más probables.
Los plugins realmente necesitan permanecer en su propia categoría, ¿no?
La diferencia entre un componente temático y un plugin ya es difusa en mi cabeza. Cualquier cosa que podamos hacer para que sea más fácil para la gente saber cuál es cuál, sin duda ayudará mucho.
Esto es un poco gracioso, durante mucho tiempo los desarrolladores de WordPress tuvieron que decidir dónde incluir la funcionalidad, y se debatió sobre cuánta código pertenecía a un “tema” frente a un “plugin”. Ese debate es casi pintoresco ahora, donde todo y cualquier cosa es un bloque de JS, pero debido a su relación con el software principal, todavía tenemos que averiguar dónde va el código, en un “plugin” o en un “patrón de bloque”.
Nunca he tenido esa sensación con los plugins en Discourse, principalmente porque la gente ha ideado algunos trucos brillantes de componentes temáticos a lo largo de los años. Si alguien me preguntara cuál es la diferencia entre “plugins” y “componentes temáticos”, mi primer pensamiento sería: uno requiere un campo de URL para instalar y el otro requiere una reconstrucción del sitio.
Definitivamente estoy dispuesto a hacer una revisión de las categorías y etiquetas. Ha habido un par de buenas sugerencias sobre cómo ajustar un poco la estructura recientemente, así que recopilaré todo esto y veremos dónde aterrizamos. Creo que cualquier cosa que haga que Meta sea más intuitiva para las personas nuevas/usuarios ocasionales solo puede ser algo bueno.
Esto debería ser menos problemático ahora que hay un Moderador de Comunidad dedicado. () Creo que tener a alguien que ordene y organice a medida que avanzo debería cubrir gran parte de eso. Y tenemos un número decente de TL3 y TL4, así que espero que reforzar un patrón consistente haga que sea más fácil para otras personas unirse también.
Todavía lo pienso como cambios de Frontend versus Backend, pero la actualización a Ember ha difuminado lo que eso significa para mí ahora también. Parece que ha hecho que muchas más cosas sean posibles en un tema/componente temático que antes (lo cual es genial si estás alojado y no tienes acceso fácil para agregar un plugin ).
Creo que esa es una distinción bastante útil para los no desarrolladores. Rojo = /admin/customize, Amarillo = app.yml. Creo que eso es probablemente todo lo que realmente necesitas saber si eres un administrador que instala una personalización existente, en lugar de un desarrollador que quiere crear una nueva.
Gracias por la sugerencia @Decorbuz Reuniré algunas ideas y veremos qué podemos hacer.
La misma pregunta que si los teléfonos inteligentes son ordenadores o no. Las fronteras ya no son tan nítidas.
Por eso, cada foro debe tomar una decisión lógica sobre cómo organizar las cosas: en algún lugar debe ser por idea o uso (importan la UX y el objetivo), o son más importantes las soluciones técnicas (pensamiento basado en el desarrollo/código).
No hay soluciones correctas o incorrectas, siempre que los usuarios encuentren lo que buscan.
Bueno, de vez en cuando hay soluciones incorrectas. Mezclar plugins/temas/componentes saludables con otros rotos de tal manera que tengas que averiguar la etiqueta correcta, es una muy, muy mala idea
Y en general, hay otro error que los administradores cometen con bastante frecuencia y, si no recuerdo mal, incluso la documentación de etiquetas o similar de Meta advierte sobre ello: la categoría no genera la creación de contenido, pero las vacías o de bajo tráfico simplemente desordenan las cosas.
La falta de claridad no significa automáticamente que deban fusionarse, especialmente con el nombre que sugirió Justin anteriormente. Podríamos agregar mejores explicaciones a cada categoría y abordar parte de la ambigüedad de esa manera.
Theme y Theme component encapsulan las personalizaciones preempaquetadas que se pueden realizar en tiempo de ejecución.
Los temas Plugin requieren una reconstrucción y solo pueden ser realizados por usuarios con acceso root. Son cambios de mayor riesgo que afectan la disponibilidad del sitio.
Yo tampoco los pienso así. Si requiere algún cambio en el backend (código ruby), ya sea para almacenar algo en la base de datos o cambiar el comportamiento de alguna API, lo más probable es que necesites un plugin.
Si el cambio es solo en la interfaz de usuario, es mejor empezar con un componente de tema y recurrir a un plugin más tarde si las cosas escalan, se complican más y resultan necesarios cambios en el backend.
Me gusta esta idea. Es un poco más complicado que una sola categoría con diferentes etiquetas, pero me gusta una frontera más fuerte entre estos diferentes elementos de personalización.
Un tema puede ser solo sobre la apariencia, mientras que un plugin requiere acceso al sistema operativo de la máquina para instalarse. Son cosas muy diferentes y las categorías adecuadas permiten, por ejemplo, que el primer tema de la categoría proporcione contexto a los nuevos usuarios sobre las diferencias entre ellos. Cómo instalar, documentación de desarrollo, etc.
Cualquier cosa que podamos hacer para que sea más fácil para la gente saber cuál es cuál, sin duda ayudará mucho.
Creo que cualquier cosa que haga que Meta sea más intuitiva para las personas nuevas/usuarios ocasionales solo puede ser algo bueno.
