Тема: 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