Phải làm gì với các vấn đề bị bỏ rơi trong GitHub?

Nếu ai đó mở một vấn đề trên GitHub nhưng có thêm thông tin để tạo lại lỗi được hỏi và không bao giờ được cung cấp, quy trình bình thường là gì? Ví dụ .

Ở đây tác giả nói rằng "phá vỡ điều hướng". Trong khi tôi tin rằng nó đã được sửa, tôi muốn từ tác giả để chắc chắn rằng chúng ta đã nói về điều tương tự. Nhưng đôi khi phóng viên của vấn đề chỉ biến mất. Đây có phải là một thực tiễn tốt / phổ biến để đặt ngày hết hạn cho các vấn đề bị bỏ rơi?

Một cái gì đó giống như những điều kiện này:

• Một câu hỏi được đặt ra về vấn đề này để có thể gỡ lỗi nó.
• Đã hơn 2-6 tháng trôi qua kể từ câu hỏi / bình luận chưa được trả lời cuối cùng từ nhóm nhà phát triển.
• Lỗi không thể được sao chép tại thời điểm đóng nó (vì bất kỳ lý do gì, có thể chúng không bao giờ được sao chép).
• Một cảnh báo được đưa ra 2 tuần trước khi đóng nó.

Các dự án thường làm gì? Tôi không thể tìm thấy bất cứ điều gì trên Google. Ngoài ra, làm thế nào tôi có thể làm tài liệu này? Có một ghi chú đơn giản trong README.md nêu chi tiết các điểm ở trên và một nhận xét trong vấn đề giải thích lý do tại sao nó bị đóng cửa không?

Lưu ý: nó khác với câu hỏi này vì lỗi vẫn có thể có liên quan (hoặc không), tuy nhiên thiếu thông tin.

Đây là một tiến thoái lưỡng nan: bạn có thể không đóng vấn đề này là "cố định", bởi vì bạn không thực sự biết nếu nó đã được cố định, hoặc ít nhất là ngay cả khi một số vấn đề đã được cố định, bạn không thực sự biết liệu điều này là vấn đề các phóng viên đã nói về. Mặt khác, bạn không muốn để lại một vấn đề có thể đã được sửa chữa mở, đặc biệt là nếu bạn sẽ không thể đóng nó vì bạn sẽ không bao giờ nhận được xác nhận.

Vì vậy, bạn nên đóng nó, nhưng có lẽ không phải là "cố định". Bạn có thể phát minh ra một lý do gần gũi tùy chỉnh "maybefixed" hoặc "unirirmedfix" nếu bạn muốn tích cực hoặc "báo cáo biến mất" nếu bạn không. Bạn cũng có thể chỉ nói "không thể sao chép" và chờ đợi cùng một lỗi xuất hiện để có một phóng viên phản ứng nhanh hơn.

Tuy nhiên, bạn không nên sử dụng tài nguyên cho một lỗi mà bạn sẽ không bao giờ biết liệu nó có thực sự được sửa hay không.

Câu hỏi chính của bạn đã được trả lời, nhưng bạn cũng đã hỏi về việc ghi lại quá trình và điều đó cũng cần trả lời.

Giải pháp tôi đã thấy trong nhiều dự án không phải là đưa nó vào README.md của dự án, mà là một đóng góp đặc biệt README - một tệp README cho những người đóng góp. Tệp này mô tả mọi thứ bạn muốn những người đóng góp cho dự án của bạn biết - có thể là về mã (quy ước đặt tên, tổ chức mô-đun, v.v.) hoặc về quy trình (cách viết cam kết, cách xử lý vé, v.v.). Tệp này có thể là một .MDtệp khác trong dự án hoặc được đặt trong một kho lưu trữ hoàn toàn khác (vì vậy nó có thể được chia sẻ giữa tất cả các dự án của bạn). Chỉ cần đừng quên liên kết với nó từ chính README.md!

Điểm tách biệt thông tin đó khỏi README chính là thường chỉ một phần người dùng của dự án trực tiếp đóng góp cho nó. Hầu hết người dùng không cần phải nhàm chán với thông tin đó - họ chỉ cần biết dự án của bạn làm gì và sử dụng nó như thế nào, và đó là những gì README chính nên chứa. Trong trường hợp dự án của bạn, phần đóng góp rất nhỏ nên nó không mã hóa README chính - nhưng nếu bạn ghi lại tất cả các quy trình công việc bạn muốn những người đóng góp theo dõi thì nó sẽ không còn phù hợp nữa ...

Lưu ý rằng bất kỳ người dùng nào cũng có thể mở một lỗi, vì vậy nếu bạn có yêu cầu đặc biệt về việc mở lỗi, bạn nên đặt chúng vào README chính (cố gắng giữ cho nó không hoạt động - không giống như những người đóng góp mã, các phóng viên lỗi có thể sẽ không sẵn sàng đi đến thời gian dài để nghiên cứu và tuân thủ các quy tắc của bạn). Tuy nhiên, người thực sự sửa lỗi và đóng vé (có thể là bạn hoặc một trong những người đóng góp mà bạn đã xác nhận) là người đóng góp trực tiếp và có thể dự kiến ​​sẽ đọc phần đóng góp README - vì vậy quá trình đóng vé khi phóng viên thực hiện không trả lời nên được mô tả ở đó.

Tôi đọc điều này như một câu hỏi về các thực tiễn xung quanh cách xử lý một lỗi chưa được xác minh (sử dụng trình theo dõi vấn đề của github) hơn bất kỳ điều gì khác.

Đối với tôi, đó là một câu trả lời khá thẳng về phía trước dựa trên các trình theo dõi vấn đề khác mà tôi đã sử dụng. Github không buộc bất kỳ ai sử dụng bất kỳ quy trình công việc nào và điều này làm cho nó rất linh hoạt ... và khá vô dụng trong cấu hình mặc định của nó.

Nhìn vào quy trình làm việc mặc định của Bugzilla, chúng tôi nhận được:

Tôi sẽ chỉ ra một điều rất quan trọng ở đó - nó được giải quyết như đã sửa trước khi nó bị đóng sau khi được xác minh . Quy trình công việc Github cơ bản chỉ hiển thị trạng thái màu đỏ (mở) và xanh lục (đóng).

Do đó, một cách tiếp cận là sử dụng các nhãn trong Github ( nhãn của ứng dụng của bạn ) để cố gắng hiển thị thông tin bổ sung. Bạn có thể tạo một cặp nhãn 'chưa được xác minh' và 'đã được xác minh' để áp dụng khi bạn đóng vấn đề. Lưu ý rằng đây chỉ là một cách tiếp cận - nếu bạn tìm kiếm, bạn có thể tìm thấy hàng tá cách tiếp cận khác nhau để sử dụng nhãn. Ở đây, câu hỏi Làm thế nào để quản lý các vấn đề github cho (ưu tiên, v.v.)? giải quyết điều này.

Bạn đã sửa nó, từ quan điểm của một nhà phát triển, nó đã được thực hiện. Đóng vấn đề trên Github. Áp dụng nhãn 'chưa được xác minh' cho nhãn đó. Khi ai đó quen với lỗi trong phiên bản trước nói "có, cái này đã sửa nó", bạn có thể thay đổi nhãn thành 'đã xác minh'. Nếu họ nói không, thì bạn mở lại.

Cũng lưu ý rằng có các trạng thái được giải quyết khác ngoài 'cố định'. Có 'wontfix' (cách khắc phục là điều không thể thực hiện được với cấu trúc hiện tại) và 'workforme' (lỗi không thể được sao chép) và 'không hợp lệ' (bạn đang gửi lỗi về HĐH, không phải các loại ứng dụng).

Tôi sẽ có một trong hai quan điểm, tùy thuộc vào mức độ tự tin của tôi khi tôi nói về điều tương tự như phóng viên ban đầu:

1) Vì phóng viên không còn nữa, nên coi rằng lỗi trong câu hỏi có nghĩa là bất cứ điều gì bạn đã sửa. Nếu nó giúp, đính kèm các trường hợp kiểm tra để làm rõ những thất bại bạn tìm thấy. Mô tả chi tiết về báo cáo lỗi về những gì bạn đã sửa và để lại một ghi chú như: "Tôi tin rằng đây là ý nghĩa của" sự cố điều hướng ", vui lòng mở lại hoặc đưa ra một lỗi mới nếu đó không phải là ý bạn". Đánh dấu lỗi là cố định.

2) Vì phóng viên không còn nữa, nên coi rằng lỗi không thể được sao chép (được biết là), vì chỉ từ của phóng viên cho nó sẽ xác nhận đó là điều tương tự họ đã báo cáo. Đưa ra một lỗi mới để mô tả điều bạn đã sửa, vì mục đích tín dụng đề cập rằng nó đã được quan sát theo các điều kiện được mô tả bởi người báo cáo vắng mặt, lưu ý rằng cả hai đều có thể trùng lặp, đánh dấu lỗi mới được sửa và đánh dấu lỗi này không hợp lệ hoặc không thể sao chép bằng một ghi chú như: "Tôi không thể hiểu ý của bạn là 'phá vỡ điều hướng', nhưng tôi đã giải quyết vấn đề mà tôi đã tìm thấy. Vui lòng mở lại hoặc đưa ra một lỗi mới nếu điều hướng vẫn bị hỏng, mô tả trong chi tiết hơn những gì sai ".

Đối với thời gian, tôi nghĩ rằng nó nên phụ thuộc vào dự án. Nếu bạn rất nhạy bén và đang xử lý lỗi này trong vài ngày kể từ khi nó được nêu ra, thì mọi người nên hiểu rằng bạn sẽ không đợi hàng tuần để có phản hồi trước khi giải quyết vấn đề. Mặt khác, nếu nó đã ở trên slushpile của bạn trong nhiều tháng thì nó có thể mở trong một hoặc hai tháng nữa mà không gây rắc rối cho bạn.

Vì lý do này, tôi không nghĩ có một giới hạn thời gian cụ thể cấu thành "thông lệ tốt" hoặc bạn cần công bố chính sách của mình và tuân thủ chính sách đó. Chắc chắn bạn sẽ không muốn ghi lại rằng phóng viên không thể liên lạc được cho đến khi bạn nỗ lực liên lạc với họ. Nhưng tôi cũng không thấy bất kỳ điểm nào để lại nhiều cảnh báo đếm ngược đến thời hạn: họ sẽ xem xét lại lỗi và muốn nói điều gì đó, hoặc họ sẽ không làm.