Tema: collaboration
-
Un día de documentación programado atrae a más contribuyentes primerizos que una convocatoria permanente de ayuda con la documentación
Hipótesis: un proyecto que anuncia un único día con una lista curada de issues de documentación pequeños, mantenedores disponibles para revisar el mismo día y la etiqueta good-first-issue en cada tarea, recibe más cambios de documentación fusionados de personas que nunca habían contribuido que esa misma lista dejada abierta todo el año; una comparación propuesta sobre el propio historial de un proyecto.
-
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.
Legible por máquina: JSON