Na minha opinião, acho que a tag Customization > Theme component cumpriria melhor seu propósito como uma subcategoria. Pelo menos para mim, é mais fácil encontrá-las do que as tags, e nos últimos anos, os componentes de tema têm se tornado cada vez mais importantes em contraste com seus equivalentes Customization > Plugin (muitos dos quais estão sendo convertidos em componentes de tema para facilitar o uso). Por falta de um termo melhor, eles merecem… tratamento “igual”. Afinal, são extremamente populares e são uma parte muito integral do Discourse atualmente.
Espero que leve isso em consideração. Não sou falante nativo de inglês, então desculpe minha falta de articulação.
Em prol da simplicidade, eu me perguntaria se faz sentido ir um passo adiante para rotular a categoria como personalizar e, em seguida, tornar estas quatro tags.
Concordo que os componentes de tema são um pouco mais valiosos para a maioria dos sites Discourse hoje em dia.
Acho que essa linguagem vai gerar confusão. Admin → Personalizar serve apenas para temas e componentes de tema. #customização:tema contém tudo o que pode ser introduzido em um site por meio dessa interface.
Já vemos problemas ocasionais com usuários colocando temas em seu YML e tentando adicionar repositórios git para plugins por meio da interface. Eliminar essa delimitação só torna esses erros mais prováveis.
Os plugins realmente precisam permanecer em sua própria categoria, não precisam?
A diferença entre um componente de tema e um plugin já está meio borrada na minha cabeça. Qualquer coisa que possamos fazer para facilitar para as pessoas saberem qual é qual vai ajudar muito, tenho certeza.
Isso é meio engraçado. Por muito tempo, os desenvolvedores do WordPress tinham uma dúvida sobre onde incluir a funcionalidade, e havia debates sobre quanto código pertencia a um “tema” versus a um “plugin”. Esse debate agora parece quase antiquado, onde tudo e qualquer coisa é um bloco JS, mas, devido à sua relação com o software principal, ainda precisamos decidir onde o código deve ir, em um “plugin” ou em um “padrão de bloco”.
Eu nunca tive essa mesma sensação com os plugins no Discourse, principalmente porque as pessoas criaram alguns hacks brilhantes de componentes de tema ao longo dos anos. Se alguém me perguntasse qual é a diferença entre “plugins” e “componentes de tema”, minha primeira thought seria: um pede um campo de URL para instalação, e o outro requer uma reconstrução do site.
Apenas uma observação sobre a marcação: Parece mais fácil esquecer de marcar um tópico do que esquecer de escolher a categoria. Já existem alguns temas sem marcação.
Estou totalmente a favor de dar uma boa olhada nas categorias e tags. Houve algumas boas sugestões sobre dar uma ajustada na estrutura recentemente, então vou juntar tudo isso e ver onde chegamos. Acho que qualquer coisa que torne o Meta mais intuitivo para pessoas novas/usuários ocasionais só pode ser algo bom.
Isso deve ser menos um problema agora que há um Moderador de Comunidade dedicado. () Acho que ter eu organizando e arrumando conforme avanço deve cobrir muito disso. E temos um número decente de TL3s e TL4s, então espero que reforçar um padrão consistente torne mais fácil para outras pessoas participarem também.
Eu ainda penso nisso como mudanças Frontend versus Backend, mas a atualização para o ember também turvou o que isso significa para mim agora. Parece que tornou muitas mais coisas possíveis em um tema/componente de tema do que antes (o que é ótimo se você está hospedado e não tem acesso fácil para adicionar um plugin ).
Acho que essa é uma distinção bastante útil para não desenvolvedores. Vermelho = /admin/customize, Amarelo = app.yml. Acho que é provavelmente tudo o que você realmente precisa saber se for um administrador instalando uma customização existente, em vez de um desenvolvedor querendo criar uma nova.
Obrigado pela sugestão @Decorbuz Vou juntar algumas ideias e ver o que podemos fazer.
Mesma pergunta que celulares mais inteligentes são computadores ou não. As fronteiras não são mais tão nítidas.
É por isso que todo fórum deve fazer uma escolha lógica de como organizar as coisas: em algum lugar deve ser por ideia ou uso (UX e público importam), ou soluções técnicas são mais importantes (pensamento de base de desenvolvimento/código).
Não há soluções certas ou erradas, desde que os usuários encontrem o que procuram.
Bem, existem soluções erradas de vez em quando. Misturar plugins/temas/componentes saudáveis com os quebrados de forma que você tenha que descobrir a tag certa é uma péssima ideia
E, em geral, há outro erro que os administradores costumam cometer e, se bem me lembro, até o tag-doc ou similar da Meta adverte sobre isso: categoria não gera criação de conteúdo, mas as vazias ou de baixo tráfego apenas tornam as coisas confusas.
A falta de clareza não significa automaticamente que eles devam ser mesclados, especialmente sob o nome que o Justin sugeriu acima. Poderíamos igualmente adicionar explicações melhores para cada categoria e resolver parte dessa ambiguidade dessa forma.
#customização:tema e #customização:componente-de-tema encapsulam as personalizações pré-embaladas que podem ser feitas em tempo de execução.
Os tópicos de #customização:plugin exigem uma reconstrução e só podem ser realizados por usuários com acesso root. São alterações de maior risco que afetam a disponibilidade do site.
Eu também penso nelas assim. Se requer alguma mudança no backend (código ruby) seja para armazenar algo no banco de dados ou mudar algum comportamento de API, você muito provavelmente precisa de um plugin.
Se a mudança for apenas na UI, é melhor começar com um componente de tema e, se as coisas escalarem, ficarem mais complicadas e mudanças no backend se tornarem necessárias, recorrer a um plugin.
Gosto dessa ideia. É um pouco mais complicado do que uma única categoria com tags diferentes, mas gosto de uma fronteira mais forte entre esses diferentes elementos de personalização.
Um tema pode ser apenas sobre aparência, enquanto um plugin requer acesso ao sistema operacional da máquina para instalar. São coisas muito diferentes e categorias adequadas permitem, por exemplo, que o primeiro tópico na categoria forneça contexto aos novos usuários sobre as diferenças entre eles. Como instalar, documentação de desenvolvimento, etc.
Qualquer coisa que possamos fazer para facilitar para as pessoas saberem qual é qual vai ajudar muito, tenho certeza.
Acho que qualquer coisa que torne o Meta mais intuitivo para pessoas novas/usuários ocasionais só pode ser algo bom.
