Não discordo. Mas, uma vez que as “pessoas específicas” crescem para um grupo de várias centenas, você acaba querendo algumas das boas funcionalidades que o Discourse oferece para navegar em tópicos públicos. Então, talvez o recurso diferenciador aqui seja o tamanho do grupo de destinatários?
1 curtida
Olá novamente, Geoff! Espero que esteja tudo bem.
Estou na mesma situação de querer poder ver MPs nas páginas Mais Recentes/Melhores/Novos (exatamente para o mesmo caso de uso), mas, separadamente disso, se entendi corretamente, essa parte (alternar a natureza pública/privada de um tópico existente) já parece existir.
A partir do ícone de chave inglesa das ações de administração no nível do tópico, no canto superior direito, você pode clicar em “Tornar Mensagem Privada” (ou “Tornar Tópico Público” se já for uma MP). Alterar um tópico existente para uma MP parece manter o acesso para todos que postaram no tópico, e então você pode adicionar o grupo de equipe também. No entanto, isso move o tópico da lista de tópicos para a seção de mensagens.
É… daí vem o problema.
O que eu adoraria seria algo como o recurso oculto, mas que deixasse a mensagem visível para toda a equipe com um determinado nível de confiança. Isso pode ser viável…
Seria possível definir manualmente, por exemplo, o trust_level_3, para que qualquer pessoa possa enviar mensagens privadas para ele (em Grupos → trust_level_3 → Gerenciar → Interações)?
Então, parece que você poderia adicionar manualmente o grupo trust_level_3 como participante após converter um tópico público em uma mensagem privada.
Isso pode não ser exatamente o que você está procurando (e não tenho certeza se entendo o suficiente do funcionamento interno para afirmar com certeza que funcionaria), mas talvez possa atender a parte do objetivo.
Sou mais um dos últimos a entrar na discussão, com um caso de uso quase idêntico ao de @Geoffrey_Challen (gerenciar uma turma grande e esperar usar o Discourse para organizar perguntas e respostas e discussões).
Não me preocupo pessoalmente com o volume de e-mails (de qualquer forma, configurei o modo de lista de e-mails), mas acho que seria uma grande melhoria na qualidade de vida poder responder à pergunta de “Quais são todos os tópicos que preciso ler/responder?” em um único lugar, independentemente de essas postagens serem públicas ou enviadas ao grupo de equipe (ou talvez até mesmo diretamente para mim).
A permissão de “criar”, como discutida originalmente, seria uma maneira de lidar com isso. Outra seria permitir que as PMs de certos grupos sejam renderizadas como pseudocategorias nas páginas de lista de tópicos (Novos, Top, etc.). Dada a semelhança na estrutura das PMs em relação aos tópicos públicos no banco de dados, parece que isso pode ser possível (embora haja, com certeza, um nível de complexidade adicional).
Uma alternativa diferente que poderia ajudar de forma semelhante, sem exigir mudanças tão grandes, seria se a caixa de pesquisa tivesse uma maneira de pesquisar em todos os tópicos e PMs (atualmente, pelo que vi, posso pesquisar um ou outro, mas não ambos), e idealmente refinar as coisas por grupos específicos de destinatários de PMs. Por exemplo, eu gostaria de poder dizer: “mostre-me todos os tópicos abertos que foram tópicos públicos ou PMs para o grupo de equipe”.
Se for possível modificar a funcionalidade de pesquisa dessa maneira, parece que isso forneceria grande parte da funcionalidade que eu esperava, e o faria de uma forma que não exigiria mudanças, exceto na pesquisa. Mas talvez haja complicações aí também, que não estou considerando.
Acho que isso pode fazer parte do problema. Talvez também tenha a ver com o volume de tráfego das PMs de grupo em comparação com as postagens públicas? Nossos casos de uso envolvem muita interação tanto em tópicos públicos quanto em PMs de grupo (e um grande número de tópicos em ambos), enquanto, para muitos outros casos de uso, mensagens privadas para a equipe podem ser mais raras, e talvez isso tenha impacto na forma como as pessoas desejam interagir com essas coisas?
OK… depois de algumas horas de hacking esta tarde tenho um protótipo da permissão de criação apenas (na branch cs125). Muito pouco testado, mas aqui está o que parece funcionar:
- Categorias podem receber uma permissão de criação.
- Usuários com essa permissão podem criar tópicos na categoria e responder aos seus próprios tópicos.
- Eles ainda conseguem ver tópicos criados por outros usuários, mas uma tentativa de acessá-los retorna um erro: “Esta página é privada ou …”.
- Administradores podem ver e responder a todas as postagens.
- Não tenho ideia se outras permissões de categoria ainda estão funcionando, mas não vejo motivo para não estarem…
Assumindo que isso realmente está funcionando e não é apenas um desejo meu, gostaria muito de resolver o item #3 para que a interface fique menos confusa para os alunos. Mas foi aí que perdi o rumo — embora talvez seja porque tenha sido um dia bastante longo. @sam: alguma ajuda aqui, ou você vai nos renegar agora que estamos tão fora dos trilhos 
. Basicamente, quero ser capaz de filtrar a lista de tópicos de uma categoria (e, na verdade, todas as listas de tópicos) para excluir tópicos em categorias onde o usuário tem apenas permissão de criação, a menos que o usuário tenha criado aquele tópico.
PS: esta branch também estende as permissões de sussurro para usuários com nível de confiança >= 3. Outros podem ou não querer essa mudança, mas é útil para nós, já que privilégios de moderador são demais para a maioria da equipe do meu curso, mas sussurrar é realmente útil ao trabalhar juntos para ajudar os alunos.
@sam: outra pergunta rápida. Há alguma chance de fazer qualquer uma dessas coisas por meio de um plugin?
Isso é quase exatamente como funciona o plugin de respostas restritas.
A única coisa que ele não lida é o item (3). Isso será extremamente difícil de implementar, por todas as razões listadas acima.
3 curtidas
Corrija-me se eu estiver errado, mas parece que seu plugin não impede que as pessoas vejam as postagens que não criaram. Isso é essencial para o nosso caso de uso: alunos postando perguntas em nosso fórum do curso que podem conter código e/ou outras partes de sua solução. Portanto, não precisamos apenas que apenas a equipe possa responder, mas também que apenas a equipe possa visualizar. O plugin de respostas restritas diz que opera como uma permissão “Criar / Responder (para si mesmo) / Ver”. Precisamos essencialmente de “Criar / Responder (para si mesmo)”, mas não de “Ver”.
Dito isso, é realmente encorajador que isso possa ser feito em um plugin. Seria possível também restringir a visualização para apoiar nosso caso de uso?
Em relação ao #3: eu estava me perguntando se seria mais fácil fazer isso no lado do cliente. Atualmente, com nossas alterações, os alunos nem conseguem acessar esses tópicos, então, mesmo que pudéssemos apenas ocultá-los na interface do usuário, isso seria suficiente.
Sim, você está correto. É por isso que disse que não atinge (3).
E se um usuário estiver acompanhando a categoria e receber notificações sobre o tópico secreto? E quanto ao modo de lista de correio? E quanto às páginas de “atividade” do usuário? E quanto aos tópicos “mais populares”? E quanto aos tópicos “novos”? E quanto à busca? E provavelmente muitas outras perguntas… Isso é uma tarefa monumental, e eu não recomendaria.
Os PMs de grupo são projetados exatamente para o seu caso de uso. Aqui no Meta, tratamos todo o nosso e-mail de suporte por meio de PMs de grupo, e funciona muito bem! Se houver problemas específicos de usabilidade que você esteja enfrentando com as caixas de entrada de grupo, então acho que seu tempo seria melhor gasto explorando melhorias nesses recursos.
3 curtidas
Não discordo. Mas estamos aqui porque tentamos mensagens privadas em grupo e elas não estão funcionando tão bem, dado que temos cerca de 200 pessoas no lado receptor da mensagem.
Falei sobre isso na minha resposta ao Sam, mas mensagens em grupo não parecem funcionar tão bem assim que a lista de destinatários fica realmente grande, e a probabilidade de eu responder a cada mensagem individual diminui. Por outro lado: se mensagens em grupo funcionassem tão bem, as pessoas ainda estariam usando listas de e-mail abertas e grandes em vez de ótimas ferramentas como o Discourse.
Provavelmente continuaremos com mensagens em grupo em vez de arriscar a quebra que você tem razão em apontar que poderia resultar de uma tentativa de modificar as permissões da categoria. Mas não é realmente muito útil ouvir “mensagens em grupo funcionam muito bem!” quando sua experiência é que, na verdade, elas não funcionam tão bem 
2 curtidas
Claro, sempre haverá diferenças na forma como as coisas são usadas em comunidades diferentes. O que quis dizer é que seria interessante explorar quais desenvolvimentos seriam necessários para que você pudesse usar as MPs com sucesso. Acredito que mudanças nessa área são muito mais alcançáveis do que re-implementar recursos de MP em categorias regulares.
Quais problemas específicos você está enfrentando com as MPs em grupo? Para dar um exemplo, talvez seja uma sobrecarga de notificações? Esse foi um dos problemas que tivemos originalmente, e agora você pode configurar o nível de rastreamento para cada caixa de entrada de grupo.
6 curtidas
Sim, essa foi uma adição realmente útil! Obrigado.
Se você der uma olhada em parte da discussão acima, acredito que verá alguns problemas com o sistema de mensagens privadas (PM). Principalmente, há um fluxo de trabalho diferente para lidar com mensagens, o que cria uma separação artificial entre tópicos que eu gostaria de tratar de forma semelhante. (Daí a tentativa de adaptar isso ao modelo de permissão de categoria existente.)
Há uma lista aqui, mas tudo se resume a fazer com que os grupos de mensagens se pareçam o máximo possível com categorias. Tê-los na página inicial e na visualização dos tópicos mais recentes, fazê-los parecer os mesmos ao navegar, ter as mesmas opções de pesquisa e filtragem (sem precisar lembrar que se trata de uma mensagem), etc. Infelizmente, minha sensação é que isso exigiria tanto, senão mais, quebra de funcionalidade do que as permissões adicionais de categoria. Mas talvez não?
@david: desculpe interromper a conversa, mas tenho um caso de uso muito semelhante ao do @Geoffrey_Challen e, embora certamente não possa falar por ele, acho que uma coisa concreta que ajudaria mim nesse sentido seria ter a opção de executar uma única consulta de pesquisa de forma que corresponda tanto a tópicos públicos quanto a mensagens privadas (no momento, parece que posso pesquisar tópicos públicos ou mensagens privadas, mas não ambos, a menos que esteja perdendo algo).
Entendo que algumas das outras alterações sugeridas aqui (permissão “Criar”, permitir que PMs sejam exibidas nas listas regulares de tópicos, etc.) envolvem mudanças amplas e complicadas, mas talvez uma alteração na pesquisa para permitir a busca em todos os tópicos (públicos ou PMs) fosse mais prática e mais localizada, ao mesmo tempo em que forneceria a capacidade de obter alguma semelhança de uma visão unificada dessas coisas por meio da pesquisa.
Para mim, não acho que substituir a interface padrão seja importante, mas seria fantástico se eu tivesse alguma maneira de responder rapidamente à pergunta: “Quais são todos os tópicos nos quais posso precisar responder agora?”, independentemente de serem públicos ou privados, e refinar isso com base em tags, etc.
Enquanto isso, escrevi um pequeno script que posso usar para obter essa lista unificada diretamente do banco de dados Postgres, ou posso executar duas consultas separadas na caixa de diálogo de pesquisa para cada coisa que quero pesquisar (uma para públicos e outra para privados), mas ambas são meio dolorosas…
2 curtidas
Parece uma ótima ideia para mim — eu usaria isso. O melhor seria criar um novo tópico #feature, para que não percamos a ideia neste tópico.
Edição: feito aqui
4 curtidas
Estou realmente com dificuldade para entender a aversão a permitir esse tipo de estrutura de permissão, depois de ter sido discutida desde 2015. Com certeza consigo ver o apelo do autor da postagem original, assim como as ressalvas em relação ao uso de mensagens privadas como alternativa. Permissões um pouco mais granulares seriam uma grande mudança de jogo para o Discourse — abririam muitas portas para usos mais criativos em comunidades.
Os efeitos das permissões granulares são… bem documentados. Ainda tenho pesadelos ao pensar na bagunça que o vbulletin fez com as permissões de categorias, exatamente por esse motivo.
O ponto é que, se você deseja que os usuários possam criar tópicos e ver apenas os tópicos que eles mesmos criaram, essa funcionalidade já existe nas mensagens privadas. Combinada com as caixas de entrada de grupos, ela já replica o comportamento desejado.
1 curtida
Eu pessoalmente não tenho experiência com o vbulletin ou outros softwares de fórum. Minha experiência com plataformas baseadas em comunidade vem do Discord, onde criadores de comunidade têm mais controle sobre as permissões. Também já vi sistemas de permissão implementados com sucesso em diversas outras plataformas que permitem maior controle. Não acho que alguém esteja pedindo 500 botões de alternância neste cenário, mas sim a capacidade de atribuir permissões de Criar, Ver e Responder de forma independente entre si.
O comportamento desejado é que o usuário abra uma categoria, clique em “Novo Tópico”, digite seu conteúdo e que sua postagem seja visível apenas para ele e para quem tiver a permissão de “ver”. As mensagens privadas são muito mais complicadas de navegar para o usuário do que o que descrevi acima — exigem mais iniciativa do usuário e a função está mais escondida na interface.
Uma solução mais simples para o problema seria permitir a criação de tópicos por e-mail, no entanto, isso também tem uma desvantagem. Isso não promove a participação na comunidade diretamente e exige que o usuário use um sistema de terceiros para alcançar o objetivo.
Mensagens diretas e permissões de categoria são dois tópicos distintos e não são realmente o que o OP pediu, nem o que várias pessoas que virão depois estarão procurando.