Deveria haver uma configuração para permitir que o Nível de Confiança 4 (Líder) visualize a aba de moderação, pois planejamos usá-los em nosso fórum comunitário
Por quê?
Nossos Moderadores de Teste precisam fazer a transição para a liderança e a melhor maneira de fazer isso é permitindo que eles usem um painel/experiência de Mod de Teste mais simples.
Aqui está uma citação do nosso fórum:
Moderadores de Teste deveriam ser TL4 (Líder), não Moderador, pois os Mods de Teste não têm tanta experiência e podem aprender sobre o Discourse com uma interface mais simples. Moderadores têm uma interface de Administrador e isso pode ser confuso para novos moderadores
Então, um dos administradores disse isto:
A única coisa é que TL4 não pode acessar /review
Isso seria muito útil e, se você souber como fazer isso, por favor, me avise.
Sim, concordo (pq sou eu na citação rsrs), mas provavelmente deveria ser uma configuração. Posso ver que funcionaria perfeitamente para sites com programas de moderadores em teste (como o meu), mas outros não querem isso, então talvez uma configuração do site tl4 pode acessar revisão?
Você já considerou usar a função de moderador de categoria? Eles têm acesso a algumas coisas extras em comparação com o TL4, mas não a tudo que um moderador completo tem.
Eu gosto da ideia do @JammyDodger de usar mods de gato, mas isso inundaria a página “sobre”. Eu sei que pode ser facilmente ocultado com CSS, mas digamos que você queira ter mods de gato normais que não sejam mods de teste, você ainda vai querer que eles apareçam.
Posso tentar fazer disso um PR, mas não gosto de mexer com Ruby porque não o conheço, lol, é por isso que os únicos 3 PRs que fiz foram principalmente mudanças de UX
Se isso for implementado, acho que eles só poderão revisar postagens que outros membros sinalizaram. Isso é para evitar que TL4 possa excluir postagens que eles sinalizaram caso tenham um desentendimento com alguém.
@darkpixlz Acho que o tópico precisa da tag pr-welcome para que um membro da comunidade possa fazer um PR para a alteração. Corrija-me se estiver errado.
Você pode fazer um PR sobre qualquer coisa que quiser, é apenas a tag pr-welcome que significa que a equipe diz que é algo que eles gostariam de abordar, mas as pessoas podem fazê-lo porque não é uma prioridade tão alta.
Se um tópico sobre isso nunca foi abordado, alguém provavelmente poderia ter feito um PR sobre ele e ninguém teria questionado, e ele poderia ter sido mesclado.
Você quer criar um novo plugin para atender às suas necessidades específicas, pois os PRs podem ser rejeitados se o recurso não for algo considerado útil em geral.
Se isso fosse feito ou se @darkpixlz criasse um plugin para isso, eu preferiria que fosse em base por grupo em vez de TLs. Como a atualização recente para sussurros.
Não sei sobre criar um plugin por enquanto. Quero, mas não tenho ideia de como fazer qualquer coisa em Ruby e não posso criar um plugin apenas em JS da última vez que verifiquei, e também ainda não conheço a API do Discourse.
Eu desafiaria o acima, mas apenas no sentido de que tudo o que chega ao core é uma decisão consciente. A equipe tem uma direção para o produto e está trabalhando ativamente todos os dias para cumpri-la. pr-welcome significa que, embora uma mudança possa ser desejável, não é algo em que eles possam direcionar esforço internamente no momento. Nesse sentido, qualquer outra coisa já está agendada ou não é adequada para o core.
Isso não significa que você não deva sugerir novos recursos e funcionalidades, mas esteja sempre preparado para ouvir que algo que você considera desejável não se alinha com os objetivos da versão padrão do Discourse, conforme visto na instalação padrão.
Isso é verdade para a maioria dos softwares de código aberto. Mesmo o melhor PR escrito pode ser rejeitado por uma infinidade de razões.
Sim, eu deveria ter formulado melhor. Quero dizer, você pode abrir um PR, mas pode receber um “não” porque não é o que a @/equipe está procurando para que acabe na versão final.
