# 16A Reporting Progress Without Mixing Up the Stages

A progress report should explain what has changed and what remains, rather than use one broad word to describe several different stages.
I may have finished editing the page without committing the changes, and a successful commit does not mean that the update is already online.
After the commit, the changes may still need to be pushed to the remote repository before an automatic build can begin.
In some projects, a push to the production branch starts deployment; in others, publishing requires a separate action or approval.
I name the actual stage so that the person reading the report knows which result they can expect to observe now.
For example, I can say that the changes have been pushed but the production deployment is still running and has not completed yet.
If a build fails, I report where it failed and which evidence is available, instead of implying that the entire update has disappeared.
The remaining work may involve correcting a configuration, retrying a build, or checking the published page after the deployment succeeds.
This separation also makes it easier to choose the next action without repeating steps that have already finished successfully.
A useful report ends with the current result, the remaining uncertainty, and the concrete step that will resolve it for this project.