Estou apenas atualizando este tópico — mas certamente acho que a resposta é sim
Devido ao sucesso de nossa comunidade empresarial (tanto com nossos usuários quanto dentro de nosso negócio), nossa equipe de documentação entrou em contato e perguntou se poderíamos criar um sistema de comentários para todo o documentation.sailpoint.com. Pelo que parece, conseguiremos fazer quase tudo o que queremos realizar, no mínimo:
Incorporar comentários (funcionalidade de incorporação)
Também queremos usar diferentes usuários para postar e aplicar diferentes conjuntos de tags, com base na incorporação. Este recurso estará disponível em breve:
A partir daí, tudo o mais que a equipe de documentação (e minha equipe) queria estava dentro do Discourse para que pudéssemos segregar efetivamente essa experiência do resto do nosso uso diário do fórum, ao mesmo tempo em que oferecemos às pessoas a capacidade de comentar, ser notificado de respostas, etc.
Capacidade de designar quais usuários podem e não podem comentar
Atribuir moderadores de categoria aos tópicos associados
Suprimir essa infinidade de categorias para esses documentos de nosso site principal
categoria não pesquisável
componente de tema usado para ocultá-la da lista principal de categorias
suprimida do resumo
adicionada às categorias silenciadas padrão
Comentários removidos após n dias
Algumas outras configurações…
Eu definitivamente adoraria ver muitas das funcionalidades mencionadas aqui implementadas, no entanto!
O objetivo é permitir que os usuários criem comentários em https://documentation.sailpoint.com/, ou você está de acordo em apenas incorporar os comentários no site de documentação e fazer com que os usuários visitem seu site Discourse para comentar os artigos?
O primeiro é um recurso que eu adoraria ter (leia-se: por favor, construam, CDCK), mas o último atende aos nossos requisitos mínimos, pelo menos.
Na verdade, explorarei uma ideia em um futuro próximo de fazer o Discourse servir nossa documentação em markdown (não, não em tópicos, mas em documentos tradicionais no estilo markdown), caso em que comentários e o registro para fazê-los seriam totalmente inclusivos. Mas essa exploração ainda não começou.
Com a abordagem em que estou trabalhando agora, seria tecnicamente possível permitir que comentários do Discourse fossem gerados diretamente nas páginas do MkDocs, mas isso exigiria o uso de um framework do lado do servidor (Remix, Rails, etc.) para servir as páginas do MkDocs. Isso tornaria possível autenticar usuários (com DiscourseConnect) no site de documentação e também permitiria o uso de um banco de dados em memória para cache de comentários retornados anteriormente.
(Edição: apenas para deixar claro, estou falando de usar o Discourse como um provedor de identidade para o site, não o site como provedor de identidade para o Discourse. A última abordagem funciona, mas é muito inflexível para a maioria dos casos de uso.)
Essa seria uma grande mudança para pedir à sua equipe.
Tenho certeza de que, da sua perspectiva, seria mais simples se isso fosse realizado inteiramente dentro do Discourse, mas também é possível usar o Discourse como um sistema de gerenciamento de conteúdo. Nesse caso, a documentação em markdown seria gerada como tópicos regulares do Discourse. Webhooks do Discourse seriam usados para acionar a geração de uma página de documentação em um site externo. Essa é, na verdade, a base do site de demonstração de comentários do Discourse que estou configurando.
Como este tópico foi linkado hoje, pensei em atualizá-lo com as conclusões que cheguei após dedicar algum trabalho à ideia.
Ainda acho que o Discourse seria uma boa plataforma de comentários pelos motivos que expus na postagem original.
Em termos de como fazer isso, acho que o trabalho precisa ser feito no lado do Discourse – idealmente, melhorando o script de incorporação de comentários do Discourse. Isso poderia ser feito incrementalmente.
É tecnicamente possível usar o Discourse como servidor para uma plataforma de comentários, fazendo todo o trabalho em um cliente Discourse (por exemplo, o plugin WP Discourse), mas devido à necessidade de gerenciar o estado entre o cliente e o Discourse, e contornar problemas de limitação de taxa, isso se torna um problema complexo. É definitivamente mais complexo do que algo que eu queira ser responsável por manter.
Algumas postagens neste tópico indicaram que as pessoas estariam interessadas apenas em permitir que os usuários criem comentários no Discourse em um site de blog. Do meu ponto de vista, essa não é uma ótima solução, mas pode ser alcançada agora com a API do Discourse. Onde as coisas se complicam é ao tentar criar um sistema de comentários completo, onde os usuários possam interagir com os comentários do Discourse em um site de forma semelhante a como esperariam interagir com comentários em um site de notícias típico e convencional.
Dada a minha experiência com ActivityPub e WP Discourse, acredito que comentários bidirecionais via JavaScript incorporado são alcançáveis. O script de incorporação conteria o seguinte:
“Leitura” não autenticada funcionando de forma semelhante ao script incorporado atual (com algumas otimizações).
Cliente remoto (ou seja, o navegador do usuário) registra um cliente de chave de API de usuário, específico para a sessão do usuário e armazena detalhes relevantes no armazenamento local do navegador.
O usuário é apresentado com “Entrar para comentar”.
O usuário autentica (com o Discourse) para recuperar uma chave de API de usuário de sessão que é armazenada no armazenamento local do navegador.
Cada atividade (comentário, curtida, etc.) é postada diretamente em um endpoint dedicado com salvaguardas, tratamento e gerenciamento de tarefas apropriados.
Com o orçamento certo, acho que poderia ter a v1 pronta para produção e integrada com discourse/discourse em 6-8 meses. Após o lançamento inicial, eu poderia fazer o seguinte:
Adicionar suporte explícito para Wordpress, Ghost e outras plataformas selecionadas.
Tente implementá-lo de uma forma que faça sentido para usuários não técnicos. Plataformas existentes como Disqus e comentários do Facebook provavelmente oferecem bons exemplos.
Algumas opções de autenticação adicionais:
o site do cliente se torna um cliente DiscourseConnect. Isso é simples de implementar, mas requer código adicional no lado do servidor do site do cliente.
os usuários fazem login diretamente no Discourse via iframe
Minha relutância em desenvolver isso puramente no lado do cliente surgiu ao considerar os problemas do sistema funcionando em qualquer tipo de escala. Essencialmente, eu teria que enfileirar solicitações de API e lidar com respostas de solicitações enfileiradas. Não parecia robusto o suficiente para lidar com, digamos, 1000 usuários simultâneos. Eu teria preocupações semelhantes, mas por razões diferentes com a abordagem de incorporação javascript. Suspeito que seria muito mais fácil de lidar do que tentar sincronizar tudo no cliente.
Refleti mais profundamente sobre isso ontem, já que o tópico foi reaberto (o que me levou a postar aqui). Acho que uma solução apenas do lado do cliente (ou seja, um embed de javascript) é a única que realmente faz sentido aqui. Caso contrário, estamos essencialmente falando sobre uma série de implementações específicas da plataforma, cada uma com seu próprio conjunto de problemas.
Você está certo que concorrência e carga são problemas. Existem problemas significativos de carga e concorrência com o ActivityPub, pois uma única postagem do ActivityPub pode expô-lo a muitas requisições de entrada e saída do Fediverso. Nesse contexto, isso pode ser, na verdade, um pouco mais fácil, pois os clientes remotos são controlados. Além disso, neste caso, concorrência e carga são realmente problemas apenas do lado do servidor (ou seja, do lado do Discourse) e, embora sejam problemas, acho que eles devem ser solucionáveis por meio de jobs em segundo plano, cache e mutexes. Mas sim, são problemas importantes a serem considerados.
Para ser honesto, minha maior preocupação aqui é o tempo.
O Composer v2 está logo ali na esquina, seria uma loucura embarcar nesta aventura e não contar com nosso novo composer, mas há uma montanha de trabalho que precisamos adiantar para viabilizar seu uso em um aplicativo leve.
Acho que a coisa certa a fazer aqui é acompanhar este espaço para o novo composer por, digamos, 2-3 meses e então revisitar a questão.
Eu acho que isso pode ser feito em paralelo. Você precisa fazer 2 alterações no discurso.
O botão “Responder” deve ser visível para usuários não registrados.
E quando usuários não registrados clicarem neste botão, isto deve ser exibido:
Em seguida, você precisa descobrir como usar a inserção de comentários. Provavelmente serão pequenas alterações de código, em vez de muito trabalho.
Gostaria de saber se ainda há interesse em desenvolver este recurso, agora que o Composer v2 foi lançado. Coloco meu voto de que ainda é algo que eu adoraria ver e usar.
