ข้อผิดพลาดในการติดตามข้อผิดพลาด - ความลึกลับหรือการทำซ้ำ?

ฉันเจอปัญหาคำขอฟีเจอร์เก่า ๆ (2 ปีขึ้นไป) ในตัวติดตามบั๊กสำหรับโปรเจ็กต์โอเพนซอร์สที่ถูกทำเครื่องหมายว่า "แก้ไขแล้ว (จะไม่แก้ไข)" เนื่องจากไม่มีเครื่องมือที่จำเป็นในการปรับปรุงตามที่ร้องขอ ในช่วงเวลาที่ผ่านไปนับตั้งแต่มีการกำหนดเครื่องมือใหม่ได้รับการพัฒนาเพื่อให้สามารถแก้ไขได้และฉันต้องการที่จะนำความสนใจของชุมชนสำหรับแอปพลิเคชันนั้นมาใช้

อย่างไรก็ตามฉันไม่แน่ใจว่ามารยาทที่ยอมรับโดยทั่วไปคืออะไรสำหรับการติดตามบั๊กในกรณีเช่นนี้ เห็นได้ชัดว่าหากระบบระบุอย่างชัดเจนว่าจะไม่ทำซ้ำและจะทำเครื่องหมายรายการใหม่เป็นรายการซ้ำ (ในลักษณะที่ไซต์ SE ทำ) ดังนั้นคำตอบก็คือทำตามสิ่งที่ระบบพูด แต่สิ่งที่เกี่ยวกับเมื่อระบบไม่ได้พูดอย่างชัดเจนหรือผู้ใช้ใหม่ไม่สามารถหาสถานที่ที่กล่าวว่าด้วยการตั้งค่าของระบบได้อย่างง่ายดาย? โดยทั่วไปแล้วถือว่าดีกว่าถ้าทำผิดด้านการทำซ้ำหรือการใช้เวทมนตร์? สิ่งนี้จะแตกต่างกันไปขึ้นอยู่กับว่าเป็นข้อบกพร่องหรือการร้องขอคุณสมบัติ?

สิ่งเดียวที่สามารถตอบได้อย่างเพียงพอคือกระบวนการขององค์กรของคุณ หากไม่ได้กำหนดสถานการณ์นี้ควรกำหนดไว้เพื่อให้สอดคล้องกันทุกครั้งที่เกิดขึ้น

ฉันขอแนะนำให้เปิดเก่าและเพิ่มข้อมูลใหม่ตามความเหมาะสม จากมุมมองการวัด / ตัวชี้วัดสิ่งนี้อาจเป็นอันตรายน้อยที่สุด - สิ่งใหม่ไม่ใช่ข้อบกพร่องหรือการปรับปรุงใหม่ แต่ควรกลับไปทบทวนสิ่งเก่า ๆ ควรมีบางสถานะสำหรับการร้องขอการเปลี่ยนแปลงที่เข้ามาซึ่งบ่งชี้ว่าจำเป็นต้องได้รับการตรวจสอบโดยบุคคลที่รับผิดชอบ โดยการเปลี่ยนสถานะกลับเป็นสิ่งนี้พวกเขาสามารถดูประวัติ (ความจริงมันถูกเลื่อนออกไปก่อนหน้านี้) แต่ยังเป็นข้อมูลใหม่ได้อย่างง่ายดาย

สิ่งที่ฉันทำ (และทำไปแล้วในอดีต) คือการสร้างบั๊กใหม่ (เพื่อให้มันเกี่ยวข้อง) จดบันทึกการแก้ไขที่เป็นไปได้ / ใหม่และเชื่อมโยงไปที่อันเก่าเพื่ออ้างอิง / ติดตามประวัติ

มันยังขึ้นอยู่กับข้อผิดพลาด ... ข้อผิดพลาดนั้นอาจเป็น "คุณสมบัติ" ในขณะนี้หรือมีวิธีแก้ไขปัญหาที่เป็นที่ยอมรับซึ่งผู้คนใช้งานมานาน 2 ปีซึ่งจะถูกทำลายโดยการแก้ไข

โดยพื้นฐานแล้วคุณต้องขุดผ่านและตรวจสอบข้อผิดพลาดและการแก้ไขที่อาจเกิดขึ้นได้และหากคุณยังคิดว่าควรได้รับการแก้ไขให้บันทึกข้อผิดพลาด

ในฐานะโปรแกรมเมอร์ฉันคิดว่าการทำสำเนาข้อมูลโดยทั่วไปเป็นสิ่งที่ไม่ดีและควรหลีกเลี่ยงเมื่อเป็นไปได้ ลองนึกภาพตาราง "ปัญหา" ในฐานข้อมูลบั๊กติดตาม แต่ละระเบียนในตารางนี้ควรแสดงถึงปัญหาที่ไม่ซ้ำกัน เมื่อคุณเพิ่มระเบียนที่สองสำหรับข้อผิดพลาดเดียวกันจริง ๆ แล้วมันเริ่มแสดงถึงข้อบกพร่องไม่ใช่ตัวเอง แต่ความจริงที่ว่าผู้ใช้บางคนค้นพบมันและโพสต์ในบางวันและเวลา สิ่งที่เกิดขึ้นจริงคือคุณโพสต์ข้อมูลเพิ่มเติมเกี่ยวกับปัญหาที่มีอยู่ ข้อมูลนี้ควรเก็บไว้ในที่อื่นเช่นตาราง "IssueComments" หรืออะไรทำนองนั้น

จากมุมมองของฉันการใช้เวทมนตร์เป็นสิ่งชั่วร้ายน้อยลง หากมีปัญหาเกี่ยวกับเวทมนตร์เราควรต่อสู้กับสิ่งที่ก่อให้เกิดปัญหาไม่ใช่ด้วยเวทมนตร์ (ถ้าคุณพบข้อมูลใหม่เกี่ยวกับข้อผิดพลาดเก่า ๆ มันผิดปกติหรือเปล่า? ตัวอย่างเช่นหากมีคนโพสต์แสดงความคิดเห็นเกี่ยวกับบั๊กที่ปิดเก่าสิ่งนี้ควรดึงดูดความสนใจของผู้ใช้ทุกคน

บางทีคุณสามารถเปิดรายงานข้อผิดพลาดใหม่และเชื่อมโยงไปยังรายงานเก่าได้ แสดงเหตุผลของคุณที่ต้องการแก้ไข อาจเป็นกรณีที่การแก้ไขจะทำลายพฤติกรรมที่มีอยู่ (ทั้งความเข้ากันได้แบบไบนารีหรือเปลี่ยนวิธีที่พวกเขาต้องทำงานกับแอปพลิเคชัน) และการแก้ไขอาจทำให้เกิดปัญหามากกว่าที่คุ้มค่า หากการแก้ไขจะมีผลกระทบน้อยที่สุดอาจไม่มีการคัดค้านการแก้ไข

คุณต้องดูให้แน่ชัดว่าเหตุใดจึงตัดสินใจไม่แก้ไขในตอนแรก

ฉันจะบอกว่าสิ่งนี้แตกต่างระหว่างข้อผิดพลาดและคำขอคุณสมบัติ

เมื่อคุณสร้างรายงานข้อผิดพลาดใน bugtracker คุณมักจะอธิบายอาการ มันไม่ได้หมายความว่าสาเหตุพื้นฐานนั้นเหมือนกันหรือคล้ายคลึงกัน โดยเฉพาะอย่างยิ่งถ้าผู้ใช้ภายในซ่อนตัวจากผู้ใช้และสิ่งที่คุณได้รับคือข้อผิดพลาดทั่วไปเมื่อมีสิ่งผิดพลาดเกิดขึ้น ในกรณีเช่นนี้การใช้เวทมนตร์ซึ่งไม่ใช่วิธีที่จะไปเพราะเหตุการณ์แม้ว่าอาการภายนอกอาจดูเหมือนคล้ายกัน หากคุณเปิดข้อผิดพลาดเก่าอีกครั้งนักพัฒนาอาจเริ่มตรวจสอบสาเหตุเดิมซึ่งอาจนำเขาไปในทิศทางที่ไม่ถูกต้องสมบูรณ์และเสียเวลา

สำหรับคำขอคุณลักษณะที่ถูกปฏิเสธและเหตุผลการปฏิเสธไม่ถูกต้องอีกต่อไปฉันจะบอกว่าการใช้เวทมนตร์เป็นวิธีที่จะดำเนินการ ในกรณีนี้คุณรู้ว่าการสร้างตั๋วใหม่คุณจะสร้างซ้ำแน่นอน