- Kho lưu trữ Ghostty không cho phép người dùng tự tạo Issue trực tiếp, mà trước hết phải bắt đầu thảo luận trong GitHub Discussions
- Dự án không dùng issue tracker để thảo luận bug hay yêu cầu tính năng, mọi trao đổi đều diễn ra trong Discussions
- Khi nội dung thảo luận đã đủ cụ thể và được sắp xếp thành hạng mục có thể thực hiện, quản trị viên sẽ chuyển nó thành Issue
- Cách làm này là một cấu trúc giúp maintainer và contributor nhanh chóng tìm ra các issue thực sự có thể xử lý
- Vì phần lớn báo cáo là vấn đề môi trường người dùng, hiểu nhầm hoặc yêu cầu tính năng chưa được triển khai, quy trình này rất quan trọng đối với việc kiểm soát chất lượng dự án
Chính sách hạn chế tạo Issue
- Trong kho lưu trữ Ghostty, người dùng không thể tự tạo Issue trực tiếp
- Thay vào đó, trước tiên cần chia sẻ vấn đề hoặc đề xuất trong GitHub Discussions
- Nếu quản trị viên xem xét và xác nhận đó là vấn đề có thể tái hiện rõ ràng, họ sẽ chuyển nó thành Issue
- Cách làm này nhằm giữ cho issue tracker chỉ chứa những hạng mục thực sự có thể xử lý
- Vì mọi Issue đều đã được làm rõ từ trước, contributor có thể bắt tay vào làm ngay
Nguyên tắc vận hành issue tracker
- Ghostty không sử dụng issue tracker cho thảo luận hay yêu cầu tính năng
- Yêu cầu tính năng hoặc câu hỏi chung được xử lý trong Discussions
- Issue chỉ chứa bug được định nghĩa rõ ràng hoặc hạng mục công việc có thể thực thi
- Cách tiếp cận này là nguyên tắc vận hành được hình thành từ kinh nghiệm duy trì dự án mã nguồn mở
- Theo kinh nghiệm trước đây, 80~90% báo cáo của người dùng thực ra không phải bug mà là hiểu nhầm hoặc vấn đề môi trường
- Phần lớn số còn lại là yêu cầu tính năng chưa được triển khai, và thường cần thêm đặc tả
Cải thiện hiệu quả bảo trì
- Khi đi qua bước Discussions, maintainer có thể chỉ quản lý các vấn đề đã được kiểm chứng dưới dạng Issue
- Giảm các báo cáo trùng lặp không cần thiết hoặc bug report sai
- Danh sách Issue được sắp xếp xoay quanh các hạng mục có thể xử lý ngay
- Người dùng không cần làm thêm bước nào ngay cả khi tìm ra vấn đề hợp lệ
- Quản trị viên sẽ trực tiếp chuyển nó thành Issue để xử lý
Tài liệu tham khảo
- Có thể xem quy trình chi tiết và hướng dẫn đóng góp trong tệp CONTRIBUTING.md
- Tài liệu đó nêu rõ cách tham gia Discussions và tiêu chí chuyển sang Issue
3 bình luận
Ý kiến trên Hacker News
Hoàn toàn đồng ý. Nếu là dự án của người khác thì quyền quyết định đó có phải issue hay không hoàn toàn thuộc về họ
Dự án càng lớn thì càng có nhiều người không đọc thông báo, đưa ra yêu cầu kỳ quặc, thậm chí còn thổi phồng CVE bằng AI
Dù người dùng không hiểu ý nghĩa của lỗi, ít nhất họ cũng phải cho biết đã hiện lỗi gì
Trước đây khi test, tôi đã nêu rõ là “broken pipe error”, nhưng kỹ sư lại đóng với lý do “không thể tái hiện”, rồi chính họ cũng nói không tái hiện được vì cùng lỗi đó
Hầu hết tracker đều có thể phân loại bằng trạng thái như “unconfirmed”, còn Github chỉ là một hệ thống thảo luận đơn giản nên rất khó quản lý
Tôi đã mất 4 tiếng phản biện bằng code và lập luận, nhưng câu trả lời nhận lại chỉ là “shrugs AI”
“Facebookization” đã tạo ra nhận thức rằng chỉ cần vài cú nhấp chuột là xong mọi thứ, và giờ có vẻ “LLMization” sẽ khiến chuyện đó còn tệ hơn
Cách tiếp cận này không phù hợp với phần mềm chuyên môn, nhưng kỳ vọng thì đã được hình thành như vậy rồi
Việc Ghostty phân loại yêu cầu thông qua thảo luận là một cách tiếp cận độc đáo nhưng hiệu quả
Việc điều tra rò rỉ bộ nhớ đang bị phân tán trên nhiều nền tảng
Liên kết X 1, Liên kết X 2, Thảo luận 1, Thảo luận 2
Vẫn chưa được nâng thành issue chính thức
Ngay cả trên hệ thống 8GB, chỉ cần mở terminal vài lần là đã bị thiếu bộ nhớ
Foot ít tính năng hơn nhưng ổn định hơn rất nhiều
Liên kết thứ hai có vẻ chỉ là cố gắng tranh cãi
Tôi đã phân tích log bằng Claude Code và tạm thời sửa được, giờ chỉ còn tái hiện 1 lần trong 10 lần
Hy vọng điều này sẽ giúp ích khi ai đó điều tra thêm
Ngay cả GPU tích hợp cũng gặp vấn đề, nhưng lúc nào cũng bị đổ cho GTK hoặc Nvidia
Tôi nghĩ việc phân biệt giữa “Issues” và “Discussions” là kém hiệu quả
Phải tìm trùng lặp ở cả hai nơi, và cũng không thể di chuyển ticket
Nếu theo dõi tiếp qua email thì thông báo lại bị đứt quãng
Vì thế trong dự án của tôi, tôi đã tắt Discussions
Nếu đúng là bug thật thì lúc đó chuyển thành issue là được
Chỉ cần quản trị viên gắn nhãn “bug” là đủ
Khi thảo luận đã được chắt lọc xong thì lúc đó tạo issue cũng được
Thông báo cũng vẫn được giữ nguyên
Một số dự án lớn trong cộng đồng Python cũng dùng cách này
Nhưng từ góc nhìn của power user thì quy trình báo lỗi khá phiền phức
Thái độ kiểu “dự án của chúng tôi là hoàn hảo” nghe khá ngạo mạn
Phần lớn các báo cáo lỗi kiểu drive-by đều vô dụng, thậm chí chỉ là nhiễu
Nếu thật sự muốn đóng góp thì sửa một bug đã được xác định còn tốt hơn
Việc đặt ra giới hạn với cách gửi báo cáo là hoàn toàn bình thường
Trước ý kiến rằng mọi issue đều phải ở trạng thái sẵn sàng để bắt tay vào làm,
có người hỏi: “Vậy thì chỉ cần gắn tag ‘ready-to-be-worked-on’ là được mà?”
Hệ thống này đã thành công hơn nhiều
Vì thế họ mới tách riêng không gian cho nhà phát triển và không gian cho người dùng
Issues sẽ không thể quản lý nổi khi quy mô tăng lên
Dùng Discussions như một bộ lọc sẽ hiệu quả hơn
Hai tính năng này của Github có UI gần như giống hệt nhau
Chỉ khác là Discussions có tính năng upvote
curl/curl/issues
Cũng có ý kiến cho rằng cách này nên trở thành mặc định
Cộng đồng phụ trách thảo luận, còn người đóng góp phụ trách issue là cấu trúc lý tưởng
Hệ thống nhãn của GitHub cũng đủ để xử lý rồi
Tài liệu quản lý nhãn của GitHub
Kiểu như Natural experiment vậy
Tôi đồng ý với chính sách người dùng gửi báo cáo theo cách này
Nhìn các thảo luận đã đóng thì nó khá giống issue đã đóng, nhưng ít nhất giảm được nhiễu trong tab issue
Danh sách thảo luận đã đóng của Ghostty
Nhiều discussion không đi đến bước đó, nhưng vấn đề của người dùng vẫn được giải quyết
Tôi nghĩ cấu trúc phân tách này là một thiết kế khá thông minh
Thực ra việc “không thể mở issue” không phải là tính năng của GitHub,
mà chỉ là dòng hướng dẫn trong template bảo rằng “đừng mở issue mới, hãy dùng Discussions”
Tôi đã thấy cách làm này ở các dự án khác,
và cấu trúc lấy thảo luận làm điểm khởi đầu trông khá hợp lý
Chỉ là nhiều dự án vẫn chưa bật GitHub Discussions thôi
Điểm khác giữa cuộc thảo luận đó với issue là gì? Issue không phải là “bug”. Dù là bug, đề xuất tính năng hay PR… nếu có điều gì đáng để thảo luận thì đó là issue.
Nếu không đáng để thảo luận thì cứ đóng lại là được.
Không phải vì Discussion và Issue khác nhau, mà đơn giản là việc tách chúng ra thành các tab riêng phù hợp với sở thích hơn thôi.
Đăng cả một kiểu danh sách việc cần làm lẫn Discussion trong tab Issue rồi quản lý bằng thẻ
vs
chỉ dùng tab Issue như danh sách việc cần làm, còn Discussion thì chỉ dùng cho Discussion