Transforme uma mensagem do Slack em uma issue do GitHub, e em uma correção
Descreva um bug no Slack com suas palavras. Okou escreve a issue do GitHub e a atribui, e quando a causa está em um único componente abre um pull request com a correção e um teste de regressão para você revisar.
O que significa criar uma issue do GitHub a partir do Slack?
Criar uma issue do GitHub a partir do Slack significa transformar um bug que alguém descreveu em uma conversa em uma issue bem estruturada no seu repositório, sem que ninguém precise sair da thread para digitar tudo de novo. A parte difícil nunca foi a chamada de API: é escrever um título claro, separar os passos para reproduzir do comportamento esperado, escolher rótulos, definir uma prioridade e achar a pessoa certa. Okou faz esse trabalho. Ele lê a mensagem do Slack e as respostas ao redor, escreve o corpo da issue, aplica rótulos e uma prioridade que consegue justificar, resolve o responsável cruzando o nome exibido no Slack com um usuário do GitHub e publica o link da issue na mesma thread, para quem relatou conferir de imediato.
Por que relatos de bug morrem nas threads do Slack
Alguém vê um bug durante uma demo, ou um cliente escreve num sábado. O caminho de sempre é longo: abrir o GitHub, achar o repositório, escrever uma issue formatada, atribuir a alguém e então esperar essa pessoa pegar a tarefa, ler o código e escrever a correção. Uma mudança de dez minutos vira um vai e vem de dias entre três pessoas, e metade dos relatos nunca sai da thread. Em vez disso, você descreve no Slack. Okou abre a issue com passos para reproduzir, rótulos e responsável, e onde a causa está contida ele segue e abre um pull request com a correção e um teste. Você revisa e publica.
Como Okou cria uma issue do GitHub a partir do Slack
Passo 1: conecte suas ferramentas
Passo 2: peça ao Okou
Passo 3: leve mais longe
As integrações de Slack e GitHub por trás do fluxo
Esta é uma integração de Slack com GitHub com um agente no meio: Okou lê a conversa no Slack e escreve o registro no GitHub. Cada conector é concedido separadamente e limitado ao que o fluxo realmente usa, então ler um canal nunca implica acesso de escrita aos seus repositórios.
Integração com Slack: a conversa que Okou lê
ObrigatórioOkou lê a mensagem que você indica e as respostas ao redor, de modo que um contexto que chegou três mensagens depois também entra na issue. Ele leva junto as capturas de tela anexadas, lê o nome exibido de quem relatou para resolver o responsável e guarda o permalink da mensagem, assim toda issue aponta de volta para onde o relato começou. Escreve uma coisa só: uma resposta na mesma thread com o número e o link da issue. Okou não publica em outros canais, não envia mensagens diretas nem edita mensagens de ninguém.
Integração com GitHub: a issue que Okou abre
ObrigatórioOkou cria a issue no repositório que você indicar, com um título escrito a partir do relato e não uma cópia da mensagem crua, com descrição, passos para reproduzir, comportamento esperado e a área afetada quando a thread menciona uma. Ele aplica os rótulos que você define ou os infere do texto, define uma prioridade que explica e atribui o responsável. Antes de abrir, procura nas issues abertas o mesmo sintoma e comenta na existente quando encontra correspondência. Quando também consegue corrigir o bug, envia uma branch e abre um pull request que fecha a issue e pede revisão. O acesso de escrita é limitado aos repositórios que você conceder, e essa é toda a superfície: issues, comentários e pull requests abertos para revisão. Okou não faz merge, não faz force push e não mexe nas configurações do repositório.
Okou, o app do GitHub para Slack e um construtor de automações
Levar um bug de uma mensagem do Slack até o GitHub tem três partes: capturar o relato, escrever uma issue utilizável e encaminhá-la a um responsável. As opções existentes resolvem uma cada.
O app do GitHub para Slack
Digitar /github abre uma caixa em que você mesmo preenche título, corpo, rótulos e responsável. Poupa a ida ao navegador, mas quem escreve a issue continua sendo você, e um formulário no meio da conversa é justamente o atrito que faz as pessoas dizerem “abro depois”.
Um construtor de automações
Uma ferramenta no-code consegue copiar uma mensagem do Slack para uma issue nova a partir de um gatilho. O que ela copia é a mensagem crua, então a issue herda o que quem relatou digitou na hora, e as regras de rótulos, prioridade, atribuição e duplicatas são suas para definir e manter, canal a canal.
O fluxo do Slack para o GitHub do Okou
Okou lê a thread e escreve a issue: um título de verdade, passos para reproduzir separados do comportamento esperado, rótulos e uma prioridade que ele justifica, e um responsável obtido do nome exibido de quem relatou. Quando a causa está contida em um único componente, ele segue adiante e abre um pull request com a correção e um teste de regressão, vinculado à issue e aguardando a sua revisão. Ele confere as issues abertas antes e comenta em uma duplicata em vez de criá-la, e responde na thread com o link.
Dicas para melhores resultados
Perguntas frequentes
Como criar uma issue do GitHub a partir de uma mensagem do Slack?
Conecte Slack e GitHub ao Okou, descreva o bug no canal e mencione o Okou. Ele lê a mensagem e as respostas próximas, escreve uma issue com título, passos para reproduzir, comportamento esperado, rótulos e prioridade, cria no repositório que você indicou, atribui um responsável e responde na thread com o número e o link. Você não preenche formulário nenhum.
Qual a diferença em relação ao app do GitHub para Slack?
O app do GitHub te dá uma caixa para preencher: título, corpo, rótulos e responsável são escritos por você. Okou escreve tudo isso a partir da conversa, verifica se já existe uma issue com o mesmo sintoma antes de abrir, e pode percorrer um canal inteiro de forma agendada em vez de uma mensagem por vez.
Okou só abre a issue ou consegue corrigir o bug?
Os dois, e ele diz qual fez e por quê. A issue Okou sempre abre. Quando a thread ou o código apontam para um único componente, o comportamento esperado é inequívoco e dá para escrever antes um teste que falha, ele também abre um pull request com a correção e esse teste, vincula à issue e pede revisão. Utilitários compartilhados, tokens de design e qualquer coisa que precise de decisão de produto são abertos como issue, não alterados. Okou nunca faz merge: toda correção chega como um pull request que você revisa.
Okou consegue atribuir a issue à pessoa certa automaticamente?
Sim. Okou cruza o nome que você mencionar, ou o nome exibido no Slack de quem relatou, com os usuários do GitHub no repositório e atribui a issue. Nomear o responsável na mensagem é o caminho mais confiável; quando ninguém é citado, Okou recorre a quem responde pela área que a thread aponta e registra na issue como decidiu.
Como Okou evita issues duplicadas no GitHub?
Antes de criar qualquer coisa, Okou procura nas issues abertas o mesmo sintoma, área afetada e forma de descrever. Quando encontra correspondência, adiciona a nova thread do Slack como comentário naquela issue, com autor e horário, e responde no Slack com o link da issue existente em vez de abrir uma segunda.
O que acontece quando um relato não tem passos para reproduzir?
Okou abre a issue mesmo assim, para o relato não se perder, marca que faltam passos para reproduzir e responde na thread do Slack pedindo por eles. A resposta cai então na thread que já está vinculada a partir da issue.
Okou pode abrir bugs de um canal inteiro de forma agendada?
Sim. Aponte o Okou para um ou mais canais e dê uma agenda, por exemplo toda sexta às 16h. Ele lê as mensagens da semana, abre uma issue para cada uma que descreve um defeito, comenta as duplicatas, ignora pedidos de funcionalidade e perguntas, e relata o que fez.
Funciona com Linear ou Jira em vez do GitHub?
O mesmo formato de fluxo vale para qualquer rastreador ao qual o Okou esteja conectado; esta página cobre o caminho do GitHub, que usa o conector do GitHub. O Linear é conectado do mesmo jeito, e você indica o rastreador na instrução.
Abra seu próximo bug sem sair do Slack
Conecte Slack e GitHub, descreva o bug como você contaria para um colega, e deixe o Okou escrever a issue e atribuí-la. Quando a causa está contida, o pull request também já fica esperando por você.