Writing issues and pull requests

An issue is not simply a reminder that something is wrong. It should allow someone else to reproduce or understand the problem and recognize a successful result. A pull request then explains the proposed change and collects verification evidence.

A useful bug report

Title: Reconnecting duplicates equipped items
Expected: One item per server ID after any reconnect.
Actual: The same item appears twice after a repeated snapshot.
Reproduction: Connect, equip item, disconnect, reconnect twice.
Environment: Development build, test backend.
Acceptance: Automated reconnect test stays green.

Remove account secrets, access tokens and personal data from logs before attaching them. Avoid turning a description into an unstructured collection of screenshots without text.

A useful pull request description

State the linked issue, the root cause, the proposed change, test commands and results, risks and any migration or rollback requirements. The review should focus on behavior and maintainability, not personality. For a user-facing change, screenshots may support the description but do not replace a testable acceptance criterion.

Connect the work

Where supported, reference the issue from the branch or PR. Track whether checks passed, whether review is complete and whether the deployed commit is actually active. A completed project card is not the same as a successful production deployment.

See GitHub issues, pull requests and README writing.