Topic: process
-
DACI and RACI for technical decisions: one approver, named contributors
DACI names a driver who runs the decision, a single approver who makes it, contributors who have a voice but no vote, and informed parties who learn the outcome; RACI assigns responsible, accountable, consulted and informed roles to tasks. Either works for technical decisions when the roles are written down before the discussion starts.
-
Technical debt as a deliberate decision with bookkeeping
Cunningham's metaphor treats not-quite-right code as a loan, with every minute of extra work on it as interest. The metaphor only holds if the debt is taken on deliberately, recorded, and reviewed regularly; as a catch-all for anything ugly or an excuse for sloppiness, it is worthless.
-
How to write a usable bug report
A bug report is usable when a stranger can reproduce the bug without asking follow-up questions: a precise title, the environment with versions, numbered steps to reproduce, expected and actual results kept separate, the verbatim error message, and an example that is as small as possible. Guesses about the cause go in a separate section.
-
Tracking postmortem action items to closure: tracking bugs, single owners and ageing review
The Site Reliability Workbook warns that without a formal tracking process, action items from postmortems are often forgotten; give every item a tracking bug, one owner, a type and a priority, review open items by age on a schedule, and treat an item past its date as a decision to make rather than a line to skip.
-
Agile principles as concrete working agreements
The twelve principles behind the Agile Manifesto become useful when translated into checkable team agreements: delivery cadence, direct communication, sustainable pace, technical excellence and regular reflection.
-
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.
-
Handling a data subject request as an engineering process: export and delete
Treat a person's request for a copy or deletion of their data as a job: verified intake, one exporter per store in the data map producing a manifest, delivery through an expiring authenticated download, deletion through the pipeline, exemptions listed with reason codes, and a synthetic-subject test on a fixed cadence; which requests must be honoured and when is not addressed.
-
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.
-
A change calendar and maintenance windows for a small operations team
Put every planned change that can affect users on one shared calendar with an owner, a window, a rollback line and blackout rules; the Google SRE book states that SRE has found roughly 70% of outages to be due to changes in a live system, so 'what changed?' is the first question in any incident and the calendar is where it is answered.
-
Writing a design document (RFC) that reviewers can decide on
A design document secures the decision before any code is written: the problem first, then goals and non-goals, an explanation at user level and at reference level, rejected alternatives with reasons, drawbacks, and an explicit list of open questions. The structure follows what PEP 1, the Rust RFC template and Google's design-doc practice call for.
-
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.
-
Retrospectives that produce changes, not lists
A retrospective justifies its time when it ends with one or two changes that each have an owner, a due date and an observable completion criterion. The Scrum Guide requires that the most impactful improvements be addressed as soon as possible, and the Prime Directive sets the tone in which people name real problems.
-
Blameless postmortems: documenting the timeline, causes and actions
A postmortem describes what happened during an incident, who was affected and for how long, what circumstances made it possible, and which actions make a recurrence less likely. Being blameless is not a courtesy: it is the condition for people reporting facts instead of defending themselves.
-
Designing an on-call rotation and its handover
An on-call rotation needs a primary and a backup, a bounded share of each engineer's time, shift lengths and swap rules that people can plan around, a pager budget that triggers corrective work when exceeded, and a written handover at every shift change; the Google SRE book and PagerDuty's public response documentation describe the constraints.
-
RICE and ICE scoring: what the numbers mean and where they stop
RICE multiplies reach, impact and confidence and divides by effort; ICE drops reach and keeps impact, confidence and ease. Both are useful to make prioritisation arguments explicit and comparable, and both break when the inputs are guesses dressed as numbers or when dependencies and strategy are ignored.
-
Estimating effort as a range with a stated confidence level
Give an estimate as a range (best case, expected value, worst case) plus your confidence that the true value falls inside it. Base the width on the outcomes of comparable past work rather than on the plan, and update the estimate at fixed points. A single number hides the very uncertainty that decisions depend on.
-
Release cadence for a small project: time-based trains versus release-when-ready
A version number says what a release promises; a cadence policy says when releases happen. Rust ships a stable release every six weeks from a nightly, beta, stable train, Python moved to an annual feature release with PEP 602, and Django issues feature releases on a time-based schedule with patch releases as needed. A small project can copy the shape: feature releases on a calendar or when something notable accumulates, patch releases whenever a fix lands.
-
Running a design review: comment period, named decider and a recorded disposition
A proposal review needs a bounded comment period, a named person or group who decides, a written disposition (accept, reject, postpone) with reasons, and a rule for reopening; the Rust RFC process and Python's PEP process show the shape and this methodology adapts it to a single team.
-
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.
-
Acceptance criteria per work item that can be turned into tests
Write each work item's acceptance criteria as concrete examples with a starting state, an action and an observable outcome, using Gherkin's Given/When/Then structure or an equivalent, with the boundary cases named; criteria that cannot be executed or checked by someone other than the author are not criteria.
Machine-readable: JSON