are there any inherent problems or considerations with raising a ticket off of the back of a review, instead of failing it?
Não inerentemente. Por exemplo, a implementação da mudança atual pode ter desenterrado um problema que já estava lá, mas não era conhecido / aparente até agora. Não conseguir o ticket seria injusto, pois você falharia por algo não relacionado à tarefa realmente descrita.
in the review we discover a function
No entanto, suponho que a função aqui seja algo que foi adicionado pela alteração atual. Nesse caso, o ticket deve falhar, pois o código não passou no teste de cheiro.
Onde você desenharia a linha, se não onde você já desenhou? Você claramente não acha que esse código está suficientemente limpo para permanecer na base de código em sua forma atual; então por que você consideraria dar um passe para o ingresso?
Fail the code review, so that the ticket doesn't close in this sprint, and we take a little hit on morale, because we cannot pass off the ticket.
Parece-me que você está indiretamente argumentando que está tentando dar um passe para beneficiar a moral da equipe, em vez de beneficiar a qualidade da base de código.
Se for esse o caso, então você tem suas prioridades misturadas. O padrão de código limpo não deve ser alterado simplesmente porque torna a equipe mais feliz. A correção e a limpeza do código não dependem do humor da equipe.
The refactor is a small piece of work, and would get done in the next sprint (or even before it starts) as a tiny, half point story.
Se a implementação do ticket original causou o cheiro do código, ele deverá ser endereçado no ticket original. Você só deve criar um novo tíquete se o cheiro do código não puder ser atribuído diretamente ao tíquete original (por exemplo, um cenário de "palha que quebrou o fundo do camelo").
The resources I can find and have read detail code reviews as 100% or nothing, usually, but I find that is usually not realistic.
Pass / fail é inerentemente um estado binário , que é inerentemente tudo ou nada.
O que você está se referindo aqui, eu acho, é mais que você interpreta as revisões de código como exigindo código perfeito ou falhando, e esse não é o caso.
O código não deve ser imaculado, deve simplesmente obedecer ao padrão razoável de limpeza que sua equipe / empresa emprega. A adesão a esse padrão é uma escolha binária: adere (passa) ou não (falha).
Com base na sua descrição do problema, é claro que você não acredita que ele esteja de acordo com o padrão de código esperado e, portanto, não deve ser aprovado por motivos ocultos, como moral da equipe.
Otherwise the task fits the definition of done.
Se "ele fizer o trabalho" fosse o melhor benchmark para qualidade de código, então não teríamos que inventar o princípio de código limpo e boas práticas para começar - o compilador e o teste de unidade já seriam nossos testes automatizados. processo de revisão e você não precisaria de revisões de código ou argumentos de estilo.