Plan Your Collaboration Strategy
For both the host team and the contributing team
Use this checklist to prepare your joint work.
The shared issue is always the single source of truth — every agreement, plan, or update must appear there.
- copy the checklists below into the chosen issue as separate comments,
- both teams go through each section together,
- check off each item as you agree on it, and add the requested notes directly in the issue.
Understanding & Scoping
| - [ ] Read the issue carefully and confirm you both understand the goal.
→ Log your shared understanding as an **issue comment**.
- [ ] Identify any open questions or ambiguous parts.
→ Add them as **clarifying questions in the issue**.
- [ ] Agree on the exact acceptance criteria (what “done” means).
→ Document this in an **updated issue description or comment**.
- [ ] Check whether extra context (API, UI mock, sample data) is needed.
→ Attach or link these resources directly **in the issue**.
|
Roles, Responsibilities & Boundaries
| - [ ] Decide who does what: contributor tasks vs. host support duties.
→ Add a short **responsibility list in the issue**.
- [ ] Confirm communication channels (issue comments, email, quick calls).
→ Record this as a **communication note in the issue**.
- [ ] Agree on how and when the host team will review work.
→ Add a **review plan** as an issue comment.
|
Technical Plan
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | - [ ] Identify the affected modules or files.
→ Add a **technical note** in the issue describing the impact area.
- [ ] Decide branch naming: e.g. `collab/<teamA>-<teamB>-<feature>`.
→ Write the chosen pattern in the **issue**.
- [ ] Plan how to run and test the project locally on both sides.
→ Add setup notes to the **repository README or wiki** and link them in the issue.
- [ ] Agree on commit message style and reference pattern (e.g., “Fixes #12”).
→ Document the rule in the **issue**.
- [ ] Check compatibility: Python version, dependencies, formatting tools.
→ Summarize the checks in an **issue comment**.
|
Professionalism & Sentiment
| - [ ] Decide how to give feedback respectfully (facts first, intentions clear).
→ Add a short **collaboration etiquette** to the issue.
- [ ] Agree on tone: neutral, helpful, and curiosity-driven.
→ Teams confirm this by adding a **reaction or brief acknowledgment**.
- [ ] Check expectations about response times (e.g., 24–48h).
→ Write this as a **service expectation** in the issue.
- [ ] Set a simple plan for resolving disagreements (ask clarifying questions → propose options → escalate to tutor if needed).
→ Add this as a **conflict-resolution note** in the issue.
|
Progress Tracking
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | - [ ] List the concrete next steps (mini-tasks).
→ Add a **task list inside the issue description**.
- [ ] Log every significant decision as an issue comment, not in private chat.
→ Follow this throughout the collaboration.
- [ ] Share intermediate progress: screenshots, test results, partial code.
→ Attach updates directly **in the issue comments**.
- [ ] Host team reviews and adds “OK” or requested changes.
→ Track this in **merge request comments**, linked from the issue.
- [ ] Contributor updates the issue status when something is finished.
→ Use **labels** or a short comment (“Step X completed”).
|
Wrapping Up
| - [ ] Confirm all acceptance criteria are met.
→ Record final verification in the **issue**.
- [ ] Provide a short reflection from both teams (what went well, what you learned).
→ Add this as a **closing comment in the issue**, signed by both teams.
- [ ] Close the issue only when both sides agree.
→ Contributor or host team closes it, based on prior agreement.
|