Feedback Solicitation

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A user could not find a known method, and query handling has been repaired. Teaching context is query retry, expected P15 and an empty original result. Feedback should address that failure rather than interrupt every search with surveys.

Mechanism

Complete independent checks first, then present concrete changes and a focused question where feedback can affect next work. Include query/expected/observed results. This fixture asks at most once per session; feedback is voluntary, silence remains unknown and independent technical checks continue.

Bad example

Demand a satisfaction survey after every search, repeatedly ask when unanswered and record silence as satisfaction.

Good example

After repairing retry search, show actual results/checks. If user feedback is useful, offer a short report: query retry, previously empty, expected P15, current results; invite remaining mismatches. Ask at most once in this session and record voluntary feedback only. Do not treat silence as satisfaction or repeatedly interrupt. Keep feedback separate from repair verification.

Why the change matters

Specific failure context makes the change assessable instead of asking broad satisfaction. Useful timing reduces interruption, while separating technical evidence and opinion avoids treating one answer as proof of all behavior.

Observable expectation

The teaching flow shows repair results before one focused request and no repeated reminders. ‘P15 is still missing’ remains an issue to inspect; no answer leaves feedback unknown.

Test passes do not establish acceptance, and acceptance does not replace checks. No automatic bug report is sent.

Limits

The one-request limit is a teaching choice. Necessary requirement questions differ from surveys and should not be omitted when they block action. The source remains unconfirmed; respect storage/privacy scope.