[번역] 이슈 대응하기-Visual studio Code Team의 Case

원문은 https://github.com/microsoft/vscode/wiki/Issue-Grooming (vscode Github) 포스트입니다.

vscode팀이 개발자나 사용자들이 요청하는 이슈에 대해 어떻게 대응하고 또 관리하는지에 대한 포스팅입니다. 개발 이슈 관리 측면에서 참고할 만한 내용이 있을 것 같아서 번역해 봤습니다. 

발 번역 및 의역이 포함되어 있으며 번역이 애매한 경우 원어를 그대로 사용하였습니다. 개발 용어는 개발자 분들은 대부분 이해하시리라고 생각합니다. 번역이 잘못되었거나 수정이 필요한 부분은 의견 주시면 수정하겠습니다.

---

우리 Github커뮤니티는 우리가 성공할 수 있었던 큰 요인중 하나입니다. 매일매일 여러분들은 새로운 기능에 대한 아이디어를 바탕으로 50~250여 개의 이슈들을 생성합니다. 여러분들은 우리에게 어떤 것들이 예상대로 진행되고, 어떤 것들은 그렇지 않으며 또 이미 적용된 것들이 어떻게 개선되었는지 문의합니다. 우리는 여러분들이 생성하는 각각의 이슈들에 대해 매우 기쁘고 감사하게 생각합니다.

우리가 모든 이슈들에 대해 최선의 노력을 다 하고 있음에도 불구하고, 시간이 지나면 이슈를 따라잡기 힘들어집니다. 여러분들이 이슈를 확인할 때, 때때로 여러분들이 제안한 기능의 제공 여부, 버그 수정 여부, 다른 이슈와의 중복 여부들이 불명확한 경우가 있습니다.

때문에 명확성을 합리적인 수준으로 회복시키기 위해 우리는 매년 모든 진행 중인 이슈에 대해 House Keeping Iteration을 진행합니다. 우리는 분류하고, 라벨링 하고, 수정하며, 이슈를 종료합니다. 때문에 처리하기 어려운 알림들이 물밀듯 몰려오지만 결국 여러분들의 아이디어가 어떻게 될지 더 잘 이해할 수 있게 되었습니다.

House Keeping Iteration에서 수행하는 일들에 대해서는 아래 좀 더 자세하게 나와있습니다.

---

이슈 종료

우리는 아래와 같은 이유로 이슈를 종료합니다.

Reason	Label
더 이상 사용되지 않거나 이미 수정하였슴
7일동안 추가 정보를 얻지 못했음	needs more info
다른 이슈와 중복됨	*duplicate
요청한 기능은 확장프로그램 기능으로 구현하는것이 좋음	*extension-candidate
설계된 동작임	*as-designed
확장프로그램으로 인한 문제	*caused-by-extension
개발자의 문의사항	*dev-question
사용자의 문의사항	*question
주제에 맞지 않고, 진행할 수 있는 정보가 없거나 의도하지 않은 문제임	invalid
재현할 수 있는 추가 정보가 필요함	*not-reproducible
범위를 벗어나는 기능요청임	*out-of-scope

우리는  /duplicate of #1234와 같이 특정한 코멘트를 추가하거나 사전에 정의된 코멘트와 함께 라벨을 부여하여 이슈를 종료한 봇의 도움으로 이슈를 완료합니다.

범위를 벗어나는 기능 요청

모든 기능 요청과 같은 이슈들은 커뮤니티 회원 간에는 물론 저희와 커뮤니티 간의 소통 수단입니다. 따라서 원칙적으로 우리는 모든 기능 요청 사항에 대해 여러분들이 설명하는 기능에 의해 어떤 일이 발생하더라도 이슈를 열어놓고 있습니다. 하지만 모든 이슈를 열어놓게 되면 어떤 것들이 실제 Repositofy에 반영되는 것인지 알 수 없습니다. 그래서 우리는 실제로 처리하지 않을 이슈는 종료합니다.

만일 당신이 기능을 요청 한 당사자라면, 우리가 이슈를 종료하는 것을 좋아하지 않을 것입니다. 아마 따귀를 맞은 것 같겠죠. 이해합니다. 우리 모두 다 이 프로젝트 또는 다른 프로젝트에 기여하면서 그런 경험을 해 본 적이 있습니다. 그렇기 때문에-확실하게 말하지만-우리는 여러분들의 모든 의견을 사랑합니다. 우리가 당신의 이슈를 종료하기로 결정했을 때 너무 화내지 말아 주세요☮. 당신이 요청한 기능이 계속 진행되어야 한다고 생각한다면 기능이 필요한 사례나 더 많은 추천을 모아주세요. 그리고 우리에게 알려주면 우리는 이슈를 다시 진행할지 고려해 보겠습니다.

우리가 종료하기로 결정하는 기능 요청사항들을 결정하는 기준은 다음과 같습니다. 

1. 기능 요청에서 설명한 것들이 향후 24개월 간 개선될 합리적인 기회가 있는가? 24개월은 6~12개월로 정해놓은 우리의 로드맵보다 긴 기간입니다. 때문에 우리에겐 좀 더 중요한 것들이 있고, 24개월 동안 해야 할 것 들보다 당장 처리해야 하는 이슈들이 있습니다.

2. 이 기능들에 대해 커뮤니티가 큰 관심을 보이는지? 즉 10 개 이상의 투표나 10개 이상의 코멘트가 달렸는지? 2019년 10월 9일 현재 2850개의 진행 중인 이슈 중 이 기준만으로도 650개의 이슈가 진행되고 있습니다.

3. 기능 요청이 대담하고 미래지향적이어서 24개월이 지난 후에도 다루어질 수 있는 것인지?

만일 위의 3가지 질문 중 하나라도 부합한다면 우리는 이슈를 우리가 감당할 수 있을지를 생각합니다.

4. 우리 팀이 이 기능을 구현할 여유가 있을지? 이슈를 처리하는데 필요한 소요 비용이 우리 팀의 규모에서 적절할지?

요약하자면, 1~3중의 1가지 항목에 부합하고, 4번 항목을 통과해야 합니다. 그렇지 않으면 범위를 벗어나는 것으로 하고 종료합니다. 우리는 매일매일 받는 이슈 알림을 덜 받기 위해 해당 이슈를 unsubscribe 합니다.

수정하지 않는 버그

버그를 처리하는데 부정적인 효과가 더 크다면 won't fix로 이슈를 종료합니다. 이 이슈에 영향을 받는 사용자가 신경 쓰지 않는 것들이나, 예를 들어 수정이 너무 복잡하여 테스트를 함에도 불구하고 많은 사용자들에게 적용되는 위험요소가 있다면 수정하는 것이 꼭 좋은 선택은 아닙니다. 버그를 수정하지 않고 won't fix로 종료할 때, 우리는 왜 그렇게 하는지에 대해 사례를 만들어 놓게 됩니다.

Upstream이슈

어떤 이슈에 대해서는 upstream이라고 라벨을 부여합니다. upstream은 이 이슈가 패키지나 라이브러리에 관련된 것이어서 우리가 독자적으로 수정할 수 없는 경우입니다. 우리의 문제와 패키지나 라이브러리와의 연관점을 분명하게 추적한 경우 문제를 해결하고 종료합니다만, 어떤 경우에는 그것이 불가능합니다. 예를 들어 Chromium문제로 확인하였으나 너무 복잡한 문제이기 때문에 Chromium 측에서 아직 문제를 받아들이지 않는 경우도 있습니다.

---

이슈 분류

각각의 이슈에는 type라벨이 있습니다. 대부분의 type라벨은 회색이지만 어떤 것들은 노란색입니다. 버그는 붉은색을 띤 회색입니다.

Type	Description
bug	기능구현이 제대로 되지 않았음
feature-request	새로운 기능요구사항
under-discussion	버그인지 기능인지 결정되지 않음
debt	구현 방법이나 설계의 개선
needs more info	정보가 부족하여 type label을 정의하지 못함
question	SO에게 직접 질문해야 함
upstream	Upstream컴포넌트 문제를 추적하는데 필요한 이슈
electron	Electron 관련 이슈
engineering	우리의 시스템이나 프로세스에 관련된 이슈

---

이슈 라벨링

• important라는 라벨을 부여하는 경우가 있습니다.
  • 데이터 유실을 초래
  • 확장 프로그램의 손상
  • 치명적인 보안/성능 이슈
  • 기능을 사용할 수 없게 만드는 UI이슈
• 커뮤니티가 도와줄 수 있는 문제에 대해서는 help-wanted로 라벨을 부여합니다.
• 만일 초보자에게 적합한 애용일 경우 good-first-issue라는 라벨을 부여하고 초보자가 프로그램을 시작하는데 도움이 되는 code pointer를 추가하기도 합니다.

---

이슈 해결

현재 Iteration의 개선 기간 내에 수정하기로 계획된 이슈들은 마일스톤에 버그로 할당합니다.