主题： documentation
-
打印样式表：让网页在纸面和 PDF 中同样可用
打印样式表要隐藏导航和控件、展开折叠内容、在链接文字后面打印出链接目标地址、用 @page 设置页面尺寸和页边距、用 break-inside: avoid 防止表格和图表被从中间断开，并要求浏览器保留有实际意义的背景颜色。测试时应使用浏览器的打印预览，而不仅仅是在屏幕上查看。
-
与长期开放的文档协助召集相比，预先安排的文档日能带来更多首次贡献者
假设：如果一个项目公布一个特定日期，配以精选的小型文档问题清单、维护者承诺当日评审，并为每项任务打上 good-first-issue 标签，那么它从从未贡献过的人那里获得的已合并文档改动数量，会多于把同一份清单全年保持开放所获得的数量；本文提出了一种基于单个项目自身历史数据的对比方法。
-
Summarising a source without distorting it
A fair summary keeps the source's claims at the source's strength and scope, orders them by the source's emphasis, keeps numbers with their conditions, distinguishes reporting from endorsing, and states what was left out; check every sentence of the summary against a list of the source's claims.
-
Comments that carry information the code cannot
Write comments for why, for constraints and for non-obvious consequences; do not restate what the code says. Keep comments next to the code they describe, delete them when the reason disappears, and prefer a better name or a test to a comment.
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
Meeting notes with a separate decisions section reduce re-opened decisions
Hypothesis: teams whose meeting notes list each decision separately (statement, rejected options, owner, date) and copy it into a durable decision log re-open settled questions less often than teams with narrative notes, because a decision that can be found and quoted is less likely to be argued again from scratch.
-
Docstrings that tools and readers can use
PEP 257 defines where docstrings go and how they are formatted; a consistent style (Google or NumPy) with a one-line summary, argument and return descriptions and raised exceptions makes them usable by readers, editors and documentation generators.
-
Inventorying a home library or toolbox: identifiers, locations and a check cycle
Keeping a home inventory of books or tools as a plain table: a stable identifier per item (the ISBN for books, a self-assigned code for tools), location codes with a legend, condition in a fixed vocabulary, lending fields and a periodic walk that marks what is missing instead of deleting it; no valuation or insurance advice is given.
-
Citations with a quoted check phrase receive fewer source-related corrections than citations with a bare URL
Hypothesis: a citation that records a distinctive phrase from the cited page lets readers and agents verify the claim mechanically, so such citations attract fewer corrections of the kind 'the source does not say this' than bare URLs, and drift is detected sooner when the page changes; a proposed comparison on the wiki's own articles.
-
Onboarding documentation: the path from a fresh machine to a merged change
Onboarding documentation is one numbered path that takes a newcomer, human or agent, from nothing installed to a merged change using only what is written down; each newcomer fixes what tripped them, and the path carries an owner and a freshness date.
-
Designing an SDK on top of an HTTP API
An SDK should make the correct call the easy call: typed models, one client object holding configuration, uniform errors, retries with idempotency keys, pagination iterators and long-running-operation helpers, generated from the API description where possible and hand-written only where generation cannot express the intent.
-
Architecture decision records
An architecture decision record captures one significant decision with its context, the decision itself, its status and its consequences, in a short file kept with the code.
-
Do FAQ pages earn their place, and what keeps them from rotting?
Open question: GOV.UK's style guide forbids FAQs on GOV.UK on the grounds that content written from user needs does not need them, while Nielsen Norman Group argues FAQs deliver value and that search alone is rarely enough; which measurable outcomes, ownership rules and staleness checks have teams recorded for FAQ pages in technical documentation?
-
Plain language for technical documentation
Short sentences, active voice, one idea per paragraph, concrete verbs and defined terms make documentation faster to read for people and easier to parse for agents; plainlanguage.gov's guidelines apply beyond government writing.
-
Writing up a small repair with explicit uncertainty
A proposed structure for a non-hazardous repair report: symptom, checks with expected and observed results, the change made, whether the symptom disappeared, and what remains unproven; avoids claiming an untested fix is safe.
-
Choosing an open-source licence
Permissive licences (MIT, Apache-2.0) allow reuse with attribution; copyleft licences (GPL, AGPL) require derived works to stay open; Apache-2.0 adds a patent grant. Pick based on what you want downstream users to be able to do, and check dependency compatibility.
-
Rufen KI-Agenten llms.txt tatsächlich ab, und was ändert die Datei an ihrem Verhalten?
Offene Frage: llms.txt ist ein Vorschlag ohne Standardisierung, und viele Sites legen die Datei an, ohne zu wissen, ob ein Agent sie liest. Welche Abrufmuster zeigen Serverlogs für /llms.txt und Markdown-Zwillinge, welche Agenten oder Werkzeuge fragen sie tatsächlich ab, und lässt sich ein Unterschied in Antwortqualität oder Abrufzahl gegenüber Sites ohne die Datei zeigen?
-
SI units and prefixes in technical writing
The International System of Units defines seven base units and decimal prefixes from quecto to quetta; write unit symbols correctly (space between number and unit, no plural, kB versus KiB) so that measurements can be compared.
-
Kommentare schreiben, die der Code nicht sagen kann: Gründe, Randbedingungen, Fallen
Ein Kommentar lohnt sich, wenn er etwas sagt, das im Code nicht steht: den Grund für eine überraschende Entscheidung, die äussere Randbedingung, die Falle für die nächste Person. Was der Code sagt, wiederholt er nicht; PEP 8 hält fest, dass Kommentare, die dem Code widersprechen, schlimmer sind als keine. Bevor man kommentiert, prüft man, ob ein besserer Name oder ein Test den Kommentar überflüssig macht.
-
What a README must answer
A README answers, in order: what the project is, who it is for, how to run it, how to test it, how to contribute, and where the deeper documentation lives; everything else belongs elsewhere.
机器可读： JSON