Este é exatamente o problema com a documentação do Discourse.
Por mais que possa ser “ok” para alguns irem caçar tópicos, isso não é documentação. É ter os usuários, e pior, os administradores/moderadores tendo que caçar informações.
Não, não é. E essa tem sido, e ainda é, a maior falha do Discourse. Não sei se estou sendo muito rude agora ou algo assim, mas a tendência de agir aqui é muito centrada no desenvolvedor — se você não sabe, sempre pode ler o código-fonte no GitHub. A CDCK não tem muita motivação para começar a construir uma boa documentação para os usuários — incluindo administradores, é claro — porque o objetivo deles são grandes corporações hospedadas. Então, para eles, o nível mínimo mais a ajuda da comunidade para os “freeriders” (que fazem uma grande parte da caça a bugs e propostas de UX 
) era suficiente. Exceto que então precisaríamos de um uso mais livre de tags…
Era suficiente não foi apenas um erro de digitação ou baixo nível de inglês. A CDCK/equipe começou a construir uma documentação melhor e tenho total certeza de que, depois de algum tempo, tópicos secundários como este serão apenas ecos do passado.
4 curtidas
Como comunidades de desenvolvedores/usuários, o Discourse está bem acima da média. Erros parecem ser corrigidos rapidamente, solicitações de recursos não são apenas ignoradas, especialmente se houver um caso de uso razoável para elas, e a equipe online (paga ou voluntária, não tenho certeza de como distinguir quem é o quê) é muito boa e bastante paciente em nos orientar, novatos.
Sim, a documentação precisa de trabalho, mas escrever uma boa documentação é caro e demorado. Além disso, os desenvolvedores muitas vezes não escrevem uma boa documentação porque estão muito próximos do produto, eles não o veem como os usuários o veem. Estar muito próximo do código também é um problema de teste de produto, embora em muitos projetos de código aberto a comunidade de usuários faça um bom trabalho testando as coisas.
5 curtidas
Claro que é. Assim como escrever um bom código também. Trabalho humano de boa qualidade é bastante caro. Mas código e documentação estão interligados, e a documentação começa a ser cara naquele ponto em que ninguém a faz. Caso contrário, é apenas uma parte crucial de um produto, assim como codificação, incluindo testes, design, UX/UI, etc. Mas os desenvolvedores costumam odiar a documentação porque simplesmente odeiam fazê-la, não há nada de sexy nisso, além disso, eles costumam ser muito ruins nisso Mas como os donos das empresas e outros supervisores são desenvolvedores semelhantes, eles simplesmente não se importam que os caras escolham o que fazem e o que não fazem.
Mas agora estou divagando para coisas muito gerais que estão muito fora do tópico. Então, vou sair e apontar para Documentation porque está evoluindo agora.
1 curtida
Concordo plenamente com isso. Sou um desenvolvedor com mais de 20 anos de experiência neste momento, mesmo que tenha migrado para engenharia de plataforma nos últimos anos.
Isso fica bem claro aqui quando você pede uma sugestão e os desenvolvedores (presumo? Só vejo que eles fazem parte do próprio discourse pelo título) vêm e dizem que não é e não será porque eles decidiram assim.
Fora do tópico daqui
Eu já disse isso: há uma diferença entre ter opiniões sobre sua pilha de tecnologia e ter opiniões sobre seu produto. Seu produto deve atender aos casos de uso dos usuários, dentro do razoável, não ser “minha bola e se outros não gostarem, podem ir para outro lugar”.
Já iniciei 5 novos projetos e, graças aos céus, tivemos alguém em nossa comunidade que entende um pouco de Ruby e explicará alguns conceitos básicos do fluxo do discourse para nós nos próximos dias, para que possamos começar a escrever alguns plugins que forneçam os recursos de que precisamos. Acima de tudo, fazer com que os Moderadores de Categoria não sejam uma piada.
O tópico de suporte Users are receiving emails even when everything is set up to not send email notifications evoluiu um pouco, então o dividi em alguns tópicos novos em outras categorias para dar a cada um deles algum espaço para respirar. 
2 curtidas
Consigo pensar em um projeto de código aberto onde os desenvolvedores tendem a trabalhar em coisas em que estão interessados, não em coisas que poderiam facilitar a vida dos usuários desse produto. O caso de uso é sempre uma questão de perspectiva, os usuários de produtos têm uma visão diferente do caso de uso do que os desenvolvedores. Os desenvolvedores tendem a pensar nas coisas que os usuários fazem como ‘apenas mais dados’, e muitas vezes não veem como uma pequena mudança pode fazer uma ENORME diferença na usabilidade. (Eu fiz minha parte no desenvolvimento de sistemas e tenho certeza de que tive essa atitude em alguns momentos.)
Até agora, não posso dizer que vi esse tipo de atitude com o desenvolvimento do Discourse, mas estou aqui há apenas um mês.
Quanto a estar muito próximo do produto, atualmente estou passando pelos exercícios de um livro sobre desenvolvimento Ruby. Um simples aplicativo ‘hello world’ levou 3 horas para funcionar ontem, principalmente porque o livro assumia familiaridade com um ambiente de IDE AWS (cloud9) que eu ainda não tinha, então eu clicava em algo e ele desfazia as alterações que eu tinha acabado de passar 10 minutos digitando.
E então houve um problema em obter uma prévia do aplicativo funcionando para exibir no meu navegador, o que parece ser devido a limitações de segurança que tanto Firefox quanto Chrome colocaram em seus navegadores desde a última atualização do livro. Depois de cerca de uma hora pesquisando soluções na web, adicionar o endereço IP do meu laptop e desktop à lista de permissões funcionou, embora eu ainda tenha que passar por uma etapa extra para que a prévia seja exibida.
1 curtida