En mi opinión, creo que la etiqueta Customization > Theme component cumpliría mejor 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 de tema han cobrado cada vez más importancia en contraste con sus contrapartes Customization > Plugin (muchas de las cuales se están convirtiendo en componentes de tema para facilitar su uso). Por falta de un término mejor, merecen un tratamiento «igual». Después de todo, son extremadamente populares y son una parte muy integral de Discourse en la actualidad.
Espero que lo tengas en cuenta. No soy hablante nativo de inglés, así que perdona mi falta de elocuencia.
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 generar confusión. Admin->Personalizar solo sirve para temas y componentes de tema. Customization > Theme contiene todo lo que se puede introducir en un sitio a través de esa interfaz.
Ya vemos problemas ocasionales con usuarios que ponen temas en su YML e intentan agregar repositorios de git para complementos a través de la interfaz. Eliminar la delimitación solo hace que esos errores sean más probables.
¿Los complementos realmente no necesitan mantenerse en su propia categoría?
La diferencia entre un componente del tema y un plugin ya es difusa en mi cabeza. Estoy seguro de que cualquier cosa que podamos hacer para facilitar que la gente sepa cuál es cuál será de gran ayuda.
Esto es un poco gracioso, durante mucho tiempo los desarrolladores de WordPress tenían que tomar una decisión sobre dónde incluir la funcionalidad, y se debatió cuánto código pertenecía a un “tema” versus un “plugin”. Ese debate ahora es casi anticuado, donde todo y cada cosa es un bloque de JS, pero debido a su relación con el software central, 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 con los componentes del tema a lo largo de los años. Si alguien me preguntara cuál es la diferencia entre “plugins” y “componentes del tema”, mi primer pensamiento sería: uno toma un campo de URL para instalar, y el otro requiere una reconstrucción del sitio.
Definitivamente estoy dispuesto a hacer un repaso a las categorías y etiquetas. Ha habido algunas buenas sugerencias recientemente sobre ajustar un poco la estructura, así que reuniré todo esto y veremos a dónde llegamos. Creo que cualquier cosa que haga que Meta sea más intuitiva para las personas nuevas o usuarios ocasionales solo puede ser algo positivo.
Esto debería ser menos problemático ahora que hay un Moderador de la Comunidad dedicado. () Creo que el hecho de que yo clasifique y organice a medida que avanzo debería cubrir gran parte de eso. Además, contamos con un número decente de usuarios TL3 y TL4, así que, con suerte, reforzar un patrón consistente hará que sea más fácil para otras personas unirse también.
Aún lo considero como cambios en el Frontend versus el Backend, pero la actualización a Ember ha difuminado lo que eso significa para mí ahora también. Parece que ha hecho posible muchas más cosas en un tema o componente de tema que antes (lo cual es genial si estás alojado y no tienes fácil acceso 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 implica automáticamente que deban fusionarse, especialmente bajo el nombre que Justin sugirió anteriormente. También podríamos añadir explicaciones más detalladas a cada categoría y abordar así parte de la ambigüedad.
Los temas Customization > Plugin requieren una reconstrucción y solo pueden ser ejecutados por usuarios con acceso root. Se trata de cambios de mayor riesgo que afectan a 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.
Estoy seguro de que cualquier cosa que podamos hacer para facilitar que la gente sepa cuál es cuál será de gran ayuda.
Creo que cualquier cosa que haga que Meta sea más intuitiva para las personas nuevas o usuarios ocasionales solo puede ser algo positivo.
