Aquele GitHub Issue Aberto em 2012 Que Ninguém Nunca Resolveu

Aquele GitHub Issue Aberto em 2012 Que Ninguém Nunca Resolveu

A Vida Útil de Um GitHub Issue

Você abriu um GitHub issue em 2012. Aquela época, você ainda usava o Tumblr, assistia Game of Thrones no dia de lançamento, e acreditava que a internet seria mais unida até 2020. Spoiler: nada disso aconteceu.

Mas aquele issue? Aquele continua lá. Olhando pra você. Esperando. Como um ex que nunca te esqueceu.

O Padrão Universal Das Issues Imortais

Existe uma progressão natural e inevitável que todo GitHub issue segue. Começa com esperança. Termina com abandono.

Dia 1: Você escreve um título genial. “TypeError: Cannot read property ‘undefined’ of undefined when parsing user input on Sunday mornings”. Muito específico, muito descritivo. Muito… ignorado.

Semana 2: Três pessoas chegam, analisam, dizem “estranha, nunca vi isso” e saem. O maintainer tá ocupado com a vida real.

Mês 1: Alguém comenta “+1” porque TAMBÉM tem o problema. A conversa enche de gente que tem o problema. Ninguém com solução.

Mês 3: O primeiro “any updates?” aparece. Inocente. Cheio de esperança.

O Abandono Lento E Doloroso

Depois vem o abandono. Não é violento. É como aquele relacionamento que morre lentamente enquanto você tá distraído trabalhando.

O repositório ganha 50 estrelas. Depois 500. Depois 50mil. Mas aquele issue continua lá. Com 127 comentários. Nenhum consenso.

Às vezes aparece um comentário desesperado: “Alguém tem workaround? Tô travado nesse bug há 3 semanas e meu boss tá furioso”.

Alguém responde com uma solução que envolve 7 passos, um plugin de 2011, configuração em arquivo que não existe mais, e reza pra três santos.

E funciona! Por 1 pessoa. As outras 127 nunca voltam pra comentar.

Os Estágios De Luto Do Issue

Toda issue imortal passa pelos 5 estágios de luto. Negação, raiva, negociação, depressão, e aceitação.

Negação: “Isso tem que ser um bug do navegador”. “Não é reprodutível com a versão 4.2.1”.

Raiva: “ALGUÉM CONSERTA ESSE CÓDIGO DE MERDA”. “Por que ninguém responde???”.

Negociação: “Se eu abrir um PR que arruma, vocês mesclam?”. (Spoiler: não vai ter PR).

Depressão: Os comentários viram espaçados. Meses entre cada um. O tom fica cada vez mais resignado.

Aceitação: Você termina usando um workaround horrível. Você lamenta. Mas aceita. É a vida.

O Documento Histórico Final

Em algum ponto, aquele issue vira um documento histórico. Um artefato. Os comentários leem como um romance de tragédia grega.

Pessoas de diferentes épocas encontram aquele issue. De 2015: “Also experiencing this in version 3.4”. De 2018: “Still an issue in 5.1”. De 2023: “Surprised this isn’t fixed yet”.

O maintainer original? Sumiu. Provavelmente tá criando startups de IA em San Francisco. Não tá nem sabendo que o repositório ainda existe.

Novos maintainers chegam. Veem o issue. Pensam “vou colocar na roadmap”. Roadmap? Que roadmap? A pessoa saiu, nunca terminou documentação.

Os Culpados Invisíveis

Mas quem é culpado? É complicado.

O maintainer que tá sozinho mantendo 47 repositórios? Culpado? Mas tá fazendo isso de graça enquanto trabalha full-time em outra empresa.

Os 50mil usuários que usam a lib mas ninguém contribui? Talvez um pouco culpados.

A pessoa que abriu o issue e nunca mais voltou? Também tá ocupada.

A empresa que deveria investir em open source mas investe em crypto em vez disso? Essa, SIM.

Os Comentários Que Matam Esperança

Tem um tipo de comentário que é praticamente um requiem. O “this should be fixed” ou “duplicate of #348” (que também nunca foi resolvido).

Pior ainda: “marking as stale”. Aquela label que significa “você vai ser deletado em 30 dias porque ninguém se importa mais”.

Aí você tem 30 dias de aviso prévio. Como um visto de deportação digital.

E muita gente comenta desesperada no último dia: “PLEASE DON’T DELETE, I STILL HAVE THIS BUG”. E a issue é “revived” por mais 30 dias de agonia.

O Fechamento Que Nunca Chega

Algumas issues vivem para sempre. Literalmente. Seu repositório favorito tem issues de 2009.

Linguagem Python evoluiu 5 vezes. GitHub redesignhou a interface 4 vezes. Mas aquele issue de 2009? Segue lá, com 3 comentários de pessoas perguntando “alguém sabe se isso foi corrigido?”.

A resposta? Não. E talvez nunca seja.

O Que Aprendemos

Open source é incrível. Mas também é um lembrete de que nem tudo tem solução. Nem tudo é importante o suficiente.

Alguns bugs são features. Alguns problemas só viram “problemas conhecidos”. Alguns issues são apenas… eternas.

Se você abriu um GitHub issue uma vez, e nunca mais voltou, provável que aquele repositório também esqueceu de você.

Mas não se sinta mal. Tá todo mundo nesse barco. Um barco gigante de código abandonado e esperança.

E Aquele Issue Em 2012?

Ainda tá lá. Com 142 comentários agora. Último comentário? “still broken”. De 3 semanas atrás.

Talvez em 2035, alguém chegue, analise tudo, e descubra que era um typo de espaço branco.

Ou talvez continue lá para sempre. Testemunha eterna da imperfeição do código.

Bem-vindo ao GitHub. Onde os sonhos morrem um issue por vez.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *