테크니컬 라이팅 전문 업체인 Expert Support의 CEO입니다. 직원 규모는 50명 이내인데 주로 클라이언트 쪽에서 테크니컬 라이터 프리랜서를 채용해서 프로젝트를 진행하다가 문제가 생기면 연락한다고 하네요. 최근 클라이언트는 리눅스 재단(https://www.linuxfoundation.org/), Cloud Native Computing Foundation (CNCF) 등이라고 합니다.
오늘 세션에서 이야기하고자 하는 프로젝트는 CNCF입니다. 이 프로젝트는 약 170여 개의 오픈소스 프로젝트로 구성되어 있습니다. 쿠버네티스처럼 성공적으로 졸업한 프로젝트는 수많은 자원봉사자들이 문서화에 참여해서 이를 유지하지만 아직 막 성장하고 있는 프로젝트들은 문서화에 많은 지원을 받지 못합니다. 그래서 이를 지원하는 프로세스가 필요했습니다.
몇 가지 지원 정책을 사용했는데 그중 하나가 트레이닝 프로그램입니다(리눅스 재단에서 이미 트레이닝 프로그램을 운영하는 시스템이 있어서 그곳에 콘텐츠만 올렸네요).
LFC111, LFC112 2가지 코스를 사용해서 여러 수준의 테크니컬 라이터 또는 문서 작성자가 프로젝트에 도움이 되는 문서를 작성하도록 지원합니다.
내용이 어렵지 않습니다. 텍스트 기반으로 문서와 간단한 테스트로 구성되어 있습니다. 트레이닝 코스를 만드신 분이 60년대 학번이라고 ~~
Open Source Technical Documentation Essentials (LFC111)
https://training.linuxfoundation.org/training/open-source-technical-documentation-essentials-lfc111/
Creating Effective Documentation for Developers (LFC112)
https://training.linuxfoundation.org/training/creating-effective-documentation-for-developers-lfc112/
문서화를 어느 정도 진행하고 있거나 아예 방향을 잡지 못하는 경우에는 현재 상황을 같이 분석하고 어떤 방향성을 가지고 나가야 할지 조언해 줍니다.
실제 컨설팅 단계에 들어가면 개발팀에서 이런 진단(assessment)을 부담스러워한다고 합니다(Nobody wants a report card라고 표현하네요). 때문에 기존 상태를 수치적으로 평가하지 말고 이후 협력 관계를 만들어가기 위한 기반으로 만들어야 합니다. 그래서 이름을 진단(assessment)에서 분석(analysis)으로 바꾸었다고 합니다.
그리고 처음부터 너무 어려운 과제를 시작하지 말고 쉽고 빠르게 끝낼 수 있는 과제를 선택해서 점차적으로 확대해 가는 것이 좋다고 합니다. 각 작업자에게 일을 할당하는 것도 작은 단위로 역할과 작업을 분배해 주고 지속적으로 멘토링을 지원해 줍니다.
수백 개의 프로젝트를 모두 직접적으로 지원할 수는 없기 때문에 가이드를 제시하고 문서를 작성할 수 있는 자원봉사자들이 자발적으로 참여해서 생태계가 확장할 수 있게 하는 것이 목표입니다.
참고)
실제 프로젝트 문서화를 진단한 자료들도 올려놓았습니다. 약간 템플릿 기반으로 진단하는 것이라 내용이 비슷비슷하긴 합니다.
https://github.com/cncf/techdocs
https://youtu.be/Q4lY_BLJpXE?si=59CL1w36Ws-DS--E
Paul Gustafson
www.flickr.com
