버그 추적 에티켓-Necromancy 또는 Duplicate?

요청 된 개선 작업을 수행하는 데 필요한 도구가 부족하여 "해결됨 (고정되지 않음)"으로 표시된 오픈 소스 프로젝트에 대한 버그 추적기에서 정말 오래된 (2 년 이상) 기능 요청 문제를 발견했습니다. 결정이 내려진 후 시간이 지남에 따라 새로운 도구가 개발되어이를 해결할 수있게되었으며, 해당 응용 프로그램에 대해 커뮤니티의 관심을 끌고 싶습니다.

그러나 이와 같은 경우 버그 추적에 일반적으로 허용되는 에티켓이 무엇인지 확실하지 않습니다. 분명히 시스템이 명시 적으로 복제하지 말라고 명시하고 새 항목을 복제본으로 적극적으로 표시하면 (SE 사이트와 같은 방식으로) 시스템이 말하는 내용을 따르는 것이 답입니다. 그러나 시스템이 명시 적으로 말하지 않거나 새로운 사용자가 시스템의 선호도를 나타내는 장소를 쉽게 찾을 수없는 경우는 어떻습니까? 복제 또는 괴사 측면에서 잘못하는 것이 일반적으로 더 나은 것으로 간주됩니까? 버그인지 또는 기능 요청인지에 따라 달라 집니까?

이에 적절하게 대응할 수있는 유일한 것은 조직의 프로세스입니다. 이 상황이 정의되지 않은 경우 발생할 때마다 일관성을 갖도록 정의해야합니다.

이전 정보를 다시 열고 적절하게 새 정보를 추가하는 것이 좋습니다. 측정 / 메트릭 관점에서 볼 때 이것은 아마도 가장 해롭지 않을 것입니다. 새로운 것은 새로운 결함이나 개선이 아니라 오래된 것을 다시 방문하는 것입니다. 수신 변경 요청에 대한 책임이있는 사람이 검토해야 함을 나타내는 상태가 있어야합니다. 상태를 다시 이것으로 변경함으로써, 그들은 역사 (이전에 한번 연기되었던 사실)뿐만 아니라 새로운 정보를 쉽게 볼 수 있습니다.

내가하고 (그리고 과거에했던) 일은 새로운 버그를 만들고 (관련성을 부여하기 위해) 가능한 / 새로운 수정 사항을 기록하고, 과거의 참조 / 추적을 위해 이전 버그에 연결하는 것입니다.

또한 버그에 따라 다릅니다. 버그는 "기능"일 수도 있고, 2 년 동안 사람들이 사용해온 해결 방법이있을 수도 있습니다.

기본적으로 버그와 잠재적 인 수정을 파고 조사해야하며 여전히 수정해야한다고 생각되면 버그를 기록하십시오.

프로그래머로서 나는 정보 복제가 일반적으로 나쁜 것이며 가능할 때마다 피해야한다고 생각합니다. 버그 추적기 데이터베이스에서 "문제"테이블을 상상해보십시오. 이 표의 각 레코드는 고유 한 문제를 나타내야합니다. 동일한 버그에 대한 두 번째 레코드를 추가하면 실제로 버그 자체가 아니라 일부 사용자가 버그를 발견하여 날짜와 시간에 게시 한 사실을 나타 내기 시작합니다. 실제로 발생한 문제는 기존 문제에 대한 추가 정보를 게시 한 것입니다. 이 정보는 "IssueComments"테이블 또는 이와 유사한 다른 장소에 저장해야합니다.

내 관점에서, 괴사는 덜 악하다. 네크로 맨시가 문제라면, 우리는 네크로 맨시 자체가 아니라 문제를 일으키는 무언가와 싸워야합니다. 예를 들어 누군가가 오래된 비공개 버그에 대한 의견을 게시하면 관심있는 모든 사용자의 관심을 끌게됩니다.

아마도 새로운 버그 리포트를 열어서 기존 버그 리포트에 연결할 수있을 것입니다. 그것을 고치려는 이유를 정당화하십시오. 이 수정으로 인해 기존 동작 (이진 호환성 또는 응용 프로그램 작업 방식 변경)이 중단 될 수 있으며 수정하면 가치보다 더 많은 문제가 발생할 수 있습니다. 수정 사항이 최소한의 영향을 미치면 수정에 대한 이의가 없을 수 있습니다.

처음에 수정하지 않기로 결정한 이유를 정확하게 알아야합니다.

버그와 기능 요청이 다르다고 말하고 싶습니다.

bugtracker에서 버그 보고서를 작성할 때 일반적으로 증상을 설명합니다. 그러나 근본적인 원인이 동일하거나 유사하다는 것을 의미하지는 않습니다. 특히 내부가 최종 사용자로부터 잘 숨겨져 있고 무언가 잘못되었을 때 발생하는 일반적인 오류입니다. 이러한 경우에는 외부 증상이 비슷해 보이지만 완전히 다른 버그 일 가능성이 있기 때문에 괴사는 아직 갈 길이 멀다. 오래된 버그를 다시 열면 개발자가 오래된 원인을 조사하기 시작하여 잘못된 방향으로 가고 시간이 느슨해 질 수 있습니다.

거부 된 기능 요청과 거부 사유가 더 이상 유효하지 않다면, 괴로움은 갈 길입니다. 이 경우 새 티켓을 만들 때 정확히 복제본을 만들게됩니다.