Rejected GitHub Profile Achievements - Bộ sưu tập thành tích GitHub Profile bị từ chối

• Một bộ sưu tập liệt kê các thành tích bị từ chối khi tạo tính năng GitHub Profile Achievements
• Mỗi mục là một danh sách gồm tiêu đề thành tích, nguyên mẫu huy hiệu và điều kiện để đạt được
• Các thành tích ví dụ gồm vượt quá 100 bình luận issue chỉ có +1 hoặc emoji ngón tay cái, vô tình commit secret API key lên public repository, hoặc commit trực tiếp vào nhánh main làm hỏng build process
• Các ví dụ khác gồm có hơn 1.000 open issue trong public repository do mình sở hữu, duy trì hơn 150 branch đã được merge nhưng chưa xóa, hoặc review và approve một pull request dài hơn 10.000 dòng trong vòng 15 giây
• Đây là một dự án mang tính đùa vui được ghi rõ là “This is a joke”, và có nói rằng họ nhận PR
• Có ghi rằng dự án được lấy cảm hứng từ Schweinepriester/github-profile-achievements, và các huy hiệu được làm dựa trên artwork của OpenMoji

[GN⁺]

Ý kiến trên Hacker News

• Đề xuất: “The Artist” dành cho người đăng ảnh chụp màn hình terminal thay vì sao chép rồi dán văn bản, “The Filmmaker” dành cho người đăng GIF phiên terminal thay vì viết ra họ đã làm gì
  Các maintainer đúng là rất yêu nghệ sĩ và đạo diễn!

  • “The Novelist”: người chỉ để lại đúng câu “doesn't work” trong issue hay thread mà không nói đã thử gì, vì sao nghĩ là không được, hay thông báo lỗi là gì
    “Captain Obvious”: người mở một issue rất hung hăng vì dự án không cài được, rồi khi maintainer trả lời bảo hãy kiểm tra xem có bỏ sót hướng dẫn quan trọng đã được ghi rõ trong tài liệu hay không, thì biến mất luôn và không bao giờ trả lời nữa
  • Khi debug thì video và GIF thực sự rất hữu ích
    Nhiều khi chúng bắt được những chi tiết nhỏ tốt hơn hẳn phần mô tả của con người. Bug có thể phụ thuộc vào một hành vi có thể thực hiện theo nhiều cách, hoặc người dùng có thể không biết rằng hành động họ vừa làm ngay trước khi gây ra bug là một phần của vấn đề. Nó cũng có thể chỉ xảy ra ở các điều kiện như kích thước màn hình cụ thể, màu terminal, hay có dùng màn hình cảm ứng hay không
    Nếu có video thì sẽ dễ nhận ra những điều đó hơn nhiều. Nó không hoàn hảo, và tốt nhất là có video kèm mô tả chi tiết, cùng với việc dán cả lỗi hay đoạn văn bản quan trọng để có thể sao chép được. Nhưng nếu phải chọn một trong hai thì nhiều khi tôi vẫn thích video hơn văn bản
    Vì vậy trong ngữ cảnh này tôi thật lòng thích “Filmmaker”. Hãy gửi cả ảnh chụp màn hình lẫn video
  • “Wikipedian”: revert commit trong vòng 10 phút sau khi push lên main
    “Social distancer”: gửi một commit chỉ thêm khoảng trắng
    “Edgycat”: đóng góp hoặc đề xuất huy hiệu cho repo này. Tôi đang cố kiếm đúng huy hiệu này
    “Duct tape”: gửi ba commit liên tiếp có chứa dòng fix tests
  • Làm ơn đừng gửi ảnh chụp màn hình thay vì sao chép rồi dán văn bản terminal
    Kỳ lạ là tôi thường xuyên nhận được ảnh chụp văn bản từ những người làm kỹ thuật. Log file, thông báo lỗi, cái gì cũng gửi bằng ảnh. Cứ như thể họ nghĩ Slack là công cụ chỉ để gửi ảnh và emoji vậy
    Tôi không định tự gõ lại từ khóa từ 3 trang exception Java, cũng không định chép tay thông điệp xác thực AWS đã mã hóa
  • “not helping”: để lại bình luận ít nỗ lực hoàn toàn không giúp ích gì
    “Internet famous”: repo có bug nghiêm trọng đến mức còn bị lên bài
    Cả hai đều được nghĩ ra khi nhớ tới https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

• “Unpopular opinion”: một bình luận trong issue nhận hơn 100 lượt dislike
  “I will raise with the team”: issue hoặc pull request có hơn 100 lượt like nhưng vẫn bị mở hơn 1 năm
  “For legal reasons”: đã có pull request sửa issue nhưng bị tự động đóng vì không ký CYA
  “Business Model Blues”: hơn 50% nội dung file LICENSE bị thay đổi
  “Back from the dead”: để lại bình luận trên một issue hoặc pull request đã mở từ hơn 1 năm trước

• Nếu repo công khai có hơn 1.000 issue đang mở thì thật sự cần một huy hiệu “This is fine”
  So với 10 năm trước, số lượng dự án mã nguồn mở đã tăng quá nhiều, và đặc biệt bên JavaScript có rất nhiều dự án với lượng bug đang mở khó tin
  Vấn đề là phần lớn những bug đó có vẻ chất lượng thấp. Vì vậy ngay cả khi một lập trình viên giàu kinh nghiệm đóng góp muốn giúp bằng cách mở bug, họ cũng rất dễ bị phớt lờ
  Tôi đang chờ bug trong next.js là 404 không trả về 404 được sửa, mà nó đã mở mấy tháng rồi (https://github.com/vercel/next.js/issues/51021). Tôi không có thời gian viết pull request, nhưng trước giờ cũng đã viết vô số pull request và báo cáo bug, lại còn tham gia nhiều dự án mã nguồn mở, nên tôi nghĩ mình cũng làm đủ phần của mình rồi
  Dù hơi mang tính tinh hoa, sẽ rất hay nếu maintainer có cách sắp xếp bug theo uy tín của người báo cáo. Như vậy dự án có thể ưu tiên những issue chất lượng cao

  • Giá mà có cách để mọi người trao đổi giá trị với nhau. Ví dụ như giấy phép trả phí, cấp hỗ trợ, những thứ mà người La Mã cổ gọi là “điều hành doanh nghiệp”. /s
    Nhưng không, mọi thứ đều phải miễn phí, rồi ai ngờ được là issue mở cứ chất đống và chẳng ai muốn xử lý
  • Ý ở đây không phải là “1.000 issue mở do tôi tạo trong repo công khai”, mà là 1.000 issue mở trong repo công khai do tôi sở hữu
    Cả hai đều thú vị theo cách riêng

• “The thief”: cách ai đó tiếp cận mã nguồn mở là đóng pull request lại, rồi tự tay merge phần khác biệt dưới tên của chính mình
  Chuyện này xảy ra khá nhiều trong các dự án do tập đoàn lớn vận hành, chắc vì lý do tuân thủ, nhưng nhìn bề ngoài thì khá đáng ngờ

  • Khá nghiêm trọng đấy, có thể cho ví dụ dự án nào nổi bật làm vậy không?

• Tôi hơi tiếc vì không có cái nào là món mình thích nhất. Trường hợp mở hơn 50 issue yêu cầu tính năng nhưng ngoài ra không có đóng góp nào khác

  • Tên thành tựu có thể là “I'm more of an idea person” hoặc “chop-chop”
  • Thành tựu kiểu “có 10 đóng góp nhưng bị bỏ mặc hơn 1 năm mà không được review” thì sao?
  • “Architecture Astronaut”
  • Với người dùng phổ thông thì đây là cách duy nhất để liên hệ với tác giả
  • “Idea guy”

• Tôi đã nhận “patient skeleton” hai lần
  Điều thực sự đáng kinh ngạc là một trong số đó được merge sau hơn 2 năm. Không có cuộc trao đổi nào về pull request đó, và vì dự án ít hoạt động nên nó đơn giản là không ai để ý tới. Tôi đã bỏ cuộc và để requirements.txt trỏ sang fork của mình
  Sau đó có người khác mở một issue vì cùng vấn đề mà pull request cũ của tôi sửa được, và khi tôi trả lời trong issue đó rằng pull request ấy giải quyết được, chính hoạt động đó cuối cùng đã khiến nó được chú ý
  Cái còn lại thì đến giờ vẫn đang chờ

  • Giá trị bị mắc kẹt trong những dự án fork chưa được thu hồi, nơi chỉ có một thay đổi quan trọng nhưng không được merge vào mainline, có lẽ dễ dàng lên tới hàng chục tỷ USD

• Tôi đề xuất “YOLO”. Dành cho trường hợp bỏ qua cảnh báo Dependabot hơn 3 tháng
  Có thể coi như giải này đã khắc tên tôi rồi

  • Thực ra đã có thành tựu YOLO thật rồi. Ý nghĩa là “merge pull request của chính mình mà không qua review code”
    Danh sách đầy đủ các thành tựu thật ở đây: https://github.com/Schweinepriester/github-profile-achieveme...

• Nói chính xác hơn thì đây không phải là các thành tựu bị GitHub từ chối, mà chỉ là các ý tưởng đùa vui do “flet”, một lập trình viên không liên quan đến GitHub, nghĩ ra

  • Chúc mừng bạn đã mở khóa thành tựu Captain Obvious!

• Có người đề xuất nếu tự bấm sao cho repo của mình thì nên được thành tựu “Copium”

  • Không chắc lắm, nhưng hình như trước đây GitHub từng tự động bấm sao cho repo khi bạn tạo nó
  • “Narcissist” có thể còn phù hợp hơn

• “Type O Contributor”: đóng góp duy nhất là những chỉnh sửa chính tả và ngữ pháp nhỏ nhặt

  • Cái này không thể là thành tựu được. Vì nó có thể bị revert và tước mất
  • Tôi cũng thỉnh thoảng làm kiểu này, những đóng góp như vậy là không được chào đón sao?
  • “Typo-O donor” nghe hay đấy