A large backlog can create the illusion that a lot of writing is almost finished.
That illusion is useful right up until you try to publish from it.
I had drafts that were real articles sitting beside files that were barely more than reminders to myself. Some had different titles but answered the same question. Some described work I had not actually completed yet. Some were technically accurate but too dependent on private context to survive a public security review. A few looked complete only because they were long.
Reworking that backlog changed my definition of a ready draft.
The important question stopped being, “How many posts are left?”
It became, “Does every surviving draft have a reason to exist?”
A title needs to promise one specific answer
The first problem was overlap.
A backlog tends to grow by accumulation. A thought appears, it gets a filename, then a similar thought appears three weeks later and gets another filename. Both sound useful in isolation. Together, they can become two versions of the same article.
That is especially easy with lessons-learned writing. “Document everything,” “write better notes,” and “make handoff easier” can all collapse into the same generic argument if the article never defines its reader question.
The test I use now is simple:
If I can swap two titles without changing most of the body, at least one draft does not yet have a distinct job.
That does not always mean deleting one. Sometimes the right move is to split the scope more sharply.
One article can focus on public versus private documentation. Another can focus on what a deployment handoff must preserve. Another can focus on why validation belongs in the build process instead of being treated as cleanup.
Those pieces can share a worldview without repeating each other.
That distinction matters for the reader, but it also matters for the site. Cross-linking works better when each article owns a clear piece of the larger system instead of becoming another doorway into the same room.
That is why pieces such as Why I Write Engineering Notes in Public, The Deployment Handoff Checklist I Actually Use, and The Test Matrix I Use Before I Trust a Change can sit next to each other without feeling redundant. They are related, but they are not substitutes.
Planning notes are not implementation evidence
The second problem was more dangerous.
Some drafts described systems that were still mostly intentions.
That is fine for private notes. It is not fine when editing turns future tense into polished certainty.
A sentence like “the recovery process will verify storage before applications start” can become “the recovery process verifies storage before applications start” with one innocent editing pass. The prose gets cleaner while the evidence gets weaker.
That is exactly backwards.
I became much stricter about separating three kinds of material:
- work I completed and can describe as experience;
- work I tested but still consider provisional;
- work I intend to do but have not earned the right to describe as established practice.
The third category still belongs in a backlog. It just should not masquerade as a finished field note.
This changed the articles I chose to publish. A completed backup-readiness review was stronger than a generic article about how backups should work. A real rack-planning exercise was stronger than a hypothetical “future homelab” post. An unresolved incident was more useful when I preserved the uncertainty instead of inventing a satisfying ending.
The result is less polished mythology and more engineering evidence.
Security review starts before the final paragraph
A technical article can be free of passwords and still reveal too much.
That became obvious once I started reviewing drafts as complete artifacts instead of just prose.
Sensitive information can hide in filenames, diagram labels, alt text, screenshots, code comments, internal paths, example URLs, service names, account identifiers, exact topology descriptions, and references to physical placement that add no technical value.
Removing a hostname from the body is not enough if the same hostname remains in a screenshot caption.
The stronger approach is to write around roles from the beginning.
“Application host” is often more useful than a pet hostname. “Storage host” is more reusable than a machine name. “Management network” communicates the boundary without publishing an address range. “Private service URL” teaches the design without disclosing the actual domain.
This is not only safer. It usually makes the article better.
A reader can apply a role-based explanation to their own environment. A story built around my exact identifiers is easier to reconstruct but harder to reuse.
That same principle is why What Goes in Public Documentation, and What Stays Private separates private operational records from public explanations. The private version can preserve the exact information needed to recover a system. The public version should preserve the architecture and the lesson.
Those are different documents with different obligations.
Length is a weak proxy for readiness
One of the easiest backlog traps is trying to make every draft “big enough.”
That usually leads to filler.
A short article can be complete if it answers a narrow question with evidence, boundaries, and a useful conclusion. A long article can still be unfinished if half of its sections exist only because the outline looked impressive.
The better readiness test is whether the article has enough structure to stand on its own.
For me, that usually means the piece has a clear problem, enough context to understand why it mattered, a decision or boundary, evidence from something actually observed or completed, what changed or became clearer, a practical takeaway, and enough cross-linking to show where the article fits in the larger body of work.
Not every field note needs every element. The point is that word count does not substitute for any of them.
This also helped me stop comparing focused field notes to the site’s long definitive guides. A guide has to teach a system from several angles. A field note often has one job.
If that job is complete, adding three more sections can make it worse.
Continuity is more useful than chronology
The numbered backlog originally implied a sequence that mattered more to me than it did to the reader.
Once I started restructuring the site, I realized continuity did not require every article to behave like a chapter in a book.
It required each article to know what problem had already been solved elsewhere.
The homelab pieces work better when one article owns storage dependency behavior, another owns application-host replaceability, and another owns missing-mount failure modes. The Windows pieces work better when repair boundaries, evidence preservation, repeatable validation, and handoff each have their own place.
The sequence still exists, but the links carry more value than the numbers.
That is a healthier model for a field-notes site because readers rarely arrive at article one and read straight through. They arrive through search, a link, or one specific problem.
Every article should therefore work alone and also make the next useful question obvious.
”Ready” and “published” are separate states
This distinction became one of the most useful outcomes of the backlog cleanup.
A draft can be ready without being published.
That means the argument is complete, the privacy pass is clean, the cross-links make sense, the claims are supported, and the piece would survive a final editorial review. It does not mean the article should automatically go live.
There are still publication-time checks.
Technical guides may need a fresh documentation review because image names, supported versions, command syntax, defaults, or product behavior can change. Security-sensitive walkthroughs deserve one more check for leaked identifiers. A post may also need to wait because another article already covers too much of the same territory that week.
The repository itself enforces part of this separation. The Astro content loader excludes the drafts directory from production, while published content must satisfy the publication-date schema. That is the right kind of friction: drafts remain available for editorial work without becoming accidental production pages.
The important lesson is conceptual, though.
A backlog should create options, not pressure.
If nothing is good enough today, the correct publishing decision can be to publish nothing.
What I would change if I rebuilt the backlog from zero
I would require one sentence at the top of every new seed note:
This article answers: ________.
That one line would have prevented a surprising amount of cleanup.
It would have exposed duplicate ideas sooner. It would have made speculative notes easier to recognize. It would have shown when a “topic” was actually three separate articles. It would also have made deletion less emotional because a draft without a distinct answer would have failed its purpose test early.
I would also label evidence state at creation time.
Something as simple as “completed,” “tested,” “planned,” or “unresolved” would make later editorial work safer. The writing could evolve without losing track of how much certainty the underlying work actually earned.
Finally, I would treat privacy as part of structure, not a cleanup phase. Generic role names, sanitized examples, and public-safe diagrams are easier to maintain when they are designed that way from the first draft.
Finishing is an editorial decision
The backlog cleanup taught me that finishing is not the act of reducing a counter to zero.
It is deciding what deserves to remain distinct, what should merge, what should stay private, what needs more evidence, and what is actually ready to represent the work in public.
That is slower than counting drafts.
It is also much more useful.
A healthy backlog is not a warehouse full of almost-articles. It is a set of defensible choices.
When I can look at each file and explain why that article exists, who it helps, what evidence supports it, and what it deliberately leaves out, the backlog is finally doing its job.
AI transparency
AI assisted with inventorying, restructuring, editing, sanitization checks, and comparison across overlapping drafts. The editorial decisions, project history, and publication standards described here are grounded in the actual Field Notes workflow and repository structure.