主题： 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