Reviews and quality

Corrections of delivered work

Give feedback on something Yavaren delivered, review how it will be corrected, and accept or reject the correction.

When a draft pull request, tests, a fix, an update, a brief, features, stories, a plan or release notes are not right, say what should change. Open the delivered job under Build › Hand over work and choose Give feedback on this work, or see every round under Build › Corrections.

Giving feedback

Write what should change in your own words, and add points if you can: what kind of problem, how serious, and the file and line. Yavaren treats your feedback as information about the work, never as instructions to obey.

The correction strategy

Yavaren works out why the work went wrong and lays out what it will do, which checks it adds, and which of your rules and lessons it follows. Depending on your organisation's policy a member reviews it first: Approve and correct, Edit the strategy, or Cancel this round. An admin sets the policy under Build › Corrections › Policy (always, only high-risk, never), and can ask for another member to approve.

The correction

Code and tests are corrected on the same draft pull request: one more commit and one comment that answers each point. Nothing is merged; the pull request stays yours to review. Unit tests are corrected in test files only. A brief, features, stories and plans come back as a new version for approval; release notes are corrected by your release managers.

Accepting or rejecting

Accept the correction, or choose Not right yet, say what is still wrong, and the next round starts. After the number of rounds your plan allows, Yavaren support takes the item over.

What Yavaren learns

Why work needed correcting becomes a lesson for the next jobs in your organisation. Across organisations only counts and fixed text are used, never your feedback; an admin can switch that off.