Rejected GitHub Profile Achievements — coleção de conquistas rejeitadas para perfis do GitHub

 (github.com/Flet)
1 pontos por GN⁺ 2023-07-06 | 1 comentários | Compartilhar no WhatsApp
  • Uma coleção que reúne e lista conquistas rejeitadas durante a criação do recurso GitHub Profile Achievements
  • Cada item é uma lista composta pelo título da conquista, um protótipo de badge e os critérios para obtê-la
  • Exemplos de conquistas incluem ter mais de 100 comentários em issues contendo apenas +1 ou um emoji de joinha, commitar acidentalmente uma secret API key em um repositório público, ou fazer commit diretamente na branch main e quebrar o processo de build
  • Outros exemplos incluem ter mais de 1.000 issues abertas em um repositório público próprio, manter 150 ou mais branches que já foram mescladas mas não foram excluídas, e revisar e aprovar em 15 segundos um pull request com mais de 10.000 linhas
  • É um projeto de brincadeira que deixa claro “This is a joke”, e informa que aceita PRs
  • Diz que foi inspirado em Schweinepriester/github-profile-achievements e que os badges foram criados com base na arte do OpenMoji

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-06
Opiniões do Hacker News

  • Sugestão: “The Artist” para quem publica captura de tela do terminal em vez de copiar e colar o texto, e “The Filmmaker” para quem publica GIF da sessão do terminal em vez de escrever o que fez
    Os mantenedores realmente adoram artistas e cineastas!

    • “The Novelist”: pessoa que deixa apenas “doesn't work” numa issue ou thread, sem dizer o que tentou, por que concluiu que não funcionava, nem qual foi a mensagem de erro
      “Captain Obvious”: pessoa que abre uma issue extremamente agressiva dizendo que o projeto não instala e, quando o mantenedor responde pedindo para verificar se não deixou passar alguma instrução importante bem documentada, some e nunca mais responde
    • Vídeos e GIFs são realmente ótimos na hora de depurar
      Muitas vezes capturam pequenos detalhes muito melhor do que a explicação da pessoa. O bug pode depender de uma ação que pode ser feita de várias maneiras, ou o usuário pode nem perceber que algo que fez logo antes de causar o bug faz parte do problema. Também pode acontecer só em condições como determinado tamanho de tela, cor do terminal ou uso de touchscreen
      Com vídeo fica muito mais fácil perceber essas coisas. Não é perfeito, e o ideal é ter vídeo junto com uma explicação detalhada; melhor ainda se também colarem erros ou textos importantes para que possam ser copiados. Ainda assim, se eu tiver que escolher um dos dois, muitas vezes prefiro vídeo a texto
      Então, nesse contexto, eu sinceramente gosto de “Filmmaker”. Mandem capturas de tela e mandem vídeos também
    • “Wikipedian”: reverte um commit em até 10 minutos depois de dar push na main
      “Social distancer”: envia um commit que só adiciona espaços em branco
      “Edgycat”: contribui ou sugere um badge para este repositório. Estou conquistando esse badge agora
      “Duct tape”: envia três commits seguidos com o texto fix tests
    • Por favor, não mandem captura de tela do texto do terminal em vez de copiar e colar
      Estranhamente, recebo com frequência capturas de tela de texto de gente da área técnica. Mandam arquivo de log, mensagem de erro, qualquer coisa em imagem. Parece que acham que o Slack é uma ferramenta que só permite enviar imagens e emoji
      Eu não vou digitar manualmente palavras-chave de três páginas de exceção Java, nem transcrever na mão uma mensagem codificada de credenciais da AWS
    • “not helping”: deixa um comentário preguiçoso que não ajuda em nada
      “Internet famous”: o repositório tem um bug tão grave que sai até matéria sobre isso
      Ambos me vieram à cabeça por causa de https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

  • “Unpopular opinion”: um comentário numa issue recebe mais de 100 dislikes
    “I will raise with the team”: uma issue ou pull request com mais de 100 likes fica aberta por mais de 1 ano
    “For legal reasons”: sobe um pull request corrigindo a issue, mas ele é fechado automaticamente por não assinar o CYA
    “Business Model Blues”: mais de 50% do texto do arquivo LICENSE muda
    “Back from the dead”: comenta numa issue ou pull request aberta há mais de 1 ano

  • Se um repositório público tem mais de 1.000 issues abertas, realmente precisa de um badge “This is fine”
    Hoje existem projetos open source demais em comparação com 10 anos atrás e, especialmente no ecossistema JavaScript, há muitos projetos com uma quantidade inacreditável de bugs em aberto
    O problema é que a maioria desses bugs parece ser de baixa qualidade. Então, mesmo quando um desenvolvedor experiente com bastante histórico de contribuição abre um bug para ajudar, é fácil ele simplesmente ser ignorado
    Neste momento estou esperando uma correção no next.js para um bug em que 404 não retorna 404, e ele está aberto há meses (https://github.com/vercel/next.js/issues/51021). Não tenho tempo de escrever um pull request, mas já escrevi muitos pull requests e relatórios de bug ao longo do tempo e participei de vários projetos open source, então acho que já fiz minha parte
    É elitista, mas eu gostaria que mantenedores tivessem uma forma de ordenar bugs pela reputação de quem reporta. Assim, os projetos poderiam priorizar issues de alta qualidade

    • Eu queria que existisse alguma forma de as pessoas trocarem valor. Tipo licenças pagas, níveis de suporte e essas coisas que os antigos romanos chamavam de “tocar um negócio”. /s
      Mas não, tudo tem que ser grátis e, surpreendentemente, as issues abertas se acumulam e ninguém quer cuidar delas
    • Isso não quer dizer “1.000 issues abertas que eu criei em repositórios públicos”, e sim 1.000 issues abertas em um repositório público que eu possuo
      Os dois casos são interessantes

  • “The thief”: quando a forma de lidar com open source é fechar pull requests e fazer merge manual em seu próprio nome daquelas mudanças
    Isso acontece bastante em projetos mantidos por grandes empresas e, embora possa ser por motivos de compliance, por fora parece bem suspeito

    • Isso é bem grave; pode citar algum projeto conhecido que faça isso?

  • Pessoalmente, lamento não haver meu favorito: quando alguém abre mais de 50 issues de solicitação de recurso e não faz nenhuma outra contribuição

    • O nome do achievement poderia ser “I'm more of an idea person” ou “chop-chop”
    • Que tal um achievement como “10 contribuições feitas e abandonadas sem revisão por mais de 1 ano”?
    • “Architecture Astronaut”
    • Para usuários comuns, essa é a única forma de entrar em contato com o autor
    • “Idea guy”

  • Ganhei “patient skeleton” duas vezes
    O realmente surpreendente é que uma delas foi mergeada depois de 2 anos. Não houve conversa alguma naquele pull request e, como era um projeto com pouca atividade, ele simplesmente passou despercebido. Eu já tinha desistido e deixado meu requirements.txt apontando para meu fork
    Outra pessoa abriu uma issue pelo mesmo problema que meu antigo pull request corrigia, e quando respondi nessa issue que o pull request resolvia aquilo, essa atividade finalmente fez alguém perceber
    A outra ainda está pendente

    • O valor não recuperado preso em projetos forkados que contêm apenas uma mudança importante, sem nunca terem sido mergeados no código principal, deve facilmente chegar à casa dos bilhões de dólares

  • Sugiro “YOLO”: quando a pessoa ignora alertas do Dependabot por mais de 3 meses
    Pode considerar que esse prêmio já tem meu nome nele

  • Corrigindo: estes não são achievements rejeitados pelo GitHub, e sim apenas ideias de piada criadas por “flet”, um desenvolvedor sem relação com o GitHub

    • Parabéns por desbloquear o achievement Captain Obvious!

  • Sugiro dar o achievement “Copium” quando alguém dá estrela no próprio repositório

    • Não tenho certeza, mas acho que antigamente o GitHub colocava estrela automaticamente quando você criava um repositório
    • Talvez “Narcissist” seja mais apropriado

  • “Type O Contributor”: quando a única contribuição da pessoa são pequenas correções de ortografia e gramática

    • Isso não pode ser um achievement. Dá para revogar depois com um revert
    • Eu mesmo às vezes fazia esse tipo de coisa; esse tipo de contribuição não é bem-vinda?
    • “Typo-O donor” seria bom