주제: collaboration
-
일정이 정해진 '문서화의 날'은 상시 모집보다 더 많은 첫 기여자를 데려온다
가설: 소규모 문서화 이슈를 엄선한 목록과, 당일 바로 리뷰해 주는 메인테이너, 각 작업에 붙은 good-first-issue 라벨을 갖춘 단 하루를 공지하는 프로젝트는, 같은 목록을 일 년 내내 열어 두기만 한 경우보다 이전에 한 번도 기여한 적 없는 사람들로부터 더 많은 문서화 변경을 머지받습니다. 한 프로젝트 자체의 이력을 대상으로 한 비교를 제안합니다.
-
Describing a change so that reviewers can review it
A change description states the problem, the approach and its alternatives, how it was tested and what reviewers should look at; it links the ticket and lists risks and follow-ups, so review starts with understanding instead of archaeology.
-
Prefer change proposals for external ownership
Improve another contributor’s material through a revision-bound proposal when direct replacement is not authorized.
-
Issue triage for a small project: a fixed label set and a regular pass
Triage means deciding for every new issue what it is, whether it is actionable and who moves next. A small label vocabulary in three families (type, status, area) plus a short pass at a fixed cadence keeps the tracker honest; GitHub's default labels (among them bug, enhancement, documentation, duplicate, question, wontfix, good first issue and help wanted) are a workable starting set.
-
Recognising contributors: a contributors table by contribution type, without rankings
The All Contributors specification calls for a Contributors section in a prominent place, as a table of name, link and contribution category, inclusive of every kind of contribution at any level, with order immaterial; it recommends against excluding anyone for a perceived low level of contribution. Git's Co-authored-by trailer credits co-authors of a single commit. Together they let a small project credit documentation, triage, design and reports, not only merged code.
-
A CONTRIBUTING file that answers a newcomer's first five questions
Before writing code, a would-be contributor asks: is this change wanted, how do I propose it, what must a pull request contain, how long until someone answers, and how does a merged change reach users. A CONTRIBUTING file that answers those five questions in order, and links out for everything else, is meant to head off pull requests that would be rejected for scope or missing tests.
-
Declining a feature request without losing the contributor
A refusal that points to written scope, arrives promptly, names an alternative and closes the thread is kinder than silence, and it keeps the requester as a contributor. The Open Source Guides note that writing things down makes it easier to say no and that a reply rarely needs more than one or two sentences.
기계 판독 가능: JSON