[컴][툴] github issue 를 활용하는 방법

github issue / github 사용법 / github 로 개발하는 방법 / github 로 collaborator 로 이슈 해결 / 협업 툴 / 그룹 웨어 / vscode 에서 github 를 사용하는 방법 /triaging / triage / 깃헙 / 깃허브 사용법 / 깃허브 이슈 사용법 / github 이슈 / 활용법


github issue 를 활용하는 방법

vscode team 의 github 활용방법

vscode Wiki를 읽으면 vscode team 이 어떻게 github 를 사용하는지 알 수 있다.

  • https://github.com/microsoft/vscode/wiki/Issues-Triaging
    • close 할 때 이유를 label 로 달아준다.(예를 드려면 duplicate)등
    • 모든 issue는 type label 을 갖는다. issue 를 분류할때 type label 을 사용한다. type label 에 특정 색으로 통일. (vscode team 은 grey 를 사용, bug 같이 특정 의미가 들어가면 grey+red 등으로 만듦)
    • feature area 라는 것을 둬서, 기능에 따른 분류를 하고, 그에 따라 label 을 배정했다. 그리고 이것도 마찬가지로 색을 통일했다.
    • iteration 이나 release 를 표현하기 위해 milestone 을 사용한다.
      • iteration 은 대체로 1개월 주기이다.(참고)
      • 주로 Backlog milestone 에 있는 issue 들이 바로 iteration milestone 으로 가게 된다. (iteration milestone 은 November 2019 처럼 날짜를 사용)
      • Backlog 에 있는 것중 Roadmap 에 부합하는 녀석들이 iteration 으로 넘어간다.
      • 만약 Backlog 에 있는 것이 Roadmap 과 전혀 관련없는 것이 명확하다면 close 한다.
      • Backlog Candidate 는 community 가 원하는 기능중에 vscode team 이 작업하지 않으려 한것들에 대한 투표를 진행한다. upvote 가 20개 이상이면 이것은 Backlog 로 옮겨진다.
    • important issue 에 대한 정의를 적어놓고, 부합되면 important label 을 붙인다.
    • 도움을 요청하는 label 도 있다.
      • investigation-wanted 는 재현을 할 수 없거나, 세팅등이 너무 오래걸려서 재현할 시간이 없거나 하면 이 label 을 사용한다.
      • help-wanted 는 community 에 도움을 요청하기 위한 용도
    • bug 를 wont-fix label 을 붙이고 close 하는 경우
      • 비용대비 효용이 없을때 wont-fix 를 사용한다.
    • upstream issue
      • 이슈가 package 나 library 에 연관돼서 생기고, 이것만 고쳐서는 안되는 이슈인 경우 `upstream` 을 붙인다. 그래서 package 나 library 가 이슈를 인지해서 이것을 issue 로 처리하면 close 한다. 또는 이것이 고쳐질 가능성이 없어도 close 한다.
  • https://github.com/microsoft/vscode/labels
  • https://github.com/microsoft/vscode/milestones
    • `On Deck` milestone: 다가올 milestone 에 고려해야 할 이슈들을 모아놓는다. vscode 에서는 On Deck 의 issue 개수를 항상 100개 이하로 관리하려 한다.
    • `Backlog` milstone : 아직 수정을 고려하고 있지 않은 issue 들을 모아놓는다.
    • 각 iteration 마다 milestone 을 만들어서 사용한다.
  • https://github.com/microsoft/vscode/projects
  • https://github.com/microsoft/vscode/wiki/Roadmap
    • Roadmap wiki 를 계속해서 update 해 나간다. 그래서 그 해에 골들을 세운다.
    • 최소 1달에 1번 roadmap 을 review 하고 update 한다.
  • https://github.com/microsoft/vscode/wiki/Development-Process
    • 매 iteration 전에, 이번 iteration 에서 어떤 기능에 우선순위를 둘 것인지를 정하고, 어떤 버그를 고칠 것인지 정한다.
    • 고치려고 하는 bug 에는 milestone 을 붙인다.
    • 새로운 기능에는 issue 를 새로 만든다.
      • 그리고 plan-item 이라는 label 을 붙인다.
      • plan-item 에는 자세한 checklist 를 넣게 된다.(예시)
    • 이렇게 bug, plan-item, feature-request 에 milestone 을 할당한다.
    • iteration
      • 첫주차 : 이전 iteration의 결과를 지켜보고, critical issue 들을 해결한다.
      • 2주차: 개발
      • 3주차: 개발
      • 4주차: 마무리
        • 기능테스트등을 하고, 문서를 update 한다.
        • insider channel 에서 가능한 pre-release 를 만든다. 그리고 user 에게 test 를 요청한다.
        • pre-release 에 아무런 변경이 없고 24시간이 지나면, release 를 게시한다. 때로는 주중에 게시하기도 한다.
    • iteration milestone 이 할당된 후에 우선순위와 관련된 label 을 추가한다.
      • importatant 가 가장 먼저 해결된다.
    • iteration plan : iteration 마다 iteration plan 이라는 이슈를 하나 만들고, 그 안에서 issue 들을 모아서 checklist 로 관리한다. 각각의 item 들은 하나의 issue 이다. 이것은 관리자가 처리해야 하는 issue 같은 느낌이다.
  • Issue Tracking · microsoft/vscode Wiki · GitHub
    • 여러 repository 에 대한 label 을 일괄적으로 관리하기 위해Github Label Manager를 사용한다.

See Also

  1. gatsby: https://www.gatsbyjs.org/contributing/triaging-github-issues/
  2. gitlab: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html
  3. 쿠…sal: [컴][툴] github 와 slack 의 연동
  4. github 용 extension: GitHub - stefanbuck/awesome-browser-extensions-for-github: A collection of awesome browser extensions for GitHub.
  5. https://github.com/super-greate-org/issues/issues/5

댓글 없음:

댓글 쓰기