Integração com o Linear
O relato de bug chega no e-mail. A issue é do Linear.
A maioria dos bugs é relatada por alguém que nunca viu o seu rastreador. Escrevem para o suporte, ou citam no Slack, e alguém precisa notar e redigitar. O this+that lê a mensagem, entende que é um bug, e um fluxo registra no Linear com a corrente original anexada.
O servidor MCP do próprio Linear
O Linear publica um servidor MCP oficial, e o this+that conecta a ele como embutido. Você autoriza com a sua conta do Linear, e os seus fluxos passam a usá-lo como passo de ação. O Linear documenta o servidor com ferramentas para achar, criar e atualizar objetos no Linear como issues, projetos e comentários, com mais a caminho, então o que um fluxo faz cresce conforme o Linear estende.
Fluxos que alcançam o Linear
Descreva em linguagem comum. O gatilho costuma ser uma mensagem, e não algo acontecendo dentro do Linear.
"Quando um e-mail de suporte descrever um bug, crie uma issue no Linear e ligue de volta à corrente"
Quem relatou nunca vê o Linear, e ninguém precisa traduzir o e-mail num ticket. A conversa original fica anexada à issue.
"Se um cliente voltar a falar de um bug que relatou, comente na issue correspondente do Linear"
O segundo e-mail não vira ticket duplicado. Ele cai na issue que quem desenvolve já está olhando.
"Quando uma issue for marcada como concluída, escreva uma resposta a quem relatou"
Fecha o ciclo com quem levantou, que é o passo mais pulado porque vive fora do rastreador.
"Toda segunda, resuma o que chegou na semana passada e ainda não foi triado"
O trabalho relatado que nunca entrou num projeto aparece sozinho, em vez de na próxima reunião de planejamento.
Dois rastreadores, e é de propósito
O Linear segue sendo o rastreador de engenharia
Não estamos pedindo para você mudar o trabalho de engenharia para o DoBox. O Linear é melhor nisso, e o seu time já vive lá. O que o this+that acrescenta é o caminho de uma mensagem que chega até o Linear.
O DoBox guarda o que não pertence ao Linear
O cliente esperando uma resposta, o follow-up que alguém prometeu, a dúvida sobre uma cobrança. Isso também são tarefas, e não são issues de engenharia.
A origem fica anexada
Uma issue registrada a partir de um e-mail mantém a corrente, então quem pega pode ler o que o cliente de fato disse, e não um resumo.
A resposta faz parte do trabalho
Um fluxo responde a quem relatou quando a issue fecha, então entregar a correção e avisar o cliente são um ciclo só, e não dois.
O Linear ao lado dos canais por onde os relatos chegam
Um bug chega por e-mail, no Slack, no WhatsApp Business, ou de um colega. Todos são lidos do mesmo jeito, então o fluxo que registra a issue não se importa de onde veio. O nosso próprio caminho de bugs roda assim.
Pare de redigitar relatos de bug no Linear
Conecte o Linear e um fluxo registra a issue no momento em que o relato chega, com a conversa anexada e quem relatou avisado quando sair.
Grátis durante o beta · Sem cartão de crédito