Design de aplicativo de caixa de entrada para revisão de código

Estrutura da caixa de entrada para revisão de código

Este design de aplicativo para desktop apresenta uma caixa de entrada de solicitações de revisão e menções do GitHub como um espaço de trabalho ordenado verticalmente. Uma barra lateral começa com “All 5”, seguida por “Participating”, “Mentions” e “Review requests 2”. A coluna principal então agrupa o trabalho em solicitações de revisão, verificações de CI, issues atribuídas e atividade. Essa sequência transforma vários sinais de engenharia em um único caminho de escaneamento, enquanto as categorias separadas preservam contexto suficiente para decidir o que precisa de atenção primeiro.

Uma solicitação de revisão como evidência

O primeiro item de revisão identifica o PR #2371 de open-design/web, nomeia “feat: orbit briefing card” e mostra “3 of 5 reviewers approved · waiting on you + cody”. Abaixo dele, o caminho de arquivo “src/components/OrbitBriefingCard.tsx” introduz um diff compacto com linhas removidas e adicionadas. Essa combinação permite que um revisor conecte o estado de aprovação a uma alteração concreta. A desvantagem é a densidade vertical: o trecho de código acrescenta contexto útil, mas torna o primeiro item substancialmente mais alto que a segunda solicitação.

Casos de uso de triagem de engenharia

O design oferece suporte a várias tarefas distintas sem fingir que elas são o mesmo tipo de trabalho. As solicitações de revisão pedem uma resposta ou aprovação, as verificações de CI sinalizam um estado de verificação com falha, as issues atribuídas representam tarefas do backlog pelas quais alguém é responsável e a atividade registra uma alteração concluída. Manter esses grupos como painéis separados torna visível o limite entre as tarefas. A desvantagem é que os sinais relacionados permanecem distribuídos pela página em vez de serem condensados em uma única pontuação universal.

Fluxo de leitura do espaço de trabalho

O espaço de trabalho usa uma coluna principal ampla e uma barra de navegação compacta, em vez de blocos de dashboard com o mesmo tamanho. O CSS entregue define uma largura máxima de página de 1280px, e o layout visível dá aos painéis de eventos a maior parte do espaço horizontal. Essa proporção comporta nomes longos de repositórios, títulos de pull requests, marcações de tempo e linhas de código sem forçar cada item a uma coluna de cartões separada. O custo é um escaneamento vertical longo, especialmente quando a solicitação de revisão inclui seu diff incorporado.

Do filtro ao detalhe

O campo de busca superior mostra Type / to search, mas não possui um manipulador de busca. Os filtros da barra lateral funcionam nos grupos locais fornecidos: Participating mostra solicitações de revisão e issues atribuídas, Review requests mostra o grupo de revisão e Mentions mostra apenas o grupo que contém o marcador de menção da fonte. Esse marcador está associado às issues atribuídas, e não à linha de revisão que requer resposta. A filtragem é um comportamento de apresentação local, não uma busca conectada do GitHub nem um serviço de caixa de entrada.

Mudanças de estado por meio da cor

A cor comunica o estado entre linhas que, de outra forma, seriam semelhantes. Verde marca estados de repositório abertos ou aparentemente saudáveis, amarelo marca trabalho aguardando uma resposta, vermelho marca o teste com falha e roxo marca o item de atividade mesclado. Os rótulos das issues usam etiquetas arredondadas azuis e rosas separadas para “backend” e “p1”. Isso torna o escaneamento mais rápido do que ler cada frase, mas a cor continua sendo suplementar: cada estado também é escrito como texto, preservando o significado quando a cor, sozinha, não é suficiente.

Limite de capacidade

A fonte implementa a filtragem local por categoria e constrói links externos do GitHub para linhas e títulos. Esses links apontam para um repositório fixo usando os identificadores de exemplo exibidos; sua existência não verifica os pull requests, issues ou resultados de CI representados. Busca, recuperação autenticada da caixa de entrada, estado persistente de revisão e execução real de testes não estão implementados. Nomes, contagens, marcações de tempo, estados de aprovação e trechos de código permanecem como conteúdo ilustrativo do cenário de design.