Na minha opinião, acho que a tag Theme component serviria melhor ao seu propósito como uma subcategoria. Pelo menos para mim, elas são mais fáceis de encontrar em comparação com as tags, e nos últimos anos, os componentes de tema se tornaram cada vez mais significativos em contraste com seus equivalentes de 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, eles são extremamente populares e são uma parte integrante do Discourse hoje em dia.
Espero que você leve isso em consideração. Eu 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 criar confusão. Admin->Personalizar é apenas para temas e componentes de temas. Theme contém tudo o que pode ser introduzido em um site através dessa interface.
Já vemos problemas ocasionais com usuários colocando temas em seu YML e tentando adicionar repositórios git para plugins através da interface. Eliminar a delimitação apenas torna esses erros mais prováveis.
Plugins realmente precisam ficar em sua própria categoria, não acha?
A diferença entre um componente de tema e um plugin já está confusa na minha cabeça. Qualquer coisa que possamos fazer para facilitar para as pessoas saberem qual é qual, certamente ajudará muito.
Isso é meio engraçado, por muito tempo os desenvolvedores do WordPress tiveram que decidir onde incluir a funcionalidade, e debates foram feitos sobre quanto código pertencia a um “tema” versus um “plugin”. Esse debate é quase pitoresco agora, onde tudo e qualquer coisa é um bloco de JS, mas por causa de sua relação com o software principal, ainda temos que descobrir onde o código vai, em um “plugin” ou em um “padrão de bloco”.
Eu nunca tive essa sensação com 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”, meu primeiro pensamento seria: um requer um campo de URL para instalar, 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 precisam ser mesclados, especialmente sob o nome que Justin sugeriu acima. Poderíamos igualmente adicionar melhores explicações a cada categoria e lidar com parte da ambiguidade dessa maneira.
Theme e Theme component encapsulam as personalizações pré-empacotadas que podem ser feitas em tempo de execução.
Tópicos de 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, certamente ajudará muito.
Acho que qualquer coisa que torne o Meta mais intuitivo para pessoas novas/usuários ocasionais só pode ser algo bom.
