How should a team handle comments that need a response in a shared document?
Quick answer
Agree on a few labels and use them consistently: flag comments that need a reply, name one person responsible for answering, and define when a thread is resolved. The responder should post the outcome and note any resulting edit. Resolve a thread only after its question is answered and needed action is complete; if it no longer applies, explain why before closing it.
The question, the details, the next step.
Our shared document has comments from several people, and it is hard to tell which ones need an answer. What convention should we agree on?
Keep the convention short: agree on how to flag comments needing a response, how to identify the responder, and what to do when a thread is finished.
For example, write “QUESTION — [name] — should this heading stay?” when a specific person needs to decide something. Use “SUGGESTION” for an optional improvement or “ISSUE” for a possible problem, if those labels help. They are plain-text suggestions, not special features; use the document’s existing comment tools.
Name one responder whenever possible. If several people are tagged without an owner, each may assume someone else will reply. For a group decision, name a coordinator to gather views and post the outcome. Include a response date only when it helps the work.
What should the person assigned to a comment write, and how do we show that it has been handled?
Answer directly in the thread, then state what changed or why no change was made. If the answer leads to an edit, make it in the document and briefly point to the result.
For example, on a draft agenda someone asks, “QUESTION — [editor] — should this item come before the budget update?” The reply could be: “Yes. I moved it above the budget update so the decision comes first.” Then mark the thread resolved using the document’s usual controls. If there is no resolution control, agree to reply “RESOLVED — [short outcome]” instead.
Reserve “resolved” for a question that has an answer and any needed action is done. If a comment no longer applies—for example, its passage was removed—explain that before closing it. A reaction or unrelated edit does not resolve the question.
What if the comment is vague, has no obvious owner, or asks for something the team has not decided yet?
Ask for clarification rather than guessing: “Which paragraph are you referring to, and what outcome would you like?” If there is no clear owner, ask the document owner or coordinator to assign one person to post the answer or status.
For an undecided issue, make the status explicit: “Decision pending — [name] will confirm [choice] by [date].” If no date fits, name the event or input the team is waiting for. Once decided, post the outcome and any edit, then resolve the thread. If the issue is outside the document’s agreed scope, identify who should decide it.
Can you give me a short convention we can paste at the top of a document, plus a practical way to review open comments?
Here is a starting point; adapt the labels and timing to your team:
“Comment convention
- Start comments needing a reply with QUESTION and name one responder: ‘QUESTION — [name] — [specific question].’
- Use SUGGESTION for an optional improvement and ISSUE for a possible problem. Say whether a reply is needed.
- The responder posts the answer and any action in the thread. Put decisions that change the document in the document itself.
- Resolve a thread only when its question is answered and needed action is complete. If it no longer applies, explain why before closing it.
- For a pending decision, write ‘Decision pending — [owner] — [next step or date].’”
At an agreed review point, scan open threads. For each, check whether the request is clear, an owner is named, action remains, or something is pending. Then assign an owner, ask for clarification, record the next step, or answer and close it.
A practical checklist
Agree on a few labels and say which comments need a reply.
Name one responder for each question or pending decision.
Ask for clarification when a comment is vague.
Reply with the outcome and record resulting decisions or edits in the document.
Resolve a thread only when its action is complete; explain if it no longer applies.
Review open threads at an agreed checkpoint and give each a next step.
A few more useful answers
Should every comment be labeled?
Not necessarily. Labels are most useful for comments needing a reply, decision, or follow-up. Keep observations that need no action simple.
What if someone disagrees with the response?
Reply in the same thread with the point of disagreement and the decision needed. Identify who will decide or coordinate it, and keep the thread open until the outcome and any required edit are recorded.
Should a team set a response deadline?
Set one when timing affects the work and state it in the comment. If timing depends on another input, name the next checkpoint or dependency instead.