# Feedback and Attribution

Turn reproducible failures into improvement candidates and keep contributions traceable.

## Where criticism can stall

Someone says a rule does not work. You immediately defend it. Someone else shares a useful method, and your retelling drops their name. Both responses remove opportunities to learn together.

## Address the issue, then ask for context

Replies in the research sample are often brief and direct. The useful habit is answering the specific issue before asking about the environment, steps and expected outcome. Forceful wording adds no evidence.

Ask which step failed to produce the expected result. A reproducible failure becomes an improvement candidate. When details are missing, keep the uncertainty visible and request the conditions needed to investigate.

Figure: Ask for a reproducible situation before turning feedback into a change. ([d17-feedback-flow](/diagrams/d17-feedback-flow.en.svg))

> Negative feedback is a gift! Would love to know how to make the skills better.
>
> — Matt Pocock, [source](https://x.com/mattpocockuk/status/2096979934975565862), 2026-09-07

A like, a successful screenshot or one failure does not establish general effectiveness. Record the conditions first, then check whether a proposed change resolves the reported problem.

> **Our inference**
> Our suggestion: retain steps, expected and actual behaviour, environment and recheck results. Investigate the smallest reproducible case before turning one experience into a rule for every task.

## Credit recommendations and adaptations

When recommending a skill, keep its author and original link. When adapting it, identify what you reused and what you changed. MIT reuse also requires the accurate copyright notice and full licence; a thank-you list cannot replace them.

Figure: Credit the original contribution separately from this site's adaptations. ([s17-attribution](/art/s17-attribution.en.svg))

Our original attribution example: the author supplied a handoff structure; this site added a failure-reproduction field and Chinese explanations. Distinguishing those contributions lets readers check the source. See the [copyright page](/en/about-and-copyright) for licence details.

## Revise experiments when evidence changes

The research records a change: after publishing a passive ASD-STE100 instruction, Matt reported that it had not worked. This is a paraphrase of the experiment's outcome, with no additional quotation. The lesson is to update a judgement when evidence changes.

The archived replies mainly cover 2026-04-20 through 2026-10-20; earlier coverage is incomplete. Patterns in that sample cannot represent every reader or his entire history, and cannot validate results in your project.

## Exercise: answer two criticisms

### Leave the discussion a useful next step

- Situation one: someone only says the rule is useless. Request actionable details.
- Situation two: someone provides failure steps. Explain how you will reproduce and report back.
- Credit check: retain the contributor, source and your changes when a suggestion comes from someone else.

Suggested approach: First request the task, steps, expected result and actual result. Then reproduce supplied steps and report reproducibility, scope and recheck results. State when the evidence is still insufficient.

Done means each reply requests or produces evidence without promising an unverified fix. Any retold method remains traceable to its contributor. Take concrete improvements into [decisions and retrospectives](/en/decisions-and-retrospectives).

## Quick reference

- **Respond** Address the specific issue and what is currently known.
- **Verify** Gather context, reproduce and record limits.
- **Attribute** Identify author, link, licence and your changes separately.

## Sources

- [Matt on negative feedback, 2026-09-07](https://x.com/mattpocockuk/status/2096979934975565862)
- [Follow-up on the tone experiment](https://x.com/mattpocockuk/status/2085681281795232026)
- [skills, an entry point for checking authorship and licensing](https://github.com/mattpocock/skills)
- [Site copyright and source notes](/en/about-and-copyright)

Unofficial, non-commercial study notes. No affiliation with or endorsement by Matt Pocock. Quoted works remain their authors’ copyright; MIT reuse retains its copyright and licence notices.

The diagram CSS on this page is adapted from Archify (https://github.com/tt-a1i/archify) under the MIT licence; the complete licence follows.

### Full licence: Archify (tt-a1i/archify)

```text
MIT License

Copyright (c) 2026 tt-a1i (Archify)
Copyright (c) 2025 Cocoon AI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```