Rejected GitHub Profile Achievements - Colección de logros de perfil de GitHub rechazados

 (github.com/Flet)
1 puntos por GN⁺ 2023-07-06 | 1 comentarios | Compartir por WhatsApp
  • Una colección que reúne y enumera logros rechazados al crear la función GitHub Profile Achievements
  • Cada elemento es una lista compuesta por el título del logro, un prototipo de insignia y las condiciones para obtenerlo
  • Entre los logros de ejemplo hay condiciones como tener más de 100 comentarios en issues compuestos solo por +1 o un emoji de pulgar arriba, commitear por accidente una secret API key en un repositorio público, o commitear directamente a la branch main y romper el build process
  • Otros ejemplos incluyen tener más de 1,000 issues abiertos en un repositorio público propio, mantener 150 o más branches que fueron mergeadas pero no eliminadas, y revisar y aprobar en 15 segundos un pull request de más de 10,000 líneas
  • Es un proyecto de broma que se presenta explícitamente como “This is a joke”, y se indica que aceptan PRs
  • Indica que se inspiró en Schweinepriester/github-profile-achievements y que las insignias fueron creadas con base en el arte de OpenMoji

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-06
Opiniones de Hacker News

  • Propuesta: “The Artist” para la gente que sube capturas del terminal en vez de copiar y pegar texto, y “The Filmmaker” para la gente que sube un GIF de la sesión del terminal en vez de escribir lo que hizo
    ¡A los maintainers realmente les encantan los artistas y los cineastas!

    • “The Novelist”: la persona que deja solo “doesn't work” en un issue o hilo, sin explicar qué intentó, por qué concluyó que no funcionaba ni cuál fue el mensaje de error
      “Captain Obvious”: la persona que abre un issue muy agresivo diciendo que el proyecto no se instala, y cuando el maintainer responde pidiéndole que verifique si no pasó por alto una indicación importante bien documentada, desaparece y no vuelve a responder jamás
    • Al depurar, los videos y GIFs son realmente buenos
      Muchas veces capturan pequeños detalles mucho mejor que la explicación de una persona. A veces el bug depende de una acción que puede hacerse de varias formas, o el usuario quizá ni siquiera se da cuenta de que lo que hizo justo antes de provocar el bug es parte del problema. También puede ocurrir solo bajo condiciones como cierto tamaño de pantalla, colores del terminal o si se usa pantalla táctil
      Con un video es mucho más fácil notar esas cosas. No es perfecto, y lo ideal es que venga acompañado de una explicación detallada; mejor aún si además pegan el error o el texto importante para poder copiarlo. Aun así, si tuviera que elegir entre uno de los dos, muchas veces prefiero el video al texto
      Así que en este contexto sí me gusta sinceramente “Filmmaker”. Manden capturas y también manden videos
    • “Wikipedian”: revierte un commit menos de 10 minutos después de haberlo empujado a main
      “Social distancer”: envía un commit que solo agrega espacios
      “Edgycat”: contribuye o propone un badge para este repositorio. Estoy ganando ese badge ahora mismo
      “Duct tape”: envía tres commits seguidos con el texto fix tests
    • Por favor, no manden texto del terminal como captura en vez de copiarlo y pegarlo
      Curiosamente, de gente técnica recibo muy seguido capturas de texto. Logs, mensajes de error, lo que sea, todo en imagen. Parece que creen que Slack es una herramienta que solo permite mandar imágenes y emojis
      No pienso tipear a mano palabras clave de tres páginas de una excepción de Java, ni transcribir un mensaje codificado de credenciales de AWS
    • “not helping”: deja un comentario de poco esfuerzo que no ayuda en nada
      “Internet famous”: el repositorio tiene un bug tan grave que hasta sale en artículos
      Ambos se me ocurrieron pensando en https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

  • “Unpopular opinion”: un comentario en un issue recibe más de 100 dislikes
    “I will raise with the team”: un issue o pull request con más de 100 likes sigue abierto por más de un año
    “For legal reasons”: se envía un pull request para corregir un issue, pero se cierra automáticamente por no firmar el CYA
    “Business Model Blues”: cambia más del 50% del texto del archivo LICENSE
    “Back from the dead”: deja un comentario en un issue o pull request abierto hace más de un año

  • Si hay más de 1,000 issues abiertos en un repositorio público, de verdad hace falta un badge de “This is fine”
    Hay muchísimos más proyectos open source que hace 10 años, y especialmente en JavaScript hay muchos proyectos con cantidades increíbles de bugs abiertos
    El problema es que muchos de esos bugs parecen ser de baja calidad. Entonces, incluso si un desarrollador experimentado con bastante trayectoria en contribuciones abre un bug para ayudar, es fácil que simplemente lo ignoren
    Ahora mismo estoy esperando en next.js un bug donde un 404 no devuelve 404, y lleva meses abierto (https://github.com/vercel/next.js/issues/51021). No tengo tiempo para escribir un pull request, pero entre tantos pull requests y reportes de bugs que ya he escrito, y mi participación en varios proyectos open source, diría que ya hice lo mío
    Aunque suene elitista, sería bueno que los maintainers tuvieran alguna forma de ordenar los bugs por la reputación del reportante. Así los proyectos podrían priorizar issues de mayor calidad

    • Ojalá existiera una manera de intercambiar valor. Por ejemplo, licencias pagadas, niveles de soporte y esas cosas que los antiguos romanos llamaban “hacer negocios”. /s
      Pero no, todo tiene que ser gratis, y luego sorprendentemente se acumulan los issues abiertos y nadie quiere atenderlos
    • Esto no significa “1,000 issues abiertos que yo creé en repositorios públicos”, sino 1,000 issues abiertos en un repositorio público que me pertenece
      Las dos cosas son interesantes

  • “The thief”: cuando tu forma de interactuar con open source consiste en cerrar pull requests y fusionar manualmente ese diff con tu propio nombre
    Esto pasa bastante en proyectos manejados por grandes empresas y, aunque seguramente haya razones de compliance, desde afuera se ve bastante sospechoso

    • Está bastante fuerte; ¿puedes mencionar algún proyecto conocido que haga eso?

  • Personalmente me decepciona que no exista mi favorita: abrir más de 50 issues de solicitud de funcionalidad sin ninguna otra contribución

    • El nombre del logro podría ser “I'm more of an idea person” o “chop-chop”
    • ¿Qué tal un logro tipo “hizo 10 contribuciones y las dejaron tiradas sin revisar durante más de un año”?
    • “Architecture Astronaut”
    • Para un usuario común, esta es la única forma de contactar al autor
    • “Idea guy”

  • Obtuve “patient skeleton” dos veces
    Lo realmente sorprendente es que una de ellas se fusionó después de 2 años. No hubo conversación alguna sobre ese pull request y, como era un proyecto con poca actividad, simplemente pasó desapercibido. Yo ya me había rendido y había dejado requirements.txt apuntando a mi fork
    Otra persona abrió un issue por el mismo problema que resolvía mi viejo pull request, y cuando respondí en ese issue que el pull request lo solucionaba, esa actividad hizo que por fin lo vieran
    El otro sigue pendiente

    • El valor no recuperado atrapado en forks de proyectos que no se han fusionado al mainline, con apenas un cambio importante, fácilmente debe sumar decenas de miles de millones de dólares

  • Propongo “YOLO”: ignorar una alerta de Dependabot por más de 3 meses
    Este premio prácticamente podría llevar mi nombre

  • Para aclarar, estos no son logros rechazados por GitHub, sino solo ideas de humor creadas por “flet”, un desarrollador no afiliado a GitHub

    • ¡Felicidades por desbloquear el logro Captain Obvious!

  • Propongo dar un logro “Copium” por darle estrella a tu propio repositorio

    • No estoy seguro, pero creo que antes GitHub te ponía estrella automáticamente a tu repositorio cuando lo creabas
    • “Narcissist” quizá sería más apropiado

  • “Type O Contributor”: cuando tu única contribución son correcciones menores de ortografía y gramática

    • Esto no puede ser un logro, porque podrían revertírtelo y quitártelo
    • Yo también he hecho esto de vez en cuando; ¿ese tipo de contribuciones no son bienvenidas?
    • “Typo-O donor” estaría bien