InfoGrab DocsInfoGrab Docs

워크플로

요약

Technical Writing 팀은 다음 작업에서 기여자, 개발자, 제품 관리자와 협업하기 위해 워크플로를 사용합니다: GitLab 제품 문서를 생성하고 유지 관리하는 프로세스는 문서의 종류에 따라 다릅니다: 새로운 기능 또는 기능 개선: 특정 마일스톤에 맞춰 제공되며 특정 코드 변경과 연관됩니다.

Technical Writing 팀은 다음 작업에서 기여자, 개발자, 제품 관리자와 협업하기 위해 워크플로를 사용합니다:

  • 제품 문서 변경

  • UI 텍스트

  • 릴리즈 포스트

제품 변경을 위한 문서#

GitLab 제품 문서를 생성하고 유지 관리하는 프로세스는 문서의 종류에 따라 다릅니다:

  • 새로운 기능 또는 기능 개선: 특정 마일스톤에 맞춰 제공되며 특정 코드 변경과 연관됩니다. 이 문서는 최우선 순위를 가집니다.

  • 특정 마일스톤 외부의 변경: 일반적으로 특정 코드 변경과 관련이 없으며, 우선순위가 낮고 모든 GitLab 기여자에게 열려 있습니다.

다음 경우에 마일스톤에 대한 문서가 필요합니다:

  • 사용자 또는 관리자 경험에 영향을 미치는 새로운 기능 또는 향상된 기능이 릴리즈될 때.

  • 사용자 인터페이스 또는 API에 변경이 있을 때.

  • 프로세스, 워크플로 또는 이전에 문서화된 기능이 변경될 때.

  • 기능이 사용 중단(deprecated)되거나 제거될 때.

백엔드 기능이 추가되거나 변경될 때는 일반적으로 문서가 필요하지 않습니다.

개발자 책임#

개발자는 기능 또는 기능 개선에 대한 문서의 주요 작성자입니다. 개발자는 다음에 대한 책임이 있습니다:

  • 기능에 필요한 초기 콘텐츠 개발.

  • 어떤 문서를 언제 제공해야 하는지 이해하기 위해 제품 관리자와 협력.

  • 해당 그룹의 다른 개발자에게 기술 검토 요청.

  • 새로운 기능 또는 기능 개선을 제공하는 DevOps Stage 그룹에 배정된 Technical Writer에게 문서 검토 요청.

가능하면 코드가 포함된 머지 리퀘스트에 문서도 함께 포함해야 합니다. 자세한 내용은 가이드라인을 참조하세요.

이 MR의 작성자(프론트엔드 또는 백엔드 개발자)가 문서를 작성해야 합니다.

커뮤니티 기여자는 GitLab 팀 멤버에게 추가적인 도움을 요청할 수 있습니다.

작성#

문서는 제품의 필수적인 부분이므로, ~"type::feature" 이슈에 ~documentation 라벨도 포함되어 있다면 기능의 코드와 함께 새로운 또는 업데이트된 문서를 제공해야 합니다.

Technical Writer는 이슈별로 요청 및 계획에 따라 기꺼이 도움을 드립니다.

문서가 필요한 기능 이슈의 경우, 제품 관리자 및 Technical Writer와 달리 합의하지 않는 한 아래 프로세스를 따르세요:

다음 중 하나에 새로운 및 편집된 문서를 포함하세요:

코드를 도입하는 머지 리퀘스트.

  • 거의 동시에 제출된 별도의 머지 리퀘스트.

이슈에서 제품 관리자가 개발한 문서 요구사항을 사용하고 필요에 따라 추가 문서 계획이나 아이디어를 논의하세요.

새로운 또는 변경된 문서가 광범위한 협업이나 대화가 필요한 경우, 계획 프로세스를 위해 별도의 연결된 이슈를 사용할 수 있습니다.

문서 가이드라인과 여기에 연결된 다른 리소스를 사용하세요:

문서 폴더 구조.

다음의 경우 이슈 또는 머지 리퀘스트, 또는 #docs Slack 채널에서 관련 DevOps Stage의 Technical Writer에게 연락하세요:

문서를 위한 올바른 위치 선택에 도움이 필요할 때.

  • 문서 아이디어나 개요를 논의하고 싶을 때.

  • 다른 도움을 요청하고 싶을 때.

별도의 머지 리퀘스트에서 문서를 작업하는 경우, 코드 머지에 최대한 가깝게 문서가 머지되도록 하세요.

기능에 feature flag가 있는 경우, feature flag가 있는 이슈 문서화 정책을 따르세요.

AI 생성 문서#

모든 AI 생성 문서는 Technical Writer의 검토를 받아야 합니다. 검토를 위해 문서를 제출하기 전에 문서 파일에 대해 Vale 테스트를 실행하여 스타일 문제를 식별하고 수정하세요.

생성형 AI 도구는 주제 전문 지식을 대체할 수 없습니다. 작성자는 자신이 생성하는 모든 콘텐츠의 기술적 정확성을 보장할 책임이 있습니다. 출력 품질에 대한 자세한 내용은 생성형 AI 도구 사용 시 의사소통을 참조하세요.

검토#

머지하기 전에 개발자가 커밋한 문서 변경사항은 다음 사람들의 검토를 받아야 합니다:

  • 머지 리퀘스트의 코드 리뷰어. 이것은 기술 검토라고 합니다.

  • 선택적으로, 다른 개발자나 제품 관리자와 같이 작업에 참여한 다른 사람들.

  • DevOps Stage 그룹의 Technical Writer. 단, 머지 후 검토를 요청할 수 있는 예외적인 상황은 제외합니다.

  • 프로젝트의 maintainer.

머지 후 검토#

GitLab에서는 코드와 마찬가지로 문서를 취급합니다. 코드와 마찬가지로 품질을 보장하기 위해 문서를 검토해야 합니다. 문서는 GitLab 완료 정의의 일부를 형성하며, 마일스톤 릴리즈 전에 완료되어야 합니다.

문서는 Technical Writer 검토 없이 기능과 함께 머지되는 경우가 있습니다. 머지 전에 Technical Writer 검토를 위해 배정되지 않은 경우, 개발자 또는 maintainer는 머지 직후에 검토를 예약해야 합니다. 이를 위해 Doc Review 설명 템플릿으로 이슈를 생성하고 문서 변경을 도입한 머지된 머지 리퀘스트에 대한 링크를 추가하세요.

머지 후 Technical Writer 검토가 발생할 수 있는 상황은 다음과 같습니다:

  • 마일스톤 릴리즈 전에 남은 시간이 적을 때. 3일 미만이 남아 있으면, 머지 후 검토를 구하고 검토가 가능한 빨리 완료되도록 Slack에서 Writer를 핑하세요.

  • 변경 규모가 작고 기능의 초기 사용자(예: GitLab.com 사용자)가 작성된 문서를 쉽게 사용할 수 있다는 높은 확신이 있을 때.

Technical Writer는 또한 Technical Writer 검토 없이 문서를 머지할 수 있는지 결정하는 데 도움을 줄 수 있지만, 머지 후 검토는 가능한 빨리 이루어져야 합니다.

제품 관리자 책임#

제품 관리자는 기능 또는 기능 개선에 대한 문서 요구사항에 대한 책임이 있습니다. 또한 다음을 할 수 있습니다:

  • 논의 및 협업을 위해 Technical Writer와 연결.

  • 직접 문서 검토.

새로운 또는 업데이트된 문서가 필요한 이슈의 경우, 제품 관리자는 반드시:

  • ~documentation 라벨 추가.

  • 문서 요구사항 확인 또는 추가.

  • 이슈에 다음이 포함되도록 확인:

새로운 또는 업데이트된 기능 이름.

  • 해당하는 경우 개요, 설명 및 사용 사례(문서 폴더 구조에서 요구하는 대로).

모든 사람이 이슈에 문서 요구사항 초안을 작성하도록 권장됩니다. 그러나 제품 관리자는:

  • 이슈에 릴리즈 마일스톤이 배정될 때, Documentation 세부사항을 검토하고 업데이트합니다.

  • 킥오프까지 문서 세부사항을 완성합니다.

Technical Writer 책임#

Technical Writer는 다음에 대한 책임이 있습니다:

  • 다가오는 마일스톤에 대한 이슈 논의에 참여하고 MR 검토.

  • 요청 시 이슈의 문서 요구사항 검토.

  • 작성 및 편집 프로세스 전반에 걸쳐 질문에 답하고 도움 및 조언 제공.

  • 머지 전이든 머지 후든 모든 중요한 새로운 및 업데이트된 문서 콘텐츠 검토.

  • 개발자 및 제품 관리자의 기능 문서 제공 지원.

  • 이슈 및 MR에 적절한 라벨이 붙어 있고 문서 콘텐츠에 올바른 메타데이터가 있는지 확인.

계획#

Technical Writer는:

  • 다음 마일스톤의 일부인 그룹의 ~"type::feature" 이슈를 검토하여 작성될 가능성이 있는 콘텐츠 범위를 파악합니다.

  • 해당 목록에서 ~documentation 라벨이 없지만 있어야 하는 이슈에 ~documentation 라벨을 권장하거나, 문서가 실제로 필요한지 확인하기 위해 PM에게 문의합니다.

  • 해당 목록에서 ~direction 이슈에 대해 전체 이슈를 읽고 Documentation 요구사항 섹션을 검토합니다. Documentation 요구사항을 다듬거나 확장하기 위해 이슈에 협력하는 PM 및 다른 사람들과 권장사항이나 질문을 처리합니다.

  • Technical Writing 마일스톤 계획(이슈 템플릿에서 생성된 예시)을 업데이트합니다.

다가오는 마일스톤의 계획된 문서 및 UI 텍스트 작업을 보여주는 보드 또는 필터에 대한 링크를 추가하세요.

  • 그룹 PM 또는 EM이 계획된 작업을 알고 있는지 확인합니다.

협업#

기본적으로 개발자는 독립적으로 문서 변경 작업을 수행하지만, 개발자, 제품 관리자 또는 Technical Writer는 주어진 이슈에 대해 더 광범위한 협업을 제안할 수 있습니다.

또한 Technical Writer는 언제든지 질문에 응답할 수 있습니다.

검토#

Technical Writer는 변경이 머지되기 전이나 후에 모든 문서 변경에 대해 비차단 검토를 제공합니다. 변경의 릴리즈를 차단하거나 지연시킬 수 있는 식별된 문제는 연결된 후속 MR에서 처리됩니다.

문서 요구사항#

기능 문서 요구사항은 이슈 설명의 Documentation 섹션에 있는 해당 기능 계획을 위한 이슈의 일부로 포함되어야 합니다. Feature Proposal 템플릿을 사용하여 생성된 이슈는 기본적으로 이 섹션을 포함합니다.

누구나 이 세부사항을 추가할 수 있지만, 이슈를 특정 릴리즈 마일스톤에 배정하는 제품 관리자는 해당 마일스톤 킥오프 시점까지 이 세부사항이 제시되고 완성되도록 합니다.

개발자, Technical Writer 및 다른 사람들이 요청에 따라 이 계획을 추가로 다듬는 데 도움을 줄 수 있습니다.

다음 세부사항이 포함되어야 합니다:

  • 문서가 사용자가 이해하거나 수행할 수 있도록 안내해야 하는 개념과 절차는 무엇인가?

  • 이를 위해 필요한 새 페이지가 있다면 무엇인가? 업데이트가 필요한 페이지 또는 하위 섹션은 무엇인가? 사용자, 관리자 및 API 문서의 변경 및 추가를 고려하세요.

  • 가이드 또는 지침 세트의 경우, 단일 사용 사례를 다루어야 하는가, 아니면 특정 범위의 사용 사례를 다룰 수 있을 만큼 유연해야 하는가?

  • 이전에 권장된 워크플로를 업데이트해야 하는가? 다양한 관련 위치에서 새 기능에 링크해야 하는가? 문서에 영향을 미쳐야 하는 모든 방법을 고려하세요.

  • 문서가 관련 검색에서 발견될 수 있도록 포함해야 하는 핵심 용어 또는 작업 설명이 있는가?

  • 해당하는 경우 페이지 또는 하위 섹션 제목의 제안된 제목을 포함하세요.

  • 해당하는 경우 상호 참조해야 하는 문서를 나열하세요.

코드와 함께 문서 포함#

현재 Technical Writing 팀은 코드와 관련된 동일한 머지 리퀘스트에 문서를 포함하도록 강력히 권장하지만, 이것이 엄격하게 의무적인 것은 아닙니다. 문서가 기능 MR과 별도의 MR에 추가되는 것은 여전히 일반적입니다.

엔지니어링 팀은 완료 정의의 일부로 문서가 코드 MR에 포함되는 것이 의무적인 워크플로를 채택할 수 있습니다. 팀이 이 워크플로를 채택하면, 해당 팀의 엔지니어는 항상 기능 코드와 동일한 MR에 문서를 포함해야 합니다.

별도의 문서 MR의 단점#

문서를 자체 MR로 분리하는 워크플로에는 많은 단점이 있습니다.

문서가 기능보다 먼저 머지되는 경우:

  • GitLab.com 사용자가 기능이 릴리즈되기 전에 사용하려고 시도하여 지원 티켓이 발생할 수 있습니다.

  • 기능이 지연되면, 문서가 제때 롤백/되돌려지지 않아 해당 릴리즈의 GitLab Self-Managed에 우연히 포함될 수 있습니다.

문서가 기능보다 나중에 머지되는 경우:

  • 기능은 GitLab Self-Managed에 포함될 수 있지만, 문서 MR이 마감일을 놓치면 문서가 없을 수 있습니다.

  • 기능이 GitLab.com 사용자 인터페이스에 문서 없이 나타날 수 있습니다. 이 기능에 놀란 사용자가 문서를 검색하지만 찾지 못하여 지원 티켓이 발생할 수 있습니다.

두 개의 별도 MR을 갖는다는 것은 다음을 의미합니다:

  • 두 명의 다른 사람이 하나의 기능을 머지하는 데 책임이 있을 수 있으며, 이는 비동기 작업 스타일에서는 적합하지 않습니다. 기능이 Technical Writer가 자는 동안 머지될 수 있어 두 머지 사이에 잠재적으로 긴 지연이 발생합니다.

  • 문서 MR이 기능 코드 MR과 동일한 maintainer에게 배정되면, 그는 하나만 처리하는 대신 두 개의 MR을 검토하고 조율해야 합니다.

문서 품질이 낮아질 수 있습니다. 왜냐하면:

  • 별도의 MR에 문서를 두면 훨씬 적은 사람이 검토하고 확인하게 되어, 문제가 누락될 가능성이 높아집니다.

  • 분리된 워크플로에서는 엔지니어가 기능 MR이 준비된 후에야 문서 MR을 생성할 수 있습니다. 이것은 Technical Writer에게 좋은 검토를 위해 기능에 대해 배울 시간이 거의 없습니다. 또한 원하는 것보다 더 빠르게 검토하고 머지해야 한다는 압박이 증가하여, 급하게 처리함으로써 문제가 발생할 수 있습니다.

항상 코드와 함께 문서를 포함하는 이점#

코드와 함께 문서를 포함하는 것(그리고 개발 프로세스 초기에 하는 것)에는 많은 이점이 있습니다:

  • 릴리즈와 관련된 타이밍 문제가 없습니다:

기능이 다음 릴리즈로 미뤄지면, 문서도 함께 미뤄집니다.

  • 기능이 릴리즈에 겨우 포함되면, 문서도 함께 포함됩니다.

  • 기능이 일찍 GitLab.com에 도달하면, 얼리 어답터를 위한 문서도 준비됩니다.

  • 단 한 명만이 기능 머지(코드 maintainer)에 대한 책임이 있습니다.

  • Technical Writer는 기능을 이해할 더 많은 시간을 갖게 되어 Review App 또는 GDK에서 문서 콘텐츠를 더 잘 확인할 수 있습니다. 또한 사용자 인터페이스 텍스트를 개선하거나 추가 사용 사례를 제안할 수 있습니다.

  • 문서의 가시성이 높아집니다:

머지 리퀘스트에 참여하는 모든 사람이 문서를 검토할 수 있습니다. 여기에는 제품 관리자, 깊은 도메인 지식을 가진 여러 엔지니어, 코드 리뷰어 및 maintainer가 포함될 수 있습니다. 그들은 Technical Writer가 알지 못할 수 있는 예시, 배경 또는 개념의 문제를 발견할 가능성이 더 높습니다.

  • 문서의 가시성을 높이는 것은 다른 엔지니어의 문서를 개선하는 부수적인 효과도 있습니다. 서로의 MR을 검토함으로써 각 엔지니어의 문서 작성 능력이 향상됩니다.

  • 문서에 대해 일찍 생각하는 것은 엔지니어가 더 나은 예시를 생성하는 데 도움이 될 수 있습니다. 왜냐하면 사용자가 원하는 예시에 대해 생각하고, 작성하는 코드가 해당 예시를 올바르게 구현하는지 확인해야 하기 때문입니다.

워크플로로서 코드와 함께 문서#

코드와 함께 문서를 의무적인 워크플로로 포함하려면, 팀의 현재 워크플로에 일부 변경이 필요할 수 있습니다:

  • 엔지니어는 Technical Writer뿐만 아니라 코드 리뷰어와 maintainer로부터도 검토할 충분한 시간을 주기 위해 개발 프로세스 초기에 문서를 포함하도록 노력해야 합니다.

  • 리뷰어와 maintainer도 코드 리뷰 중에 문서를 검토하여 설명된 프로세스가 기능의 예상 사용과 일치하고 예시가 올바른지 확인해야 합니다. 스타일이나 문법에 대해서는 걱정할 필요가 없습니다.

  • Technical Writer는 MR에 직접 리뷰어로 배정되어야 하며 단순히 핑만 받아서는 안 됩니다. 이는 언제든지 할 수 있지만, 코드 maintainer 검토 전에 반드시 이루어져야 합니다. 문서와 코드 검토가 동시에 진행되고, 작성자, 리뷰어 및 Technical Writer가 함께 문서를 논의하는 것이 일반적입니다.

  • 문서가 준비되면, Technical Writer는 승인을 클릭하고 일반적으로 MR에 더 이상 참여하지 않습니다. 코드 리뷰 중 기능이 변경되고 문서가 업데이트되면, Technical Writer는 업데이트를 확인하기 위해 MR에 다시 배정되어야 합니다.

  • Maintainer는 Technical Writer가 아직 최종 승인을 하지 않았더라도 현재 상태의 문서와 함께 기능을 머지할 수 있습니다. 문서 검토는 차단 요소가 되어서는 안 됩니다. 따라서 문서를 포함하고 일찍 Technical Writer에게 배정하는 것이 중요합니다. 최종 문서 승인 전에 기능이 머지되면, maintainer는 머지 후 후속 이슈를 생성하고 엔지니어와 Technical Writer 모두에게 배정해야 합니다.

코드와 문서 검토를 위한 병렬 워크플로를 다음과 같이 시각화할 수 있습니다:

graph TD A("Feature MR Created (Engineer)") --> |Assign| B("Code Review (reviewer)") B --> |"Approve / Reassign"| C("Code Review (maintainer)") C --> |Approve| F("Merge (maintainer)") A --> D("Docs Added (Engineer)") D --> |Assign| E("Docs Review (Tech Writer)") E --> |Approve| F

여러 머지 리퀘스트에 걸쳐 분할된 복잡한 기능의 경우:

  • 머지 리퀘스트가 미래 기능을 위한 구성 요소를 구현하고 있지만, 구성 요소가 아직 사용자에게 접근 가능하지 않은 경우, 문서를 포함해서는 안 됩니다.

  • 머지 리퀘스트가 활성화된 사용자 인터페이스 요소, API 엔드포인트 또는 이와 유사한 방식으로 사용자에게 기능을 노출시키는 경우, 해당 MR에는 반드시 문서가 있어야 합니다. 이는 단일 대규모 기능 구현을 위한 빌드업에서 여러 문서 추가가 발생할 수 있음을 의미합니다. 예를 들어 API 문서와 기능 사용 문서가 있습니다.

  • 어떤 엔지니어가 기능 문서를 MR에 추가해야 할지 불명확한 경우, 엔지니어링 관리자가 계획 중에 결정하고, 기능이 릴리즈된 것으로 간주되기 전에 머지되어야 하는 마지막 MR에 문서를 연결해야 합니다. 이것은 종종(항상은 아니지만) 프론트엔드 MR입니다.

문서 숨기기 대신 삭제#

기능이 준비되기 전에 추가된 문서, 미완성된 문서 또는 다른 유사한 이유로 문서를 숨기기 위해 HTML 주석을 사용하지 마세요. 문서를 숨기는 것은 여러 가지 이유로 문제가 있습니다:

  • 예상치 못한 차단 요소로 인해 기능이 무기한 지연될 수 있습니다.

  • 숨겨진 문서는 개발 중 기능이 발전함에 따라 오래된 내용이 됩니다.

  • 취소된 기능은 발견될 때까지 리포지터리를 혼란스럽게 하는 고아 콘텐츠를 남깁니다.

문서가 너무 일찍 추가되어 제거해야 하는 경우, 삭제하세요. 콘텐츠를 제거하는 머지 리퀘스트에서 원래 추가된 머지 리퀘스트에 대한 링크를 추가하세요. 나중에 필요하면 Git 히스토리 또는 이전 MR을 사용하여 콘텐츠를 복구하고 다시 추가할 수 있습니다.

문서가 너무 일찍 추가되는 것을 방지하기 위해, 개발 팀은 코드와 함께 문서를 포함하는 것을 고려해야 합니다.

UI 텍스트#

계획 및 작성#

제품 디자이너는 UI 텍스트를 추가하거나 변경할 계획이 있을 때 해당 Stage 그룹의 Technical Writer에게 문의해야 합니다.

Technical Writer는 아이디어, 계획 또는 실제 텍스트에 대한 초기 검토를 제공할 수 있습니다. Technical Writer는 텍스트의 컨텍스트와 목표가 제공되면 텍스트 초안 작성을 요청받을 수 있습니다. 컨텍스트에는 텍스트가 표시될 위치와 전달할 정보가 포함될 수 있으며, 일반적으로 다음 질문 중 하나 이상에 답합니다:

  • 이것은 무엇을 하는가?

  • 어떻게 사용하는가?

  • 왜 신경 써야 하는가?

검토 라운드당 알림 양을 관리하는 데 도움이 되도록, 검토가 필요한 위치를 나타내는 메시지와 함께 검토 요청에서 Technical Writer를 한 번만 태그하는 것을 고려하세요.

MR 검토#

머지 리퀘스트가 생성된 후, UI의 텍스트에 대한 모든 변경 및 추가 사항은 반드시 Technical Writer의 검토를 받아야 합니다. 여기에는 라벨(버튼, 메뉴, 칼럼 헤더 및 UI 섹션) 또는 마이크로카피나 오류 메시지와 같이 UI에 표시되는 모든 문구가 포함될 수 있습니다.

UI 텍스트 작성 및 검토에 대한 자세한 내용은 Copy That: Helping your Users Succeed with Effective Product Copy를 참조하세요.

파이프라인과 브랜치 이름 지정#

gitlab 및 gitlab-runner 프로젝트의 CI/CD 파이프라인은 문서 변경만 포함하는 머지 리퀘스트에서 더 짧고 빠른 파이프라인을 실행하도록 구성되어 있습니다.

omnibus-gitlab, charts/gitlab 또는 gitlab-operator에 문서 전용 변경사항을 제출하고 더 짧은 파이프라인을 실행하려면, 브랜치 이름을 지정할 때 다음 가이드라인을 따라야 합니다:

브랜치 이름 유효한 예시
docs/로 시작 docs/update-api-issues
docs-로 시작 docs-update-api-issues
-docs로 끝남 123-update-api-issues-docs

gitlab 프로젝트에서 이 파일들에 대한 변경사항은 일부 코드 테스트가 이 파일들을 예시로 사용하기 때문에 자동으로 긴 파이프라인을 트리거합니다:

  • doc/_index.md

  • doc/api/settings.md

이 페이지를 편집하면, 긴 파이프라인이 코드 MR과 동일하게 나타나지만 추가 승인이 필요하지 않습니다. 긴 파이프라인에 대한 자세한 내용은 GitLab 프로젝트의 파이프라인을 참조하세요.

pre-merge-checks job이 tier-3 파이프라인 또는 예측 파이프라인에 대한 메시지와 함께 실패하면, 다음 단계를 따르세요:

  • MR에 ~"pipeline::tier-3" 및 ~"pipeline:mr-approved" 라벨을 추가합니다.

  • 새 파이프라인을 실행합니다.

  • 파이프라인이 실행되는 동안 MR을 자동 머지로 설정합니다.

MR을 작업하는 동안 긴 파이프라인 실행을 방지하려면, 파이프라인을 트리거하지 않고 커밋을 푸시할 수 있습니다. 자세한 내용은 파이프라인 건너뛰기를 참조하세요.

콘텐츠 이동#

콘텐츠를 새 위치로 이동하고 동일한 머지 리퀘스트에서 콘텐츠를 편집하는 경우, 별도의 커밋을 사용하세요.

별도의 커밋은 리뷰어를 도와줍니다. 왜냐하면 이동된 콘텐츠의 MR diff가 편집 사항을 명확하게 강조하지 않기 때문입니다. 별도의 커밋을 사용하면, 리뷰어가 첫 번째 커밋 diff에서 위치 변경을 확인한 후 이후 커밋에서 콘텐츠 변경을 확인할 수 있습니다.

예를 들어, 페이지를 이동하면서 페이지 콘텐츠도 업데이트하는 경우:

  • 첫 번째 커밋에서: 콘텐츠를 새 위치로 이동하고 필요한 경우 리디렉션을 배치하세요. 가능하면 이 커밋에서 깨진 링크를 수정하세요.

  • 이후 커밋에서: 콘텐츠 변경 사항을 적용하세요. 아직 수정하지 않았다면 깨진 링크를 수정하세요.

  • 머지 리퀘스트에서: MR 설명과 리뷰어에 대한 코멘트에서 커밋을 설명하세요.

커밋을 원하는 만큼 추가할 수 있지만, 첫 번째 커밋은 콘텐츠를 이동하기만 하고 편집하지 않아야 합니다.

라벨#

Technical Writing 팀은 이슈와 머지 리퀘스트에 다음 라벨을 사용합니다:

  • 변경 유형에 대한 라벨. 가장 자주 사용되는 두 가지 라벨은:

~"type::feature"

  • ~"type::maintenance"와 ~"maintenance::refactor"

  • Stage 및 그룹 라벨. 예를 들어:

~devops::create

  • ~group::source code

  • ~documentation 전문화 라벨.

  • ~Technical Writing 팀 라벨.

문서 머지 리퀘스트 템플릿에는 이 라벨들 중 일부가 포함되어 있습니다.

사용 가능한 라벨#

Technical Writer가 작업하는 모든 이슈 또는 머지 리퀘스트에는 Technical Writing 라벨이 포함되어야 합니다.

작업 유형을 추가로 분류하려면, 다음 라벨 중 하나 이상을 포함하세요:

  • Category:Docs Site: 문서 웹사이트 인프라 또는 코드. 문서 자체와 관련된 이슈에는 필요하지 않습니다. 이 라벨이 있는 이슈는 Docs Workflow 이슈 보드에 포함됩니다.

  • development guidelines: /developer 디렉터리의 파일.

  • docs-feedback: 문서 피드백 위젯, 설문 verbatim 또는 고객이 생성한 이슈의 피드백.

  • docs-missing: 기능에 대한 문서가 누락됨. 문서는 GitLab 완료 정의의 일부로 특정 마일스톤에 대한 기능 제공과 함께 필요합니다. 이 라벨을 문서가 누락된 원래 기능 MR 또는 이슈에 추가하세요. 이력 추적을 위해 라벨을 유지하고 문서가 완료되면 tw::finished를 사용하여 표시하세요. 실험 기능에는 적용되지 않습니다.

  • documentation: /doc 디렉터리의 파일.

  • global nav: 문서 사이트의 왼쪽 내비게이션. docs-gitlab-com 프로젝트에서 사용됩니다.

  • L10N-docs: Technical Writing 팀의 워크플로 또는 docs.gitlab.com 사이트 및 인프라에 영향을 미치는 현지화 이슈, MR 또는 에픽.

  • release post item: 릴리즈 포스트 항목.

  • Technical Writing Leadership: OKR과 같이 Technical Writing 리더십 팀이 주도하거나 소유하는 작업.

  • tw-lead: Stage 리드 중 한 명이 주도하거나 입력이 필요한 MR.

  • tw-style: 문서 및 UI 텍스트에 대한 스타일 표준.

  • UI text: UI 텍스트 및 오류 메시지와 같은 사용자 대면 텍스트.

기타 문서 라벨에는 vale, docs-only, docs-channel이 포함됩니다. 이 라벨들은 선택 사항입니다.

유형 라벨#

제품의 일부인 프로젝트의 모든 이슈 및 머지 리퀘스트는 작업 유형으로 라벨을 붙여야 합니다. 핸드북 및 마케팅 사이트 변경에는 작업 유형 라벨이 필요하지 않습니다. 이슈 또는 머지 리퀘스트에 다음 라벨 중 하나를 추가하세요:

  • type::feature

  • type::bug

  • type::maintenance

자세한 내용은 작업 유형 분류를 참조하세요.

대부분의 문서 작업은 type::maintenance 라벨을 사용합니다. 유지 관리 작업의 유형을 추가로 분류하기 위해 이 하위 유형 라벨 중 하나를 적용해야 합니다:

  • maintenance::refactor: 기존 문서의 편집 및 개선.

  • maintenance::workflow: 린팅 및 도구 업데이트, 메타데이터 변경과 같이 독자에게 보이지 않는 문서 변경.

예를 들어, CTRT를 위해 페이지를 리팩토링하는 머지 리퀘스트를 열면 type::maintenance와 maintenance::refactor 라벨을 적용하세요. 메타데이터를 수정하는 머지 리퀘스트를 열면 type::maintenance와 maintenance::workflow 라벨을 적용하세요.

워크플로 라벨#

Writer는 이슈 또는 머지 리퀘스트에서 작업 상태를 설명하기 위해 이 라벨들을 사용할 수 있습니다:

  • tw::doing

  • tw::finished

콘텐츠를 작성하는 Technical Writer는 일반적으로 tw::doing 라벨을 추가하고, 검토를 수행하는 Technical Writer는 일반적으로 tw::finished 라벨을 추가합니다. 커뮤니티 기여자의 콘텐츠 제출에 대해서는, Technical Writer가 검토의 일부로 두 라벨을 모두 추가합니다.

워크플로는 다음과 같습니다:

  • 이슈 또는 머지 리퀘스트가 검토를 위해 Writer에게 배정됩니다.

  • Writer는 활발히 작업하는 동안 tw::doing 라벨을 추가합니다.

Writer가 1주일 이상 작업을 중단하면, tw::doing 라벨을 제거합니다.

  • 작업이 재개될 때마다, Writer는 tw::doing 라벨을 다시 추가합니다.

  • 이슈 또는 머지 리퀘스트에 대한 작업이 완료되면, Technical Writer(일반적으로 리뷰어)가 tw::finished 라벨을 추가합니다.

  • 이슈 또는 머지 리퀘스트가 닫히거나 머지됩니다.

tw::finished 라벨은 Writer가 닫거나 머지하지 않는 이슈 또는 머지 리퀘스트에 대한 작업을 완료했음을 나타냅니다. Technical Writing 팀이 닫거나 머지하는 경우, 이슈 또는 머지 리퀘스트 상태가 범위가 지정된 tw 라벨 상태를 재정의합니다. Technical Writer는 tw::finished 라벨을 사용할 필요가 없습니다.

Technical Writer가 추가 작업이 필요한 tw::finished 라벨이 있는 열린 이슈 또는 머지 리퀘스트를 발견하면, Writer는 tw::doing 범위 지정 라벨을 다시 추가해야 합니다.

릴리즈 포스트#

각 Stage 그룹의 Technical Writer는 제품 관리자가 작성한 그룹의 기능 블록(릴리즈 포스트 항목)을 검토합니다.

각 릴리즈에 대해, 단일 Technical Writer가 구조 확인 및 기타 업무를 수행하기 위해 Technical Writing Lead로 배정됩니다.

월간 문서 릴리즈#

새로운 GitLab 버전이 릴리즈되면, Technical Writing 팀은 버전별 게시 문서를 릴리즈합니다.

문서 피드백 및 개선사항#

특정 코드 변경과 관련이 없는 문서 변경을 하려면, Technical Writing 팀은 기여자들이 MR을 생성하도록 권장합니다.

MR 대신 이슈로 시작하는 경우, 문서 템플릿을 사용하세요. 적용해야 하는 라벨에 대해서는 라벨을 참조하세요.

또한 다음을 포함하세요:

  • 마일스톤: 마일스톤에 예약될 때까지 Backlog.

  • 담당자: 마일스톤에 예약될 때까지 None. 인식을 위해 이슈 설명 또는 코멘트에서 그룹에 배정된 Technical Writer를 (@username 형태로) 언급하세요.

  • 설명: Docs: 또는 Docs feedback:으로 시작.

  • MVC 제공을 위한 작업 체크리스트 또는 다음 단계.

  • 선택 사항. 이슈가 커뮤니티 기여자에게 적합한 경우: Seeking community contributions 및 quick win.

이슈가 Technical Writer가 작업을 시작하기 전에 개발 팀의 입력이 필요한 경우, Stage 및 그룹의 이슈 라이프사이클을 따라야 합니다. 이슈 라이프사이클의 예시는 Plan Stage 이슈를 참조하세요.

문서 전용 백로그 이슈 검토 및 분류#

Technical Writer는 이슈 보드를 사용하여 그룹의 문서 피드백 및 개선 이슈를 정기적으로 검토하고 분류합니다. 이를 통해 사용자 경험을 개선하는 실행 가능한 이슈의 우선순위를 정할 수 있습니다.

그룹의 이슈 분류 보드를 생성하려면:

Docs only backlog triage - group name이라는 이슈 보드를 생성하세요.

다음 필터 기준을 입력하세요:

Label=documentation, Label="group::groupname", Label!="type::feature", Label!="type:bug"

Edit board에서 Show the Open list가 선택되어 있는지 확인하세요.

이슈 보드에서 Create list를 선택하고 라벨을 tw:triaged로 설정하세요.

Project Management 그룹의 예시 보드를 참조하세요.

그룹의 문서 피드백 및 개선 이슈를 검토하고 분류하려면:

  • 월 1회, 그룹의 이슈 분류 보드에서 Open 목록에서 새 이슈를 확인하세요.

  • 문서 피드백 및 개선사항에 설명된 라벨을 적용하세요.

  • 열린 미분류 이슈 목록을 10개 미만으로 유지하는 것을 목표로 하세요.

  • 분류된 목록을 그룹 및 그룹 PM과 공유하세요.

Technical Writer 검토 없는 페이지#

/doc/solutions 아래의 문서는 Solutions Architect 팀이 생성, 유지 관리, 편집 및 머지합니다.

해커톤#

Technical Writing 팀은 GitLab 해커톤에 참여하며 때로는 문서 전용 해커톤을 개최합니다.

해커톤을 위한 이슈 생성#

해커톤을 위해 문서 이슈를 자주 생성합니다. 이 이슈들은 일반적으로 문서에 대해 Vale를 실행할 때 발견된 결과를 기반으로 합니다.

전체 문서 세트에 대해 Vale를 실행하세요. GitLab 리포지터리로 이동하여 다음을 실행하세요:

find doc -name '*.md' | sort | xargs vale --minAlertLevel suggestion --output line > ../results.txt

이슈를 생성하세요. 몇 가지 옵션이 있습니다:

스크립트를 사용하여 Vale 결과에 나열된 각 마크다운 파일에 대해 하나의 이슈를 생성하세요. 이 스크립트는 Doc cleanup 이슈 템플릿을 사용합니다.

  • Doc cleanup 이슈 템플릿을 사용하여 이슈를 하나씩 생성하세요.

  • 이슈 API를 사용하여 이슈를 일괄 생성하세요.

이슈에 배정된 라벨이 Doc cleanup 이슈 템플릿의 라벨과 일치하는지 확인하세요.

커뮤니티 기여자에게 이슈 배정#

커뮤니티 기여자에게 이슈를 배정하려면:

  • Seeking community contributions 라벨을 제거하세요.

  • 코멘트에서 /assign @username을 입력하여 사용자를 배정하세요. 여기서 @username은 기여자의 핸들입니다.

  • 코멘트에서 사용자를 언급하여 이슈가 이제 그들에게 배정되었음을 알리세요.

각 기여자당 동시에 세 개 이하의 이슈로 제한하도록 하세요. 이미 배정된 이슈 중 하나에 대해 MR을 열면 다른 이슈를 배정할 수 있습니다.

해커톤 머지 리퀘스트 검토#

커뮤니티 기여자가 해커톤 머지 리퀘스트를 열 때:

관련 이슈를 확인하세요. MR을 작성한 사용자가 이슈에 배정을 요청한 동일한 사용자인지 확인하세요.

이슈에 사용자가 나열되지 않았고, 다른 사용자가 이슈 작업을 요청한 경우, MR을 머지하지 마세요. MR 작성자에게 아직 배정되지 않은 이슈를 찾거나 GitLab 개발에 기여로 안내하세요.

머지 리퀘스트 머지 작업을 수행하세요.

머지할 때 관련 이슈를 닫으세요.

관련 주제#

워크플로

GitLab v19.1
원문 보기
요약

Technical Writing 팀은 다음 작업에서 기여자, 개발자, 제품 관리자와 협업하기 위해 워크플로를 사용합니다: GitLab 제품 문서를 생성하고 유지 관리하는 프로세스는 문서의 종류에 따라 다릅니다: 새로운 기능 또는 기능 개선: 특정 마일스톤에 맞춰 제공되며 특정 코드 변경과 연관됩니다.

Technical Writing 팀은 다음 작업에서 기여자, 개발자, 제품 관리자와 협업하기 위해 워크플로를 사용합니다:

  • 제품 문서 변경

  • UI 텍스트

  • 릴리즈 포스트

제품 변경을 위한 문서#

GitLab 제품 문서를 생성하고 유지 관리하는 프로세스는 문서의 종류에 따라 다릅니다:

  • 새로운 기능 또는 기능 개선: 특정 마일스톤에 맞춰 제공되며 특정 코드 변경과 연관됩니다. 이 문서는 최우선 순위를 가집니다.

  • 특정 마일스톤 외부의 변경: 일반적으로 특정 코드 변경과 관련이 없으며, 우선순위가 낮고 모든 GitLab 기여자에게 열려 있습니다.

다음 경우에 마일스톤에 대한 문서가 필요합니다:

  • 사용자 또는 관리자 경험에 영향을 미치는 새로운 기능 또는 향상된 기능이 릴리즈될 때.

  • 사용자 인터페이스 또는 API에 변경이 있을 때.

  • 프로세스, 워크플로 또는 이전에 문서화된 기능이 변경될 때.

  • 기능이 사용 중단(deprecated)되거나 제거될 때.

백엔드 기능이 추가되거나 변경될 때는 일반적으로 문서가 필요하지 않습니다.

개발자 책임#

개발자는 기능 또는 기능 개선에 대한 문서의 주요 작성자입니다. 개발자는 다음에 대한 책임이 있습니다:

  • 기능에 필요한 초기 콘텐츠 개발.

  • 어떤 문서를 언제 제공해야 하는지 이해하기 위해 제품 관리자와 협력.

  • 해당 그룹의 다른 개발자에게 기술 검토 요청.

  • 새로운 기능 또는 기능 개선을 제공하는 DevOps Stage 그룹에 배정된 Technical Writer에게 문서 검토 요청.

가능하면 코드가 포함된 머지 리퀘스트에 문서도 함께 포함해야 합니다. 자세한 내용은 가이드라인을 참조하세요.

이 MR의 작성자(프론트엔드 또는 백엔드 개발자)가 문서를 작성해야 합니다.

커뮤니티 기여자는 GitLab 팀 멤버에게 추가적인 도움을 요청할 수 있습니다.

작성#

문서는 제품의 필수적인 부분이므로, ~"type::feature" 이슈에 ~documentation 라벨도 포함되어 있다면 기능의 코드와 함께 새로운 또는 업데이트된 문서를 제공해야 합니다.

Technical Writer는 이슈별로 요청 및 계획에 따라 기꺼이 도움을 드립니다.

문서가 필요한 기능 이슈의 경우, 제품 관리자 및 Technical Writer와 달리 합의하지 않는 한 아래 프로세스를 따르세요:

다음 중 하나에 새로운 및 편집된 문서를 포함하세요:

코드를 도입하는 머지 리퀘스트.

  • 거의 동시에 제출된 별도의 머지 리퀘스트.

이슈에서 제품 관리자가 개발한 문서 요구사항을 사용하고 필요에 따라 추가 문서 계획이나 아이디어를 논의하세요.

새로운 또는 변경된 문서가 광범위한 협업이나 대화가 필요한 경우, 계획 프로세스를 위해 별도의 연결된 이슈를 사용할 수 있습니다.

문서 가이드라인과 여기에 연결된 다른 리소스를 사용하세요:

문서 폴더 구조.

다음의 경우 이슈 또는 머지 리퀘스트, 또는 #docs Slack 채널에서 관련 DevOps Stage의 Technical Writer에게 연락하세요:

문서를 위한 올바른 위치 선택에 도움이 필요할 때.

  • 문서 아이디어나 개요를 논의하고 싶을 때.

  • 다른 도움을 요청하고 싶을 때.

별도의 머지 리퀘스트에서 문서를 작업하는 경우, 코드 머지에 최대한 가깝게 문서가 머지되도록 하세요.

기능에 feature flag가 있는 경우, feature flag가 있는 이슈 문서화 정책을 따르세요.

AI 생성 문서#

모든 AI 생성 문서는 Technical Writer의 검토를 받아야 합니다. 검토를 위해 문서를 제출하기 전에 문서 파일에 대해 Vale 테스트를 실행하여 스타일 문제를 식별하고 수정하세요.

생성형 AI 도구는 주제 전문 지식을 대체할 수 없습니다. 작성자는 자신이 생성하는 모든 콘텐츠의 기술적 정확성을 보장할 책임이 있습니다. 출력 품질에 대한 자세한 내용은 생성형 AI 도구 사용 시 의사소통을 참조하세요.

검토#

머지하기 전에 개발자가 커밋한 문서 변경사항은 다음 사람들의 검토를 받아야 합니다:

  • 머지 리퀘스트의 코드 리뷰어. 이것은 기술 검토라고 합니다.

  • 선택적으로, 다른 개발자나 제품 관리자와 같이 작업에 참여한 다른 사람들.

  • DevOps Stage 그룹의 Technical Writer. 단, 머지 후 검토를 요청할 수 있는 예외적인 상황은 제외합니다.

  • 프로젝트의 maintainer.

머지 후 검토#

GitLab에서는 코드와 마찬가지로 문서를 취급합니다. 코드와 마찬가지로 품질을 보장하기 위해 문서를 검토해야 합니다. 문서는 GitLab 완료 정의의 일부를 형성하며, 마일스톤 릴리즈 전에 완료되어야 합니다.

문서는 Technical Writer 검토 없이 기능과 함께 머지되는 경우가 있습니다. 머지 전에 Technical Writer 검토를 위해 배정되지 않은 경우, 개발자 또는 maintainer는 머지 직후에 검토를 예약해야 합니다. 이를 위해 Doc Review 설명 템플릿으로 이슈를 생성하고 문서 변경을 도입한 머지된 머지 리퀘스트에 대한 링크를 추가하세요.

머지 후 Technical Writer 검토가 발생할 수 있는 상황은 다음과 같습니다:

  • 마일스톤 릴리즈 전에 남은 시간이 적을 때. 3일 미만이 남아 있으면, 머지 후 검토를 구하고 검토가 가능한 빨리 완료되도록 Slack에서 Writer를 핑하세요.

  • 변경 규모가 작고 기능의 초기 사용자(예: GitLab.com 사용자)가 작성된 문서를 쉽게 사용할 수 있다는 높은 확신이 있을 때.

Technical Writer는 또한 Technical Writer 검토 없이 문서를 머지할 수 있는지 결정하는 데 도움을 줄 수 있지만, 머지 후 검토는 가능한 빨리 이루어져야 합니다.

제품 관리자 책임#

제품 관리자는 기능 또는 기능 개선에 대한 문서 요구사항에 대한 책임이 있습니다. 또한 다음을 할 수 있습니다:

  • 논의 및 협업을 위해 Technical Writer와 연결.

  • 직접 문서 검토.

새로운 또는 업데이트된 문서가 필요한 이슈의 경우, 제품 관리자는 반드시:

  • ~documentation 라벨 추가.

  • 문서 요구사항 확인 또는 추가.

  • 이슈에 다음이 포함되도록 확인:

새로운 또는 업데이트된 기능 이름.

  • 해당하는 경우 개요, 설명 및 사용 사례(문서 폴더 구조에서 요구하는 대로).

모든 사람이 이슈에 문서 요구사항 초안을 작성하도록 권장됩니다. 그러나 제품 관리자는:

  • 이슈에 릴리즈 마일스톤이 배정될 때, Documentation 세부사항을 검토하고 업데이트합니다.

  • 킥오프까지 문서 세부사항을 완성합니다.

Technical Writer 책임#

Technical Writer는 다음에 대한 책임이 있습니다:

  • 다가오는 마일스톤에 대한 이슈 논의에 참여하고 MR 검토.

  • 요청 시 이슈의 문서 요구사항 검토.

  • 작성 및 편집 프로세스 전반에 걸쳐 질문에 답하고 도움 및 조언 제공.

  • 머지 전이든 머지 후든 모든 중요한 새로운 및 업데이트된 문서 콘텐츠 검토.

  • 개발자 및 제품 관리자의 기능 문서 제공 지원.

  • 이슈 및 MR에 적절한 라벨이 붙어 있고 문서 콘텐츠에 올바른 메타데이터가 있는지 확인.

계획#

Technical Writer는:

  • 다음 마일스톤의 일부인 그룹의 ~"type::feature" 이슈를 검토하여 작성될 가능성이 있는 콘텐츠 범위를 파악합니다.

  • 해당 목록에서 ~documentation 라벨이 없지만 있어야 하는 이슈에 ~documentation 라벨을 권장하거나, 문서가 실제로 필요한지 확인하기 위해 PM에게 문의합니다.

  • 해당 목록에서 ~direction 이슈에 대해 전체 이슈를 읽고 Documentation 요구사항 섹션을 검토합니다. Documentation 요구사항을 다듬거나 확장하기 위해 이슈에 협력하는 PM 및 다른 사람들과 권장사항이나 질문을 처리합니다.

  • Technical Writing 마일스톤 계획(이슈 템플릿에서 생성된 예시)을 업데이트합니다.

다가오는 마일스톤의 계획된 문서 및 UI 텍스트 작업을 보여주는 보드 또는 필터에 대한 링크를 추가하세요.

  • 그룹 PM 또는 EM이 계획된 작업을 알고 있는지 확인합니다.

협업#

기본적으로 개발자는 독립적으로 문서 변경 작업을 수행하지만, 개발자, 제품 관리자 또는 Technical Writer는 주어진 이슈에 대해 더 광범위한 협업을 제안할 수 있습니다.

또한 Technical Writer는 언제든지 질문에 응답할 수 있습니다.

검토#

Technical Writer는 변경이 머지되기 전이나 후에 모든 문서 변경에 대해 비차단 검토를 제공합니다. 변경의 릴리즈를 차단하거나 지연시킬 수 있는 식별된 문제는 연결된 후속 MR에서 처리됩니다.

문서 요구사항#

기능 문서 요구사항은 이슈 설명의 Documentation 섹션에 있는 해당 기능 계획을 위한 이슈의 일부로 포함되어야 합니다. Feature Proposal 템플릿을 사용하여 생성된 이슈는 기본적으로 이 섹션을 포함합니다.

누구나 이 세부사항을 추가할 수 있지만, 이슈를 특정 릴리즈 마일스톤에 배정하는 제품 관리자는 해당 마일스톤 킥오프 시점까지 이 세부사항이 제시되고 완성되도록 합니다.

개발자, Technical Writer 및 다른 사람들이 요청에 따라 이 계획을 추가로 다듬는 데 도움을 줄 수 있습니다.

다음 세부사항이 포함되어야 합니다:

  • 문서가 사용자가 이해하거나 수행할 수 있도록 안내해야 하는 개념과 절차는 무엇인가?

  • 이를 위해 필요한 새 페이지가 있다면 무엇인가? 업데이트가 필요한 페이지 또는 하위 섹션은 무엇인가? 사용자, 관리자 및 API 문서의 변경 및 추가를 고려하세요.

  • 가이드 또는 지침 세트의 경우, 단일 사용 사례를 다루어야 하는가, 아니면 특정 범위의 사용 사례를 다룰 수 있을 만큼 유연해야 하는가?

  • 이전에 권장된 워크플로를 업데이트해야 하는가? 다양한 관련 위치에서 새 기능에 링크해야 하는가? 문서에 영향을 미쳐야 하는 모든 방법을 고려하세요.

  • 문서가 관련 검색에서 발견될 수 있도록 포함해야 하는 핵심 용어 또는 작업 설명이 있는가?

  • 해당하는 경우 페이지 또는 하위 섹션 제목의 제안된 제목을 포함하세요.

  • 해당하는 경우 상호 참조해야 하는 문서를 나열하세요.

코드와 함께 문서 포함#

현재 Technical Writing 팀은 코드와 관련된 동일한 머지 리퀘스트에 문서를 포함하도록 강력히 권장하지만, 이것이 엄격하게 의무적인 것은 아닙니다. 문서가 기능 MR과 별도의 MR에 추가되는 것은 여전히 일반적입니다.

엔지니어링 팀은 완료 정의의 일부로 문서가 코드 MR에 포함되는 것이 의무적인 워크플로를 채택할 수 있습니다. 팀이 이 워크플로를 채택하면, 해당 팀의 엔지니어는 항상 기능 코드와 동일한 MR에 문서를 포함해야 합니다.

별도의 문서 MR의 단점#

문서를 자체 MR로 분리하는 워크플로에는 많은 단점이 있습니다.

문서가 기능보다 먼저 머지되는 경우:

  • GitLab.com 사용자가 기능이 릴리즈되기 전에 사용하려고 시도하여 지원 티켓이 발생할 수 있습니다.

  • 기능이 지연되면, 문서가 제때 롤백/되돌려지지 않아 해당 릴리즈의 GitLab Self-Managed에 우연히 포함될 수 있습니다.

문서가 기능보다 나중에 머지되는 경우:

  • 기능은 GitLab Self-Managed에 포함될 수 있지만, 문서 MR이 마감일을 놓치면 문서가 없을 수 있습니다.

  • 기능이 GitLab.com 사용자 인터페이스에 문서 없이 나타날 수 있습니다. 이 기능에 놀란 사용자가 문서를 검색하지만 찾지 못하여 지원 티켓이 발생할 수 있습니다.

두 개의 별도 MR을 갖는다는 것은 다음을 의미합니다:

  • 두 명의 다른 사람이 하나의 기능을 머지하는 데 책임이 있을 수 있으며, 이는 비동기 작업 스타일에서는 적합하지 않습니다. 기능이 Technical Writer가 자는 동안 머지될 수 있어 두 머지 사이에 잠재적으로 긴 지연이 발생합니다.

  • 문서 MR이 기능 코드 MR과 동일한 maintainer에게 배정되면, 그는 하나만 처리하는 대신 두 개의 MR을 검토하고 조율해야 합니다.

문서 품질이 낮아질 수 있습니다. 왜냐하면:

  • 별도의 MR에 문서를 두면 훨씬 적은 사람이 검토하고 확인하게 되어, 문제가 누락될 가능성이 높아집니다.

  • 분리된 워크플로에서는 엔지니어가 기능 MR이 준비된 후에야 문서 MR을 생성할 수 있습니다. 이것은 Technical Writer에게 좋은 검토를 위해 기능에 대해 배울 시간이 거의 없습니다. 또한 원하는 것보다 더 빠르게 검토하고 머지해야 한다는 압박이 증가하여, 급하게 처리함으로써 문제가 발생할 수 있습니다.

항상 코드와 함께 문서를 포함하는 이점#

코드와 함께 문서를 포함하는 것(그리고 개발 프로세스 초기에 하는 것)에는 많은 이점이 있습니다:

  • 릴리즈와 관련된 타이밍 문제가 없습니다:

기능이 다음 릴리즈로 미뤄지면, 문서도 함께 미뤄집니다.

  • 기능이 릴리즈에 겨우 포함되면, 문서도 함께 포함됩니다.

  • 기능이 일찍 GitLab.com에 도달하면, 얼리 어답터를 위한 문서도 준비됩니다.

  • 단 한 명만이 기능 머지(코드 maintainer)에 대한 책임이 있습니다.

  • Technical Writer는 기능을 이해할 더 많은 시간을 갖게 되어 Review App 또는 GDK에서 문서 콘텐츠를 더 잘 확인할 수 있습니다. 또한 사용자 인터페이스 텍스트를 개선하거나 추가 사용 사례를 제안할 수 있습니다.

  • 문서의 가시성이 높아집니다:

머지 리퀘스트에 참여하는 모든 사람이 문서를 검토할 수 있습니다. 여기에는 제품 관리자, 깊은 도메인 지식을 가진 여러 엔지니어, 코드 리뷰어 및 maintainer가 포함될 수 있습니다. 그들은 Technical Writer가 알지 못할 수 있는 예시, 배경 또는 개념의 문제를 발견할 가능성이 더 높습니다.

  • 문서의 가시성을 높이는 것은 다른 엔지니어의 문서를 개선하는 부수적인 효과도 있습니다. 서로의 MR을 검토함으로써 각 엔지니어의 문서 작성 능력이 향상됩니다.

  • 문서에 대해 일찍 생각하는 것은 엔지니어가 더 나은 예시를 생성하는 데 도움이 될 수 있습니다. 왜냐하면 사용자가 원하는 예시에 대해 생각하고, 작성하는 코드가 해당 예시를 올바르게 구현하는지 확인해야 하기 때문입니다.

워크플로로서 코드와 함께 문서#

코드와 함께 문서를 의무적인 워크플로로 포함하려면, 팀의 현재 워크플로에 일부 변경이 필요할 수 있습니다:

  • 엔지니어는 Technical Writer뿐만 아니라 코드 리뷰어와 maintainer로부터도 검토할 충분한 시간을 주기 위해 개발 프로세스 초기에 문서를 포함하도록 노력해야 합니다.

  • 리뷰어와 maintainer도 코드 리뷰 중에 문서를 검토하여 설명된 프로세스가 기능의 예상 사용과 일치하고 예시가 올바른지 확인해야 합니다. 스타일이나 문법에 대해서는 걱정할 필요가 없습니다.

  • Technical Writer는 MR에 직접 리뷰어로 배정되어야 하며 단순히 핑만 받아서는 안 됩니다. 이는 언제든지 할 수 있지만, 코드 maintainer 검토 전에 반드시 이루어져야 합니다. 문서와 코드 검토가 동시에 진행되고, 작성자, 리뷰어 및 Technical Writer가 함께 문서를 논의하는 것이 일반적입니다.

  • 문서가 준비되면, Technical Writer는 승인을 클릭하고 일반적으로 MR에 더 이상 참여하지 않습니다. 코드 리뷰 중 기능이 변경되고 문서가 업데이트되면, Technical Writer는 업데이트를 확인하기 위해 MR에 다시 배정되어야 합니다.

  • Maintainer는 Technical Writer가 아직 최종 승인을 하지 않았더라도 현재 상태의 문서와 함께 기능을 머지할 수 있습니다. 문서 검토는 차단 요소가 되어서는 안 됩니다. 따라서 문서를 포함하고 일찍 Technical Writer에게 배정하는 것이 중요합니다. 최종 문서 승인 전에 기능이 머지되면, maintainer는 머지 후 후속 이슈를 생성하고 엔지니어와 Technical Writer 모두에게 배정해야 합니다.

코드와 문서 검토를 위한 병렬 워크플로를 다음과 같이 시각화할 수 있습니다:

graph TD A("Feature MR Created (Engineer)") --> |Assign| B("Code Review (reviewer)") B --> |"Approve / Reassign"| C("Code Review (maintainer)") C --> |Approve| F("Merge (maintainer)") A --> D("Docs Added (Engineer)") D --> |Assign| E("Docs Review (Tech Writer)") E --> |Approve| F

여러 머지 리퀘스트에 걸쳐 분할된 복잡한 기능의 경우:

  • 머지 리퀘스트가 미래 기능을 위한 구성 요소를 구현하고 있지만, 구성 요소가 아직 사용자에게 접근 가능하지 않은 경우, 문서를 포함해서는 안 됩니다.

  • 머지 리퀘스트가 활성화된 사용자 인터페이스 요소, API 엔드포인트 또는 이와 유사한 방식으로 사용자에게 기능을 노출시키는 경우, 해당 MR에는 반드시 문서가 있어야 합니다. 이는 단일 대규모 기능 구현을 위한 빌드업에서 여러 문서 추가가 발생할 수 있음을 의미합니다. 예를 들어 API 문서와 기능 사용 문서가 있습니다.

  • 어떤 엔지니어가 기능 문서를 MR에 추가해야 할지 불명확한 경우, 엔지니어링 관리자가 계획 중에 결정하고, 기능이 릴리즈된 것으로 간주되기 전에 머지되어야 하는 마지막 MR에 문서를 연결해야 합니다. 이것은 종종(항상은 아니지만) 프론트엔드 MR입니다.

문서 숨기기 대신 삭제#

기능이 준비되기 전에 추가된 문서, 미완성된 문서 또는 다른 유사한 이유로 문서를 숨기기 위해 HTML 주석을 사용하지 마세요. 문서를 숨기는 것은 여러 가지 이유로 문제가 있습니다:

  • 예상치 못한 차단 요소로 인해 기능이 무기한 지연될 수 있습니다.

  • 숨겨진 문서는 개발 중 기능이 발전함에 따라 오래된 내용이 됩니다.

  • 취소된 기능은 발견될 때까지 리포지터리를 혼란스럽게 하는 고아 콘텐츠를 남깁니다.

문서가 너무 일찍 추가되어 제거해야 하는 경우, 삭제하세요. 콘텐츠를 제거하는 머지 리퀘스트에서 원래 추가된 머지 리퀘스트에 대한 링크를 추가하세요. 나중에 필요하면 Git 히스토리 또는 이전 MR을 사용하여 콘텐츠를 복구하고 다시 추가할 수 있습니다.

문서가 너무 일찍 추가되는 것을 방지하기 위해, 개발 팀은 코드와 함께 문서를 포함하는 것을 고려해야 합니다.

UI 텍스트#

계획 및 작성#

제품 디자이너는 UI 텍스트를 추가하거나 변경할 계획이 있을 때 해당 Stage 그룹의 Technical Writer에게 문의해야 합니다.

Technical Writer는 아이디어, 계획 또는 실제 텍스트에 대한 초기 검토를 제공할 수 있습니다. Technical Writer는 텍스트의 컨텍스트와 목표가 제공되면 텍스트 초안 작성을 요청받을 수 있습니다. 컨텍스트에는 텍스트가 표시될 위치와 전달할 정보가 포함될 수 있으며, 일반적으로 다음 질문 중 하나 이상에 답합니다:

  • 이것은 무엇을 하는가?

  • 어떻게 사용하는가?

  • 왜 신경 써야 하는가?

검토 라운드당 알림 양을 관리하는 데 도움이 되도록, 검토가 필요한 위치를 나타내는 메시지와 함께 검토 요청에서 Technical Writer를 한 번만 태그하는 것을 고려하세요.

MR 검토#

머지 리퀘스트가 생성된 후, UI의 텍스트에 대한 모든 변경 및 추가 사항은 반드시 Technical Writer의 검토를 받아야 합니다. 여기에는 라벨(버튼, 메뉴, 칼럼 헤더 및 UI 섹션) 또는 마이크로카피나 오류 메시지와 같이 UI에 표시되는 모든 문구가 포함될 수 있습니다.

UI 텍스트 작성 및 검토에 대한 자세한 내용은 Copy That: Helping your Users Succeed with Effective Product Copy를 참조하세요.

파이프라인과 브랜치 이름 지정#

gitlab 및 gitlab-runner 프로젝트의 CI/CD 파이프라인은 문서 변경만 포함하는 머지 리퀘스트에서 더 짧고 빠른 파이프라인을 실행하도록 구성되어 있습니다.

omnibus-gitlab, charts/gitlab 또는 gitlab-operator에 문서 전용 변경사항을 제출하고 더 짧은 파이프라인을 실행하려면, 브랜치 이름을 지정할 때 다음 가이드라인을 따라야 합니다:

브랜치 이름 유효한 예시
docs/로 시작 docs/update-api-issues
docs-로 시작 docs-update-api-issues
-docs로 끝남 123-update-api-issues-docs

gitlab 프로젝트에서 이 파일들에 대한 변경사항은 일부 코드 테스트가 이 파일들을 예시로 사용하기 때문에 자동으로 긴 파이프라인을 트리거합니다:

  • doc/_index.md

  • doc/api/settings.md

이 페이지를 편집하면, 긴 파이프라인이 코드 MR과 동일하게 나타나지만 추가 승인이 필요하지 않습니다. 긴 파이프라인에 대한 자세한 내용은 GitLab 프로젝트의 파이프라인을 참조하세요.

pre-merge-checks job이 tier-3 파이프라인 또는 예측 파이프라인에 대한 메시지와 함께 실패하면, 다음 단계를 따르세요:

  • MR에 ~"pipeline::tier-3" 및 ~"pipeline:mr-approved" 라벨을 추가합니다.

  • 새 파이프라인을 실행합니다.

  • 파이프라인이 실행되는 동안 MR을 자동 머지로 설정합니다.

MR을 작업하는 동안 긴 파이프라인 실행을 방지하려면, 파이프라인을 트리거하지 않고 커밋을 푸시할 수 있습니다. 자세한 내용은 파이프라인 건너뛰기를 참조하세요.

콘텐츠 이동#

콘텐츠를 새 위치로 이동하고 동일한 머지 리퀘스트에서 콘텐츠를 편집하는 경우, 별도의 커밋을 사용하세요.

별도의 커밋은 리뷰어를 도와줍니다. 왜냐하면 이동된 콘텐츠의 MR diff가 편집 사항을 명확하게 강조하지 않기 때문입니다. 별도의 커밋을 사용하면, 리뷰어가 첫 번째 커밋 diff에서 위치 변경을 확인한 후 이후 커밋에서 콘텐츠 변경을 확인할 수 있습니다.

예를 들어, 페이지를 이동하면서 페이지 콘텐츠도 업데이트하는 경우:

  • 첫 번째 커밋에서: 콘텐츠를 새 위치로 이동하고 필요한 경우 리디렉션을 배치하세요. 가능하면 이 커밋에서 깨진 링크를 수정하세요.

  • 이후 커밋에서: 콘텐츠 변경 사항을 적용하세요. 아직 수정하지 않았다면 깨진 링크를 수정하세요.

  • 머지 리퀘스트에서: MR 설명과 리뷰어에 대한 코멘트에서 커밋을 설명하세요.

커밋을 원하는 만큼 추가할 수 있지만, 첫 번째 커밋은 콘텐츠를 이동하기만 하고 편집하지 않아야 합니다.

라벨#

Technical Writing 팀은 이슈와 머지 리퀘스트에 다음 라벨을 사용합니다:

  • 변경 유형에 대한 라벨. 가장 자주 사용되는 두 가지 라벨은:

~"type::feature"

  • ~"type::maintenance"와 ~"maintenance::refactor"

  • Stage 및 그룹 라벨. 예를 들어:

~devops::create

  • ~group::source code

  • ~documentation 전문화 라벨.

  • ~Technical Writing 팀 라벨.

문서 머지 리퀘스트 템플릿에는 이 라벨들 중 일부가 포함되어 있습니다.

사용 가능한 라벨#

Technical Writer가 작업하는 모든 이슈 또는 머지 리퀘스트에는 Technical Writing 라벨이 포함되어야 합니다.

작업 유형을 추가로 분류하려면, 다음 라벨 중 하나 이상을 포함하세요:

  • Category:Docs Site: 문서 웹사이트 인프라 또는 코드. 문서 자체와 관련된 이슈에는 필요하지 않습니다. 이 라벨이 있는 이슈는 Docs Workflow 이슈 보드에 포함됩니다.

  • development guidelines: /developer 디렉터리의 파일.

  • docs-feedback: 문서 피드백 위젯, 설문 verbatim 또는 고객이 생성한 이슈의 피드백.

  • docs-missing: 기능에 대한 문서가 누락됨. 문서는 GitLab 완료 정의의 일부로 특정 마일스톤에 대한 기능 제공과 함께 필요합니다. 이 라벨을 문서가 누락된 원래 기능 MR 또는 이슈에 추가하세요. 이력 추적을 위해 라벨을 유지하고 문서가 완료되면 tw::finished를 사용하여 표시하세요. 실험 기능에는 적용되지 않습니다.

  • documentation: /doc 디렉터리의 파일.

  • global nav: 문서 사이트의 왼쪽 내비게이션. docs-gitlab-com 프로젝트에서 사용됩니다.

  • L10N-docs: Technical Writing 팀의 워크플로 또는 docs.gitlab.com 사이트 및 인프라에 영향을 미치는 현지화 이슈, MR 또는 에픽.

  • release post item: 릴리즈 포스트 항목.

  • Technical Writing Leadership: OKR과 같이 Technical Writing 리더십 팀이 주도하거나 소유하는 작업.

  • tw-lead: Stage 리드 중 한 명이 주도하거나 입력이 필요한 MR.

  • tw-style: 문서 및 UI 텍스트에 대한 스타일 표준.

  • UI text: UI 텍스트 및 오류 메시지와 같은 사용자 대면 텍스트.

기타 문서 라벨에는 vale, docs-only, docs-channel이 포함됩니다. 이 라벨들은 선택 사항입니다.

유형 라벨#

제품의 일부인 프로젝트의 모든 이슈 및 머지 리퀘스트는 작업 유형으로 라벨을 붙여야 합니다. 핸드북 및 마케팅 사이트 변경에는 작업 유형 라벨이 필요하지 않습니다. 이슈 또는 머지 리퀘스트에 다음 라벨 중 하나를 추가하세요:

  • type::feature

  • type::bug

  • type::maintenance

자세한 내용은 작업 유형 분류를 참조하세요.

대부분의 문서 작업은 type::maintenance 라벨을 사용합니다. 유지 관리 작업의 유형을 추가로 분류하기 위해 이 하위 유형 라벨 중 하나를 적용해야 합니다:

  • maintenance::refactor: 기존 문서의 편집 및 개선.

  • maintenance::workflow: 린팅 및 도구 업데이트, 메타데이터 변경과 같이 독자에게 보이지 않는 문서 변경.

예를 들어, CTRT를 위해 페이지를 리팩토링하는 머지 리퀘스트를 열면 type::maintenance와 maintenance::refactor 라벨을 적용하세요. 메타데이터를 수정하는 머지 리퀘스트를 열면 type::maintenance와 maintenance::workflow 라벨을 적용하세요.

워크플로 라벨#

Writer는 이슈 또는 머지 리퀘스트에서 작업 상태를 설명하기 위해 이 라벨들을 사용할 수 있습니다:

  • tw::doing

  • tw::finished

콘텐츠를 작성하는 Technical Writer는 일반적으로 tw::doing 라벨을 추가하고, 검토를 수행하는 Technical Writer는 일반적으로 tw::finished 라벨을 추가합니다. 커뮤니티 기여자의 콘텐츠 제출에 대해서는, Technical Writer가 검토의 일부로 두 라벨을 모두 추가합니다.

워크플로는 다음과 같습니다:

  • 이슈 또는 머지 리퀘스트가 검토를 위해 Writer에게 배정됩니다.

  • Writer는 활발히 작업하는 동안 tw::doing 라벨을 추가합니다.

Writer가 1주일 이상 작업을 중단하면, tw::doing 라벨을 제거합니다.

  • 작업이 재개될 때마다, Writer는 tw::doing 라벨을 다시 추가합니다.

  • 이슈 또는 머지 리퀘스트에 대한 작업이 완료되면, Technical Writer(일반적으로 리뷰어)가 tw::finished 라벨을 추가합니다.

  • 이슈 또는 머지 리퀘스트가 닫히거나 머지됩니다.

tw::finished 라벨은 Writer가 닫거나 머지하지 않는 이슈 또는 머지 리퀘스트에 대한 작업을 완료했음을 나타냅니다. Technical Writing 팀이 닫거나 머지하는 경우, 이슈 또는 머지 리퀘스트 상태가 범위가 지정된 tw 라벨 상태를 재정의합니다. Technical Writer는 tw::finished 라벨을 사용할 필요가 없습니다.

Technical Writer가 추가 작업이 필요한 tw::finished 라벨이 있는 열린 이슈 또는 머지 리퀘스트를 발견하면, Writer는 tw::doing 범위 지정 라벨을 다시 추가해야 합니다.

릴리즈 포스트#

각 Stage 그룹의 Technical Writer는 제품 관리자가 작성한 그룹의 기능 블록(릴리즈 포스트 항목)을 검토합니다.

각 릴리즈에 대해, 단일 Technical Writer가 구조 확인 및 기타 업무를 수행하기 위해 Technical Writing Lead로 배정됩니다.

월간 문서 릴리즈#

새로운 GitLab 버전이 릴리즈되면, Technical Writing 팀은 버전별 게시 문서를 릴리즈합니다.

문서 피드백 및 개선사항#

특정 코드 변경과 관련이 없는 문서 변경을 하려면, Technical Writing 팀은 기여자들이 MR을 생성하도록 권장합니다.

MR 대신 이슈로 시작하는 경우, 문서 템플릿을 사용하세요. 적용해야 하는 라벨에 대해서는 라벨을 참조하세요.

또한 다음을 포함하세요:

  • 마일스톤: 마일스톤에 예약될 때까지 Backlog.

  • 담당자: 마일스톤에 예약될 때까지 None. 인식을 위해 이슈 설명 또는 코멘트에서 그룹에 배정된 Technical Writer를 (@username 형태로) 언급하세요.

  • 설명: Docs: 또는 Docs feedback:으로 시작.

  • MVC 제공을 위한 작업 체크리스트 또는 다음 단계.

  • 선택 사항. 이슈가 커뮤니티 기여자에게 적합한 경우: Seeking community contributions 및 quick win.

이슈가 Technical Writer가 작업을 시작하기 전에 개발 팀의 입력이 필요한 경우, Stage 및 그룹의 이슈 라이프사이클을 따라야 합니다. 이슈 라이프사이클의 예시는 Plan Stage 이슈를 참조하세요.

문서 전용 백로그 이슈 검토 및 분류#

Technical Writer는 이슈 보드를 사용하여 그룹의 문서 피드백 및 개선 이슈를 정기적으로 검토하고 분류합니다. 이를 통해 사용자 경험을 개선하는 실행 가능한 이슈의 우선순위를 정할 수 있습니다.

그룹의 이슈 분류 보드를 생성하려면:

Docs only backlog triage - group name이라는 이슈 보드를 생성하세요.

다음 필터 기준을 입력하세요:

Label=documentation, Label="group::groupname", Label!="type::feature", Label!="type:bug"

Edit board에서 Show the Open list가 선택되어 있는지 확인하세요.

이슈 보드에서 Create list를 선택하고 라벨을 tw:triaged로 설정하세요.

Project Management 그룹의 예시 보드를 참조하세요.

그룹의 문서 피드백 및 개선 이슈를 검토하고 분류하려면:

  • 월 1회, 그룹의 이슈 분류 보드에서 Open 목록에서 새 이슈를 확인하세요.

  • 문서 피드백 및 개선사항에 설명된 라벨을 적용하세요.

  • 열린 미분류 이슈 목록을 10개 미만으로 유지하는 것을 목표로 하세요.

  • 분류된 목록을 그룹 및 그룹 PM과 공유하세요.

Technical Writer 검토 없는 페이지#

/doc/solutions 아래의 문서는 Solutions Architect 팀이 생성, 유지 관리, 편집 및 머지합니다.

해커톤#

Technical Writing 팀은 GitLab 해커톤에 참여하며 때로는 문서 전용 해커톤을 개최합니다.

해커톤을 위한 이슈 생성#

해커톤을 위해 문서 이슈를 자주 생성합니다. 이 이슈들은 일반적으로 문서에 대해 Vale를 실행할 때 발견된 결과를 기반으로 합니다.

전체 문서 세트에 대해 Vale를 실행하세요. GitLab 리포지터리로 이동하여 다음을 실행하세요:

find doc -name '*.md' | sort | xargs vale --minAlertLevel suggestion --output line > ../results.txt

이슈를 생성하세요. 몇 가지 옵션이 있습니다:

스크립트를 사용하여 Vale 결과에 나열된 각 마크다운 파일에 대해 하나의 이슈를 생성하세요. 이 스크립트는 Doc cleanup 이슈 템플릿을 사용합니다.

  • Doc cleanup 이슈 템플릿을 사용하여 이슈를 하나씩 생성하세요.

  • 이슈 API를 사용하여 이슈를 일괄 생성하세요.

이슈에 배정된 라벨이 Doc cleanup 이슈 템플릿의 라벨과 일치하는지 확인하세요.

커뮤니티 기여자에게 이슈 배정#

커뮤니티 기여자에게 이슈를 배정하려면:

  • Seeking community contributions 라벨을 제거하세요.

  • 코멘트에서 /assign @username을 입력하여 사용자를 배정하세요. 여기서 @username은 기여자의 핸들입니다.

  • 코멘트에서 사용자를 언급하여 이슈가 이제 그들에게 배정되었음을 알리세요.

각 기여자당 동시에 세 개 이하의 이슈로 제한하도록 하세요. 이미 배정된 이슈 중 하나에 대해 MR을 열면 다른 이슈를 배정할 수 있습니다.

해커톤 머지 리퀘스트 검토#

커뮤니티 기여자가 해커톤 머지 리퀘스트를 열 때:

관련 이슈를 확인하세요. MR을 작성한 사용자가 이슈에 배정을 요청한 동일한 사용자인지 확인하세요.

이슈에 사용자가 나열되지 않았고, 다른 사용자가 이슈 작업을 요청한 경우, MR을 머지하지 마세요. MR 작성자에게 아직 배정되지 않은 이슈를 찾거나 GitLab 개발에 기여로 안내하세요.

머지 리퀘스트 머지 작업을 수행하세요.

머지할 때 관련 이슈를 닫으세요.

관련 주제#