Written by Table of contents
- Keep deliveries small
- Make it easy to validate
- Define acceptance
- Delivering outside a repository
- Before asking for payment
Keep deliveries small
Break work into incremental Pull Requests so validation is faster and risk is lower.
Make it easy to validate
Include in each PR:
- What changed and why
- How to test
- Screenshots for UI changes
Define acceptance
Tie acceptance to objective checks (tests, review approval, and a short manual verification path).
Delivering outside a repository
A Payment Request can cover client work delivered through files, a meeting, or another agreed handoff. Keep a record of the deliverable and the customer’s approval, then describe the completed work clearly in the request. A Pull Request is useful when the work is code, but it is not required for every service.
Before asking for payment
Check the agreed scope, provide access to the deliverable, and resolve outstanding review comments. Then use Charge customers to create a Payment Request. If the work is a funded project issue, follow Work on an issue and the maintainer’s acceptance process instead.
