Every issue tracker I have used has some version of Backlog, In Progress, Done. Not one of them ships a place to prepare a task in private before other people can see it.
That missing state causes a specific, recognisable mess, and once you notice it you see it everywhere.
The mess
Somebody has an idea. The only way to record it is to create a ticket. Creating a ticket puts it on the board. Being on the board means it is now a thing the team can see, comment on, estimate, and start.
So a half-formed thought becomes a work item in one step, and then the work item becomes the argument. You have all had the ticket with eleven comments where the first four are people asking what it means, the next four are scope negotiation, and the last three are somebody who already started building the wrong version.
None of that is a communication problem. It is a missing lifecycle stage.
Two jobs that are not the same job
Capturing an idea and preparing a task are different activities with different requirements.
Capturing wants to be as cheap as possible. Any friction here and people stop recording things, which is strictly worse. One line, no fields, no estimate, no owner.
Preparing is the expensive part. It means deciding the scope, writing down what would make the result acceptable, attaching the context somebody would otherwise have to come and ask you for, and - most importantly - deciding whether the thing is worth doing at all.
If those share one state, capturing inherits preparation's friction, or preparation gets skipped. Usually both.
Preparation is cheap in private and expensive in public
This is the bit that convinced me. The same edit costs radically different amounts depending on whether anyone is watching.
Rewriting the scope of a private draft costs nothing. Rewriting the scope of a published ticket means notifying whoever commented, correcting whoever started, and re-litigating whatever was already negotiated. Same keystrokes, ten times the cost.
So the natural consequence of having no private stage is that tasks get published under-prepared and then never properly fixed, because fixing them in public is too expensive.
Publishing as an actual gate
The other thing you get from a real draft state is that publishing becomes a signal.
When someone deliberately moves a task from draft to the board, they are asserting something: this is ready to put in front of another person. That assertion is genuinely useful information. On a board where everything is published by default, no item carries it, and every item has to be independently assessed for whether it is real.
I would go further: nothing should be able to leave the draft state without a written acceptance check. Not as a process ritual - as the definition of prepared.
If your tracker cannot do this
Most cannot, so approximate it:
- Add a Draft or Not Ready label and treat items carrying it as invisible. No estimating, no starting, no commenting beyond the author.
- Default new items to it. The gate only works if passing through it is deliberate.
- Make the exit criterion explicit and boring: scope, acceptance check, context attached.
- Keep capture separate and frictionless. A one-line note that becomes a draft later is fine. A one-line note that becomes a ticket immediately is the problem.
The convention is weaker than a real state because nothing enforces it, but it recovers most of the value.
Wagglet's walkthrough of its full workflow is the most explicit version of this I have seen implemented rather than described - a rough request, a private Draft used as a preparation room, then a deliberate publish onto the board, and separate stages after that for claiming, delivering evidence, and a reviewer choosing among genuinely different verdicts. It looks longer on paper. That is rather the point: the stages were always there, they were just happening implicitly inside one column and one comment thread.
