GitHub permite que a função Triage arquive pull requests, e não apenas administradores

O GitHub mudou, em 8 de outubro de 2026, as regras de acesso ao arquivamento de pull requests. Agora, usuários com a função Triage ou superior podem arquivá-los e desarquivá-los. Até então, essa permissão era exclusiva dos administradores do repositório. Entre as cinco funções padrão do GitHub (Read, Triage, Write, Maintain, Admin), o requisito caiu do degrau mais alto para o segundo, de baixo para cima. É uma mudança pequena, mas em um dos fluxos de trabalho mais movimentados da plataforma.

O que exatamente mudou

O anúncio no GitHub Changelog é curto. Antes, arquivar um PR exigia permissões de administrador, e por isso os triadores de confiança precisavam repassar aos administradores até os casos de rotina. O texto do anúncio, na versão a que tivemos acesso, termina abruptamente nessa frase. Ele não traz detalhes de implementação, por exemplo, como os PRs arquivados aparecem na busca e nos filtros ou quais eventos entram no log de auditoria. Vale conferir isso na documentação do GitHub.

A regra agora vale nos dois sentidos: um usuário com a função Triage pode tanto mandar um PR para o arquivo quanto trazê-lo de volta. Isso é relevante. Se o triador arquivar um PR por engano, ele mesmo corrige, sem precisar procurar um administrador.

Por que o nível de acesso importa

A função Triage do GitHub foi criada para quem cuida do fluxo de entrada. Essas pessoas aplicam labels, atribuem responsáveis, fecham duplicatas e reabrem issues. Em contrapartida, não podem fazer push de código no repositório. É uma função natural para voluntários em projetos open source e para engenheiros de suporte ou profissionais de QA em equipes corporativas.

Antes da mudança, havia uma lacuna. O triador via um PR desatualizado ou abandonado e podia fechá-lo, mas não podia tirá-lo do espaço de trabalho. Para isso, era preciso pedir a um administrador. Em projetos pequenos, costuma haver só um administrador, e esses pedidos viram rapidamente um gargalo. Agora, a limpeza rotineira da fila fica no nível em que se decide o que vai nela.

Há também um pano de fundo indireto. Ferramentas como agentes de programação tornam mais barato abrir um PR, e em muitos repositórios as filas estão crescendo. O próprio GitHub não menciona essa relação no anúncio; é uma observação nossa. Mas, quanto mais PRs são criados automaticamente, mais cara fica cada transferência desnecessária de tarefa entre funções.

Os parâmetros em resumo

• Data do anúncio: 8 de outubro de 2026.
• Quem tem acesso: função Triage ou superior (Triage, Write, Maintain, Admin).
• Operações: arquivar e desarquivar pull requests.
• Antes: apenas administradores do repositório.
• Fonte: GitHub Changelog.

Como aproveitar a mudança na equipe

Primeiro, verifique quem tem a função Triage no seu repositório. Se você a concedeu apenas para labels e atribuições, essas pessoas ganharam mais uma ação. Para a maioria das equipes, isso é aceitável, mas em projetos com regras mais rígidas é melhor avisar com antecedência.

Depois, registre no CONTRIBUTING ou em um guia interno os critérios de arquivamento. Por exemplo: PRs sem atividade por mais de determinado prazo, duplicatas, PRs abandonados pelo autor. Sem uma regra, cada triador vai decidir de um jeito, e perguntas como «por que meu PR sumiu» vão aparecer com mais frequência.

Por fim, se você tem automações em torno dos PRs (bots, dashboards, relatórios de velocidade de revisão), confira como elas tratam os pull requests arquivados. Quem mede o tempo de vida dos PRs deve decidir de antemão se o arquivamento conta como fechamento. É improvável que o GitHub indique como fazer isso no seu processo específico.