Revisiting our communication strategy & style 🦑

Hello :wave:

After our most recent Team Week (a week for goal-setting and roadmapping that we have every four months), we decided to revisit our communication strategy and style to more accurately reflect our values and principles.

With this exercise, we decided to make it an objective to establish an open development process and style. We’ll be mainly doing so through but I also wanted to put some time into reframing some of our other objectives as well for reference on how we’ve thought through this.

The way I’ve categorized our communication channels is inspired by a FOSDEM talk I saw by Matthew Broberg. By categorizing our communication channels by different categories (Sync, Async, News, F2F) we’re able to keep ourselves organized, which gives us more time to focus on making our communications accessible and transparent.

This is only a starting point - I’m excited to see how it develops! Thoughts and feedback always appreciated.

:sparkles: Our Principles

Our strategy is to communicate openly and transparently regarding our internal, product, and engineering development by sharing progress, decisions-making processes, and proposals through our async communication channels.

Whenever we communicate something internally or make a decision we should ask ourselves: would this be interesting, relevant, or appreciated by our community? If so, we should:

  • Clearly and proactively communicate outcomes & decisions as they are made
  • Elaborate on decision-making processes (how a decision was made, by who, and why)
  • Provide the space for contribution and conversation (gather insights from community, present questions in discussions, and be open and responsive to feedback & discussion)

Bi-weekly Development Updates

Every two weeks, we share a formal development update on Discourse, IRC, SSB, and the mailing list. These development updates are sourced from all project teams and share larger pieces of work/progress, highlight active discussions/work, and communicate outcomes. We can think of it as a public debrief of our own bi-weekly meetings.

Our “Third Place”:

To provide a clear gateway into the project, we try to present all communications on our community Discourse channel, This includes:

  • :hammer_and_wrench: Engineering decisions & process (proposals, best practices, decisions, progress)

  • :space_invader: Product development (roadmaps, designs, feature specs)

  • :handshake: Project-wide decisions (how we work, governance, partnerships)


Discourse discussions are open-ended without a structured format. The way the post is written is up to the creator. The only guidelines are:

  • :seedling: Follow the principles! Make sure to present a comprehensive view of the topic that gives readers background & context.

  • :bowing_woman:Make an active effort to engage the community! Present questions, seek feedback, or ask for advice from community members.

  • :man_dancing:t3:Involve the team! Tag team members and contributors who are involved in the process, have them way in, or answer your questions publicly. It’s super cool to see people collaborating openly.


#development: for public cross-team engineering discussions on engineering progress, challenges, and decisions.

#product: for UI/UX discussions and user research debriefs

#announcements: for official cross-team bi-weekly development updates (also shared to the radicle mailing list), project announcements, releases, and launches.

#general: for general discussions & questions

Where do we communicate?

Frame (5)


for casual, high-throughput discussion

→ IRC: #radicle

→ Twitter: @radicle_xyz & @monadic_xyz


for a definitive, recorded answer

→ Discourse: :seedling:


→ Websites: &


To stay informed and empowered

→ Twitter: @radicle_xyz & @monadic_xyz

→ mailing list

→ SSB: #radicle-weekly-updates


face-to-face time to build a formidable bond