Squads

CHT Squads

How community squads work

What is a squad?

A CHT Squad is a cross-functional, action-oriented team that works together to solve community needs. These teams bring together developers, designers, project managers, and other contributors to build and implement new features and improvements for the CHT.

When a community-proposed improvement shows potential for broad impact, we invite the wider community to collaborate. Members can express interest in contributing to discussions, design, development, testing and/or funding. Below are the characteristics of how a squad works:

  • Collaborative by design: Anyone can join - whether you are an experienced community contributor or just getting started with the CHT
  • Transparent process: Regular meetings and shared public notes and documentation to keep everyone informed
  • Flexible contributions: Help in whatever way works for you - coding, design, testing, or documentation.

Why join a squad?

  • Work on meaningful projects that make a real difference
  • Learn from and collaborate with other community members
  • Help shape the future of the CHT

Where to find active squads?

See the active squads on the CHT roadmap and subscribe to the CHT calendar to stay up to date with all the CHT events, including the regular squad meetings.

How to start a squad?

If you are interested in forming a squad, here are the steps to follow:

  1. Post on the forum to identify other interested members. Share details about the topic/feature to be explored in the squad and connect with other interested community members.
  2. Reach out to specific community members who have previously discussed the topic or who you think may be interested.
  3. Reach out to the CHT Stewardship Team to allocate dedicated time during Round-up calls for sharing the initiative with the broader community.

Kick off

  • Once the squad members have a start date, organise a public, open kick off meeting with all community members interested in contributing to the initiative. The agenda for this meeting should include:
    • Introductions and role clarity.
    • Overview of squad objectives and desired outcomes.
    • Alignment on squad scope.
    • Initial task assignments.
    • Agreement on a recurring meeting cadence (for example, weekly/biweekly calls).
  • Reach out to the CHT Stewardship Team to create a dedicated Slack channel for squad discussion. If Slack doesn’t suit for whatever reason, any other shared comms channel would be fine.
  • Invite others in advisory roles, as for example domain experts, UX experts. Clarify their involvement (for example, periodic reviews, feedback sessions) even if they are not full-time contributors. Any expertise is invaluable for reviews, sharing advice, etc.

What are the different stages in a squad?

Squads evolve through stages, and anyone can start contributing at any stage - no matter their experience level. Here are the various stages:

1. ✨ Emerging

A need sparks! The community identifies a feature or improvement with broad potential.

Outputs:

  • A squad kick off message is shared on the forum
  • Community members volunteer to participate in the squad
  • The Code of Conduct is shared with all squad members.
  • A squad kick off call is scheduled with the interested contributors.

2. 🧑🏼‍🎨 Early Design Discussion

Teams explore technical requirements, timelines, and design approaches.

Outputs:

  • The first output of early discussions should be a needs and requirements document. The squad members should align on what’s in scope and what’s out of scope of the project and identify how success should look like for the initiative.
  • Resource commitments - identify which contributor works on which part of the project.

3. 💡 Requirements & Design

Turning ideas into action.

Outputs:

  • The squad should collaboratively work on a design document based on the requirements. Once the first iteration is complete, pause to incorporate feedback by announcing it on the forum for broad community review before proceeding.
  • If needed, UI mockups are created.

4. 🧑🏽‍💻 Development/Building

Once the design doc is accepted, development can begin. If multiple orgs are codeveloping the functionality, then agree on a single communal branch/workspace for the developers to contribute to. Ensure work is pushed to the public repositories early and often. Ensure coding best practices are being followed, such as automated testing, code quality, and documentation. Ensure manual testing is happening throughout to find issues early.

Output:

  • Working software

5. 📲 Testing

Ensuring quality. Rigorous manual/automated testing verifies functionality.

Outputs:

  • Test reports
  • Verified software

6. 🛋️ Review

When the squad confirms that the solution meets the requirements, submit a pull request for code review. Nominate a CHT maintainer to work on the review. Post the PR and instructions on how to run it, on the forum so other community members can try it out. After passing both technical review and allowing a few days for community feedback, merge the approved code.

Outputs:

  • PR posted with testing instructions in the forum for community validation.
  • Merged contribution with documented community input.

7. 💪🏼 Release

The functionality is released and ready to create an impact in the real world. Features can be deployed to users.

Output:

  • Software release

8. ✅ Done

Mission accomplished. The project meets all goals and the related tasks are marked complete.

The most important thing now is to recognise the efforts of everyone involved in this process. This cannot be understated. Do this loudly, repeatedly, in private, and in public, calling out specific people and organisations.

To close out the squad, undo all the set up that was done in Kick Off:

  • Remove the meeting from the shared Google calendar so it does not show up on the public Events Calendar
  • Archive the dedicated Slack channel - Stewardship team can help with this
  • Clean up GitHub tickets - make sure all releated tickets are closed and up to date
  • Hold a final meeting to thank everyone and have a retrospective to ask “What worked?”, “What didn’t work? and “What could be changed/improved?”. Implement improvements to make this process better next time.
Last updated on

Did this documentation help you ?