GitHub에서 버려진 문제로 무엇을해야합니까?

누군가 GitHub에서 문제를 열었지만 오류를 재현하기위한 추가 정보가 요청되고 제공되지 않으면 정상적인 절차는 무엇입니까? 예 .

여기서 저자는 "탐색이 끊어진다"고 말합니다. 나는 그것이 고정되어 있다고 생각하지만, 저자의 말이 우리가 똑같은 것에 대해 이야기하고 있는지 확인하고 싶습니다. 그러나 때로는 문제의 기자가 사라집니다. 포기한 문제에 대해 만료 날짜 를 설정 하는 것이 좋거나 일반적인 관행 입니까?

이러한 조건과 같은 것 :

• 디버깅 할 수있는 문제에 대한 질문이 제기되었습니다.
• 개발자 팀의 마지막 답변 / 의견 이후 2-6 개월이 지났습니다.
• 버그를 닫을 때 버그를 재현 할 수 없습니다 (어떤 이유로 든 절대 재현 할 수 없었을 수 있음).
• 2 주 전에 경고가 발행됩니다.

프로젝트는 일반적으로 무엇을합니까? Google에서 찾을 수 없습니다. 또한 이것을 어떻게 문서화합니까? 위의 요점을 자세히 설명하는 README.md의 간단한 메모와 왜 닫히는 이유를 설명하는 문제의 설명이 있습니까?

참고 : 버그는 여전히 관련성이 있거나 그렇지 않을 수 있기 때문에이 질문 과 다릅니다 . 그러나 정보가 부족합니다.

이 딜레마이다 : 당신이 실제로 모르기 때문에 당신이 "고정"으로 문제를 닫을 수 없습니다 경우 는 고정, 또는 적어도 경우에도 일부 문제가 수정되었습니다, 당신은 실제로이 기자 문제인지 모르겠어요 에 대해 이야기했다. 다른 한편으로, 당신은, 당신이 결코 확인을 얻을 수 없기 때문에 그것을 닫을 수없는 경우, 수정되었을 수있는 문제를 떠나고 싶지 않습니다.

그래서, 당신은 해야 닫습니다, 그러나 아마 "고정"하지. 긍정적이거나 "보고자"인 경우 맞춤 마감 이유를 "수정 된"또는 "확인되지 않은 수정"으로 만들 수 있습니다. 또한 "복제 할 수 없음"이라고 말하고보다 반응이 빠른 기자를 위해 같은 버그가 나타날 때까지 기다릴 수 있습니다.

그러나 버그가 실제로 수정되었는지 여부를 알 수없는 버그에 대해서는 리소스를 소비해서는 안됩니다.

귀하의 주요 질문에 대해서는 이미 답변을 받았지만 귀하는 프로세스를 문서화하는 것에 대해서도 질문했으며 이에 대한 답변도 필요합니다.

많은 프로젝트에서 본 솔루션은 프로젝트의 README.md에 저장하는 것이 아니라 기고자 용 README 파일 인 README 파일에 특별한 기여를 하는 것입니다. 이 파일은 코드 (이름 지정 규칙, 모듈 구성 등) 또는 프로세스 (커밋 작성 방법, 티켓 처리 방법 등)에 대해 프로젝트에 참여하는 사람들이 알고 싶어하는 모든 것을 설명합니다. 이 파일은 .MD프로젝트의 다른 파일이거나 완전히 다른 저장소에 배치되어 모든 프로젝트에서 공유 될 수 있습니다. 메인에서 연결하는 것을 잊지 마십시오 README.md!

기본 README에서 정보를 분리하는 것은 대개 프로젝트 사용자의 일부만 직접 정보에 기여한다는 것입니다. 대부분의 사용자는 그 정보에 대해 지루할 필요가 없습니다. 프로젝트가하는 일과 사용 방법을 알아야하기 때문에 주 README에 포함되어야합니다. 프로젝트의 경우 기여 섹션이 매우 작아서 주요 README를 방해하지는 않지만 모든 워크 플로우를 문서화하면 기여자가 따르기를 원할 때 더 이상 잘 맞지 않습니다 ...

모든 사용자가 버그를 열 수 있으므로 버그 열기에 대한 특별한 요구 사항이있는 경우 기본 README에 버그를 넣어야합니다 (코드 제공자와는 달리 버그 리포터는 더 긴 시간에 갈 의향이 적습니다) 규칙을 연구하고 준수하십시오). 그러나 실제로 버그를 수정하고 티켓을 닫는 사람 (귀하가 확인한 컨트 리뷰 터 중 하나인지 여부)은 직접 기고자이며 README 컨트 리뷰 션을 읽을 수 있습니다. 응답하지 않음을 여기에 설명해야합니다.

나는 다른 것보다 확인되지 않은 버그를 처리하는 방법 (github의 이슈 트래커 사용)에 관한 더 많은 질문으로 이것을 읽었습니다.

나에게, 그것은 내가 사용한 다른 이슈 트래커에 기반한 다소 직접적인 대답입니다. Github은 누구에게도 워크 플로를 사용하도록 강요하지 않으므로 기본 구성에서 매우 유연하고 쓸모가 없습니다.

Bugzilla의 기본 워크 플로우를 살펴보면 다음과 같은 이점이 있습니다.

나는 매우 중요한 점을 지적 할 것이다 . 검증 된 후에 닫히기 전에 고정 된 것으로 해결 된다 . 기본 Github 워크 플로에는 빨간색 (열림) 및 녹색 (닫힘) 상태 만 표시됩니다.

따라서 Github 내의 레이블 ( 응용 프로그램의 레이블 )을 사용하여 추가 정보를 표시하는 방법이 있습니다. '확인되지 않음'및 '확인 됨'레이블 쌍을 만들어 문제를 닫으면 적용 할 수 있습니다. 이 방법은 단 하나의 접근 방식입니다. 검색하면 레이블 사용에 대한 수십 가지의 다른 접근 방법을 찾을 수 있습니다. 여기, (우선 순위 등)에 대한 github 문제를 관리하는 방법은 무엇입니까? 이 문제를 해결합니다.

개발자의 입장에서 수정했습니다. Github에서 문제를 닫습니다. '확인되지 않은'라벨을 적용하십시오. 이전 버전의 버그에 익숙한 사람이 "예, 수정했습니다"라고 표시되면 레이블을 '확인 됨'으로 변경할 수 있습니다. 그들이 말하지 않았다면 다시여십시오.

또한 '고정'외에도 다른 해결 된 상태 가 있습니다 . 'wontfix'(수정은 현재 구조로는 수행 할 수없는 것임)와 'worksforme'(버그를 재현 할 수 없음) 및 'invalid'(OS에 관한 버그를 제기하지 않음)가 있습니다. 응용 프로그램 유형의 것들).

나는 원래의 기자와 같은 것에 대해 이야기하고 있다는 확신에 따라 두 가지 견해 중 하나를 취할 것입니다.

1) 리포터를 더 이상 사용할 수 없으므로 문제의 버그가 수정 한 것을 의미한다고 생각합니다. 도움이되는 경우 테스트 사례를 첨부하여 발견 된 오류를 명확하게하십시오. 버그 보고서에 수정 한 내용을 자세히 설명하고 "이것이 '탐색'이 의미하는 것으로 생각합니다. 이것이 의미가 아닌 경우 새 버그를 다시 열거 나 제기하십시오"와 같은 메모를 남깁니다. 버그를 수정 된 것으로 표시하십시오.

2) 리포터를 더 이상 사용할 수 없기 때문에 버그를보고 할 수없는 것으로 간주되므로 버그를 재현 할 수 없다고 간주합니다. 신용 조사를 위해 결석 기자가 설명 한 조건에서 관찰되었다는 언급을 위해 새로운 버그를 제기하십시오. 두 가지가 중복 될 수 있음에 유의 하고 새로운 버그를 수정 표시 하고이 버그를 무효로 표시하십시오. '내비게이션 중단'의 의미를 해결할 수는 없지만 찾은 문제를 해결했습니다. 내비게이션이 여전히 중단되면 새 버그를 다시 열거 나 제기하십시오. 무엇이 잘못되었는지 더 자세하게 "

타임 스케일에 관해서는 프로젝트에 달려 있다고 생각합니다. 매우 반응이 좋고 며칠 안에이 버그를 처리하고 있다면 사람들은 문제를 해결하기 전에 몇 주 동안 응답을 기다리지 않을 것임을 이해해야합니다. 반면, 슬러시 파일에 몇 달 동안 있었다면 아무런 문제없이 한 달 또는 두 달 동안 열 수 있습니다.

이러한 이유로 "좋은 관행"을 구성하거나 정책을 게시하고 준수해야하는 특정 시간 제한이 없다고 생각합니다. 확실히 당신은 당신이 그들에게 연락하려고 노력할 때까지 연락 할 수 없다는 것을 기록하고 싶지 않을 것입니다. 그러나 여러 경고를 마감 기한까지 남겨 두는 요점도 없습니다. 버그를 다시 방문하고 무언가를 말하고 싶거나하지 않을 것입니다.