- [ ] **Define your issue workflow.**
→ *Decide what columns or states (e.g. “To Do → In Progress → Review → Done”) you will use on your GitLab board or equivalent tool. Document this flow in your README or a wiki page.*
- [ ] **Question:** Who is responsible for moving issues between states?
→ *Write down your team’s convention in the README (e.g. “The assignee moves issues to ‘In Progress’ and the reviewer closes them after merge”).*
- [ ] **Create at least one example issue for each type** (feature, bug, documentation, refactor).
→ *Use consistent labels, assignees, and descriptions so others can copy the pattern.*
- [ ] **Question:** Are issue titles clear and scannable?
→ *Compare a few together — rewrite them if they’re too long or vague. Record a short summary of your naming rule in an issue comment or README note.*
- [ ] **Define what “Done” means.**
→ *Write a short “Definition of Done” (DoD) checklist that covers criteria like code reviewed, tested, merged, and documented. Store it in your repo (`/docs/` or README).*
- [ ] **Question:** Which labels or tags will you use to mark blocked issues, bugs, or dependencies?
→ *Decide on a clear convention (e.g. `blocked`, `bug`, `waiting-for-review`) and test it with one example.*
- [ ] **Plan how to link issues to commits or merge requests.**
→ *Try closing an issue automatically with a commit message like `Fixes #3` and verify it works. Document this habit in your README under “Git & Issue Integration.”*
- [ ] **Review your issue board setup together.**
→ *During class or a team sync, walk through one complete example from creation to closure and note any needed adjustments in an issue labeled “workflow improvement.”*