devpt-org / discord-bot Goto Github PK

Seria interessante termos uma funcionalidade em que um utilizador através de:

• uma mensagem direta para o bot (se possível) OU
• através de uma página web básica com um formulário OU
• num canal em que só o próprio utilizador pode ver (costumava-se usar algo semelhante para sistemas de tickets no Discord?)

Assim que esta mensagem é recebida pelo bot, esta fica pendente de aprovação num canal apenas visível para admins (sempre anonimificada).

Exemplo:

devPT Bot says:
Mensagem 09e0c047-bf50-4983-a245-08c6cb2654f1
"Preciso de procurar outras oportunidades que paguem mais mas não sei onde. Alguém me pode sugerir bons sites para encontrar trabalho?"

Assim que aprovada (p.ex. um membro do staff respondendo neste canal privado com um !aprovar 09e0c047-bf50-4983-a245-08c6cb2654f1) esta é publicada num canal público a designar - se possível utilizando a nova funcionalidade de Fóruns.

Assim, qualquer utilizador que queira manter o seu anonimato em perguntas mais pessoais poderá fazê-lo sem problema.

Para evitar commits que alterem espaçamentos (espaços/tabs), devemos dar enforce num standard.

A adição desta verificação permitirá esse enforce.

No bot que tínhamos ativo no Discord, sempre que uma mensagem com o texto “!ja” era enviada, o bot respondia no mesmo canal com o conteúdo “ 👉 https://dontasktoask.com/pt-pt/”.

Idealmente poderíamos implementar esta funcionalidade neste bot.

Diria que numa primeira versão podemos implementar uma versão muito básica e conforme percebamos quais as necessidades em termos de funcionalidades poderemos eventualmente olhar para o issue #23 para organizarmos melhor o código.

Atualmente a escolha de cargos era feita de acordo com a seleção de emojis.

Olhando para as novas possibilidades do Discord, talvez pudéssemos tentar ter algo deste género:

(retirado daqui: https://discord.com/blog/welcome-to-the-new-era-of-discord-apps/)

Este issue por agora seria meramente de research até para percebermos como deve ser o UX para o utilizador.

Estejam à vontade para partilhar comentários. Podem claro avançar com uma implementação, mas que estará sujeita a alterações até definirmos exatamente o que queremos.

Quais são os caracteres disponíveis para este bot? Unicode? discord markdown?

Já agora, para além do <@${context.params.event.user.id}> temos mais alguma tag? como por exemplo hora de entrada? Seria engraçado dizer a alguém que entrasse às 16:30 que o giveaway de uma 3070 foi às 16:24 por exemplo

O projeto e a developer experience beneficiariam das tipagens e do acesso a funcionalidades de ES6 e ES7 fornecidas pelo TypeScript.

Tendo em conta o tamanho do projeto ser ainda bastante reduzido, penso que seria uma boa altura para a conversão da tecnologia.

O projeto atual deveria ter uma pipeline de testes implementada.

Sugeria utilizarmos jest tendo em conta ser o mais consensual em JavaScript, mas estou aberto a ideias.

Para facilitar desenvolvimento local e paridade entre dev e prod seria interessante adicionar suporte a Docker e eventualmente a docker-compose.

• Criar suporte para Dockerfile de desenvolvimento (#43)
• Criar suporte para Dockerfile de CI
• Criar suporte para Dockerfile de produção

O projeto atual deveria ter um ficheiro README.md que explique o conceito do bot.

Para além de uma introdução básica do projeto, seria benéfico ter também no README:

• instruções para desenvolvimento local (ainda não implementado)
• instruções da execução de testes (ainda não implementado)

Se colocássemos as frases num ficheiro .js, poderíamos remover esta dependência.

A Ideia é o user tem a hipotese de registar o seu stack, anos de exp. , o que faz atualmente se é remote ou não.

Ao executar um comando por exp !profile o user ter opções entre essas todas e ao selecionar por exemplo a stack aparecem opções em botoes/reactions que ao selecionar são atribuidas as roles automaticamente.

Os anos de exp ficava generico por exp < 1 ano , 1 a 3 anos, 3 a 5, 5 a 10 anos, > 10 anos...

O que isto iria influenciar?

Hipotese de criar opções like :open to work: em que pudessemos ativar alertas e sempre que um !jobs fosse adicionado com a stack do user ele seria alertado por dm ou outro meio

Hipotese de criar filtros nos !jobs, o user poderia filtrar ser alertado apenas para works remote em c# por exemplo

Aumentava a eficácia dos classificados pois mesmo que um user fosse inativo no chat iria ser alertado se quisesse

Para que os commits passem a ficar uniformes, seria interessante implementarmos um enforcer de conventional commits:

https://www.conventionalcommits.org/en/v1.0.0/

O pretty-quick vai deixar de funcionar por causa de uma API deprecada no prettier v3. Mais detalhes neste issue pretty-quick/issues/164.

Isto é um problema que vai afetar o pre-commit hook neste repositório, quando o prettier for updated também.

Como não existe muita manutenção na repo do pretty-quick eu vou tentar arranjar outra solução mais mantida e após testar em outros projetos faço pull request aqui.

Contexto

Depois de uma alteração que fiz ao comando !ja, notei que as mensagens dos comandos estão todas acopladas ao resolver que lê os comandos. Para facilitar a manutenção, revisão do código e rapidez de aprovação de mudanças, sugiro que os comandos e suas respectivas mensagens sejam desacoplados do resto da lógica. Talvez podíamos fazer uma estrutura em formato json.

Acho que pode ser um bom first issue para alguém, mas se ninguém fizer, eu abro um PR e proponho mudanças.

Idealmente, o código do bot deverá ter lugar para ser extensível e gerível.

Como tal, a arquitetura atual é demasiado coupled para permitir isso.

Alguns use-cases a serem eventualmente implementados no bot para que se possa perceber melhor que tipo de arquitetura se poderia almejar atingir seriam:

• envio de mensagens periódicas para determinado canal
• envio de mensagens de boas-vindas
• responder a uma mensagem publicada em determinado canal (por exemplo: !ja atualmente devolve 👉 https://dontasktoask.com/pt-pt/)

Conforme reportado no Discord, têm existido algumas situações em que algunas mensagens não fazem render da menção ao utilizador corretamente.

Exemplos:

Este comando torna o canal de Classificados fechado.

Quando um utilizador o chama, são pedidas varias informações em prompt que irão obrigar uma estrutura fixa de ofertas de trabalho, sendo assim essas opções obrigatórias/opcionais

Após o utilizador enviar esse comando serão criadas as threads para discussão do mesmo e o comando será removido do chat que foi chamado.

Adicionar o Gitpod permitirá que qualquer colaborador possa iniciar uma máquina pronta a programar o projeto em apenas alguns segundos (apenas tendo que configurar um token de um bot Discord criado para o efeito), automatizando a sua persistência.

É uma boa adição também para a review de PRs pela facilitação do setup de ambientes de desenvolvimento.