Work and bug tracking
The team uses the RODENT Sprint board for visible work planning and Gitea pull requests, Actions and commit history for implementation evidence. A task card and a code branch serve different purposes: the card explains the outcome and owner, while the branch contains the reviewable change.
Task flow
The lightweight board uses Work in progress and Done. A task moves to Done only when its acceptance criteria are met and the related code, test, documentation or evidence can be identified.
Each task should record:
- a researcher-facing outcome, not only a file name;
- owner and collaborators;
- acceptance criteria;
- feature branch and pull request;
- tests or manual verification;
- dependencies and blockers;
- client or user feedback that changed it; and
- the final merged commit or deployment.
Bug record
A useful bug report contains:
| Field | Example of the required detail |
|---|---|
| Build | Branch, commit or deployed URL and date. |
| Environment | Browser, operating system, account role and relevant project permissions. |
| Steps | Small numbered sequence that reproduces the problem. |
| Expected | What the researcher should have seen. |
| Actual | Exact message, incorrect state or screenshot. |
| Severity | Blocker, severe, normal or minor, with a reason. |
| Ownership | Person responsible for investigation. |
| Fix evidence | Commit/PR and a regression test where practical. |
| Retest | Who repeated the steps, on which build, and the outcome. |
Security and data-access defects should not expose real emails, passwords, tokens or private experiment data in screenshots. Use dedicated test accounts.
Relationship to GitHub Flow
Card or bug
|
v
Short feature/fix branch
|
v
Tests and documentation
|
v
Pull request and review
|
v
Merge to main
|
v
Deployment/retest evidence
|
v
Done
Direct emergency changes still need a record and retrospective test. A merge alone does not close a deployment bug if the hosted build was not updated.
Submission evidence
For the project rubric, keep an export or screenshots showing real use of the board over time, not only the final Done column. Pair representative cards with their pull requests and tests. Gitea Actions queue problems should be logged as infrastructure issues instead of silently changing a passing workflow until it starts.
AI Attribution: This tracking guide was prepared with OpenAI Codex assistance from the team's stated Trello and GitHub Flow process. Actual task history remains the primary evidence.