Skip to content

The feedback process

Most teams have too many feedback channels: Slack, email, hallway, retro, the comments field, JIRA tickets, a Google Doc that one person opened nine months ago. The result is the same as having no channel — feedback gets lost, ignored, or relitigated.

dooer takes a different position. Feedback is a first-class object with its own lifecycle, its own register, and its own constraints. This page explains what that actually means and how to use it.

The model

A Feedback row in dooer has these key fields:

  • work_item_id — every feedback is attached to one task. There is no free-floating "team feedback."
  • author_user_id — who wrote it.
  • message — the actual content.
  • status — one of: Pending / Approved / Rejected.
  • created_at, updated_at — timestamps for the audit trail.

The unique constraint that changes everything

There is a database-level rule: one Pending feedback per task per author.

In plain language: you cannot pile up 12 different "things to think about" on the same task as the same person. You get one open thread until it's resolved. If you want to raise a second point, you have to first decide what to do with the first one.

This single constraint is the reason dooer's feedback works where most "feedback inboxes" fail. It forces you to close the loop before you open a new one. (See Capture, organize, reflect.)

The lifecycle

                    Pending
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
   Approved        Rejected       Convert to Task
   (resolved)    (not actionable) (spawns new work)

Pending is the starting state. Anyone with access to the task can add feedback, and it lands here. It shows up in: - The Feedback tab on the task detail. - The Feedback Register on the project the task belongs to. - The task owner's notification bell (if the feedback type triggers notifications).

Approved means we read it, we agree, action taken (or the issue resolved itself). The feedback stays visible in the registers as a closed item — part of the lessons-learned record.

Rejected means we read it, we disagree, no action. Rejection is not dismissal — write a short reason in a comment so the author can see the thinking. A rejected feedback teaches just as much as an approved one.

Convert to Task is the special path. When feedback represents real action that doesn't fit on the current task, hit the Convert button. dooer spawns a new WorkItem with:

  • origin = feedback — so you can trace the new task back to its source.
  • The author of the feedback as the new task's original_assigner.
  • The feedback itself moves to Approved.

This is the most powerful flow in the entire model. It turns a one-line complaint into a tracked, assigned, audited piece of work — with zero copy-paste.

When to use feedback vs comment vs new task

This is the single most common confusion. Use this matrix:

Situation Use
"I have a thought about how this could be better" Feedback
"The estimate is wrong" Feedback (effort type) → triggers effort-revision flow
"We should also do X as part of this" Feedback → likely Convert to Task
"Hey @teammate, can you take a look?" Comment (fires notifications to watchers)
"Here's the status update for stakeholders" Comment
"Let me clarify what I meant in the brief" Edit the brief (creates an audit log row), then comment briefly
"Different work, related to this one" New task with a predecessor link
"Different work, completely unrelated" New task standalone

The dividing line: feedback evaluates the work, comments discuss the work, new tasks create more work.

If you find yourself writing the same kind of comment over and over ("the date isn't right", "this is more effort than expected"), you are using comments where feedback belongs.

Feedback at three scales

On a single task (the small loop)

  1. Someone reviews a task — yours or someone else's.
  2. They notice something — effort is off, brief is unclear, scope changed, blocker missed.
  3. They click Add Feedback on the task.
  4. The task's owner gets a notification.
  5. The owner reads it, makes a decision, either acts (approve) or explains why not (reject + comment).

This loop should close within 48 hours. If feedback sits Pending for over a week, the system is broken.

Across a project (the register)

The Project Detail page has a Feedback tab. This tab shows every open feedback across every task in that project. Use it as your lessons learned register (PMBOK 7, PMI 2021).

The pattern at this scale:

  • Daily skim — walk the open feedback for active projects. Identify anything that's been Pending more than 48 hours.
  • Weekly close — pick the top 3 oldest. Close them. Document the resolution.
  • Monthly review — what types of feedback keep recurring? That pattern is telling you something about how the project is being run.

Across the workspace (the export)

Once a quarter, Export Feedback to XLSX. Now you have a flat table of every piece of feedback across the workspace. Pivot by:

  • Most-feedback-receiving tasks — these are your hot spots.
  • Average resolution time — your "feedback velocity."
  • Approved vs rejected ratio — too many rejections means the team isn't aligned on what good looks like. Too many approvals with no rejections often means people are being polite, not honest.

Why dooer doesn't have free-form team feedback

You might wonder: what about feedback that's not about a task? "I think our standup is too long." "The new project naming convention is confusing."

dooer's position: that's a retrospective topic, not a feedback object. Capture it in a retrospective meeting (see Retrospectives) — that's where multi-person, no-single-task feedback belongs. The meeting decision becomes the record. If action is needed, the decision spawns a task. From there, the new task can carry feedback the normal way.

This isn't a limitation. It's a design choice: keep feedback attached to concrete things you can change. Free-form feedback is where good ideas go to die.

How feedback connects to gamification

Feedback events do not award dooer_points directly. Points are a throughput signal — how much work you ship. Feedback is a quality signal — how much you improve.

What feedback does affect, indirectly:

  • A task with feedback that gets converted into a new task counts as throughput when that new task closes.
  • The Feedback Register burndown is a leading indicator (see Leading vs lagging) — a team with a healthy feedback velocity tends to ship more reliably.

The two metrics are complementary. Optimizing only for points means you'd ship a lot of low-quality work. Optimizing only for feedback closure means you'd never ship.

Where to read more

  • PMI (2021). PMBOK Guide, 7th Edition. Performance domain #5: Project Work. Lessons learned register.
  • Kerth, N. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House. The retrospective discipline that complements task-level feedback.
  • Edmondson, A. (2018). The Fearless Organization. Wiley. Why your team won't write honest feedback unless safety is real. See Psychological safety.
  • Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Free, scrumguides.org. Sprint review + retrospective as the parent cadences for task-level feedback.

← Estimation | Next: Retrospectives →