Theo dõi lỗi xã giao - Necromancy hoặc trùng lặp?

Tôi đã gặp một vấn đề yêu cầu tính năng thực sự cũ (hơn 2 năm) trong trình theo dõi lỗi cho một dự án nguồn mở được đánh dấu là "đã giải quyết (sẽ không sửa)" do thiếu công cụ cần thiết để thực hiện cải tiến được yêu cầu. Trong thời gian trôi qua kể từ khi quyết định đó được đưa ra, các công cụ mới đã được phát triển sẽ cho phép giải quyết nó và tôi muốn đưa sự chú ý của cộng đồng cho ứng dụng đó.

Tuy nhiên, tôi không chắc chắn về nghi thức được chấp nhận chung là gì để theo dõi lỗi trong các trường hợp như thế này. Rõ ràng, nếu hệ thống tuyên bố rõ ràng là không trùng lặp và sẽ chủ động đánh dấu các mục mới là trùng lặp (theo cách mà các trang web SE làm), thì câu trả lời sẽ là làm theo những gì hệ thống nói. Nhưng còn khi hệ thống không nói rõ điều đó, hoặc người dùng mới không thể dễ dàng tìm thấy địa điểm nói với sở thích của hệ thống thì sao? Là nó thường được coi là tốt hơn để sai ở phía trùng lặp hoặc hoại tử? Điều này có khác nhau hay không tùy thuộc vào việc đó là lỗi hay yêu cầu tính năng?

Điều duy nhất có thể trả lời thỏa đáng đây là quy trình của tổ chức bạn. Nếu tình huống này không được xác định, thì nó phải được xác định sao cho phù hợp mỗi khi nó xảy ra.

Tôi khuyên bạn nên mở lại thông tin cũ và thêm thông tin mới vào đó nếu thích hợp. Từ góc độ đo lường / số liệu, điều này có lẽ sẽ ít gây hại nhất - điều mới không phải là một khiếm khuyết hoặc cải tiến mới, mà là xem xét lại một cái cũ. Cần có một số trạng thái cho các yêu cầu thay đổi đến cho biết nó cần được xem xét bởi bất kỳ ai là bên chịu trách nhiệm. Bằng cách thay đổi trạng thái trở lại điều này, họ có thể nhìn thấy lịch sử (thực tế nó đã được hoãn lại một lần trước đó) nhưng cũng có thể dễ dàng thông tin mới.

Những gì tôi đã làm (và đã làm trong quá khứ) là tạo ra một lỗi mới (để cung cấp cho nó mức độ phù hợp), lưu ý sửa chữa có thể / mới và liên kết với lỗi cũ để tham khảo / theo dõi lịch sử.

nó cũng phụ thuộc vào lỗi ... lỗi đó có thể là một "tính năng" bây giờ hoặc có các công việc được thiết lập tốt mà mọi người đã sử dụng trong 2 năm sẽ bị hỏng do sửa chữa.

Về cơ bản, bạn thực sự phải tìm hiểu và điều tra lỗi và sửa lỗi tiềm năng, và nếu bạn vẫn nghĩ nó nên được sửa, thì hãy đăng nhập lỗi.

Là một lập trình viên, tôi nghĩ rằng việc sao chép thông tin nói chung là một điều xấu và nên tránh bất cứ khi nào có thể. Hãy tưởng tượng một bảng "Các vấn đề" trong cơ sở dữ liệu theo dõi lỗi. Mỗi bản ghi trong bảng này phải thể hiện một vấn đề duy nhất. Khi bạn thêm bản ghi thứ hai cho cùng một lỗi, nó thực sự bắt đầu không phải là một lỗi, mà thực tế là một số người dùng đã phát hiện ra nó và đăng vào một ngày nào đó. Điều thực sự xảy ra là bạn đã đăng một số thông tin bổ sung về vấn đề hiện có. Thông tin này nên được lưu trữ ở những nơi khác nhau, như bảng "IssueComments" hoặc đại loại như thế.

Theo quan điểm của tôi, hoại tử là ít xấu xa. Nếu hoại tử là một vấn đề, chúng ta nên đấu tranh với thứ gì đó gây ra vấn đề, chứ không phải với chính nó (nếu bạn tìm thấy một số thông tin mới về lỗi cũ, điều đó có gì sai? Điều đó hoàn toàn tự nhiên). Ví dụ: nếu ai đó đăng nhận xét về lỗi đã đóng cũ, điều này bằng cách nào đó sẽ thu hút sự chú ý của tất cả người dùng quan tâm.

Có lẽ bạn có thể mở một báo cáo lỗi mới và liên kết nó với báo cáo cũ. Biện minh cho lý do của bạn để muốn sửa chữa nó. Đó có thể là trường hợp sửa chữa sẽ phá vỡ hành vi hiện có (có thể tương thích nhị phân hoặc thay đổi cách họ phải làm việc với ứng dụng) và sửa nó có thể gây ra nhiều vấn đề hơn giá trị của nó. Nếu sửa chữa sẽ có tác động tối thiểu thì có thể không có sự phản đối nào đối với việc khắc phục.

Bạn cần phải xem chính xác lý do tại sao nó đã được quyết định không sửa chữa ngay từ đầu.

Tôi muốn nói điều này khác nhau giữa lỗi và yêu cầu tính năng.

Khi bạn tạo một báo cáo lỗi trong bugtracker, bạn thường mô tả các triệu chứng. Tuy nhiên, điều đó không có nghĩa là nguyên nhân cơ bản đó giống hoặc thậm chí tương tự nhau. Đặc biệt là nếu nội bộ được ẩn tốt khỏi người dùng cuối và tất cả những gì bạn nhận được là lỗi chung khi có sự cố. Trong những trường hợp như vậy, tình trạng hoại tử không phải là hướng đi, vì sự kiện mặc dù các triệu chứng bên ngoài có vẻ giống nhau, nhưng rất có thể đó là lỗi hoàn toàn khác. Nếu bạn mở lại lỗi cũ, nhà phát triển có thể sẽ bắt đầu điều tra nguyên nhân cũ, điều này có thể khiến anh ta hoàn toàn sai hướng và mất thời gian.

Đối với yêu cầu tính năng đã bị từ chối và lý do từ chối không còn hiệu lực, tôi muốn nói rằng cần thiết là cách để đi. Trong trường hợp này, bạn biết rằng việc tạo vé mới, bạn sẽ tạo bản sao chính xác.