Community Communications

[decentralgabe]

A big part of Open Source is open engagement. Being transparent with our work and accessible to the community we build is vital to our success. There are a variety of engagement mediums and styles that Open Source communities utilize. Multiparty/multidirectional communications from the real time -- voice chat -- to the asynchronous -- like email lists. There are also single-directional communications like blog posts, email newsletters, or informational websites. Across these mediums we target different audiences: non-technical, technical, developers, marketers, other "business people," and so on.

We've started with open engagement via GitHub: our code, issues, and discussions like this are (or will be) public to all. This is almost solely a technical, developer audience. With the work Angie has been doing, we also engage through Twitter: spaces and tweets. This engagement is the broadest. Soon we'll have a developer site to communicate information about our work as well. Another technical focus. Both communication mediums have their benefits, tradeoffs, and styles: GitHub is asynchronous, favoring longer-form prose and discussion. One needs to navigate to our GitHub org, repositories, and discussions, or opt-in to receive notifications to participate. Twitter, on the other hand, is conversational and highly public. You can follow and engage, but don't need to subscribe or opt-in to see a Tweet, you're at the whims of the Twitter algorithm. Spaces are real-time voice conversations, and tweets are often more useful for quippy engagement-bait than thoughtful discussion.

We're starting to color in a graph of our accessibility / all possible accessibility we can have, and I want to step back and consider the utility and benefits of each, so we can approximate the most effective communication possible for our work. That means, for those who are looking for specific information how easily can they find it? How quickly can we solve problems as they arise and create an excellent experience for those engaging with our team and its work. How do we attract, engage, and retain an audience interested in, and bought in to the success of our work? The scope of that statement is pretty wide, so I'll bite off a chunk to start: how does the development team engage with individuals and teams building with and on top of our stack?

From experience, there are usually a few tried & true methods -- from most asynchronous, to most synchronous: a developer site with rich documentation including both written explanations and code examples, a GitHub organization with repositories, issues, discussions, and a real-time discussion medium (IRC, Slack, Discord, etc.). We're building the first, we have the second, and we don't have the third. With each additional communication method we add, there's more overhead for the team. What might be the right choice now, might not be the right choice in 6 months, or 2 years.

Moving past the theoretical and into the practical...
As we are beginning to get folks working with our code, and partnering with us to build, we will certainly need a real-time communication mechanism. With the wide success and adoption in the "web3" space of Discord, I believe it's the right choice for us. And I believe now's a good time to start small, build up some team muscle, and expand our usage. Discord is free to start, though we can pay to upgrade our server at any time. We can have a variety of public and private text channels, similar to Slack. Anyone can join at any time. It also supports voice chat and screen sharing. We can use it for a variety of purposes: technical, general product, marketing, social engagements, and all sorts of other discussions.

I believe Discord is the right move for publicly engaging with TBD in a real-time manner. Here are some pros and cons that I see:

Pros

• Free to use
• Easy to set up
• Already widely used in the web3 space
• Works well for real time chat, and voice chats
• Able to have both private and public messages
• Could be great for community building, recruitment, and an easy way to engage with what we're building

Cons

• As we grow, we'll need moderation. Spam is a risk
• The team will have another thing to check
• Notification controls aren't great
• We'll need to come up with some rules/guidelines for how the team engages/response SLAs

Considerations

• There are a set of problems that will be "soon" and others that will be "later"
• I believe we can solve the soon, and leave the later until...later
• Discord can be used as a "funnel" to get interested parties to join right now.
• The TBD team won't need to be involved in each conversation, we'll be creating a space for those interested in our work to engage organically.

I recommend that we do a "soft launch" of Discord soon. Meaning, we can invite people, but it's not publicized on our social media. For the first set of interested parties, and folks we run into at conferences, this can be an easy way to stay in touch. What do you think?

[mistermoe]

I think realtime messaging is necessary especially during early stages of development. We want quick feedback loops and we don't yet have concrete documentation that won't be changing every 2-3 days. Prior to a stable release, we'll have to help external contributors quite a bit with simple things. It's much slower to do so using GitHub Discussions

[mistermoe]

+1 for discord as a means to collaborate. Screen sharing, voice channels, and chat all in 1 app

[hellendou]

I also fully agree with Discord. It has the right atmosphere and as you said is already being used by the web3 space.

I feel the most excited contributing if I knew I was able to get real time feedback. I think it also can produce engagement and excitement for the developers on the team if they are able to see the community being built in real time.

[ALRubinger]

+1.

Real-time comms are an essential part of modern dev. Some considerations I think are important:

• Opening up any comms channel is a commitment to the community to invest in it. In time, we hope the community will be self-sustaining: easy questions will be answered by more seasoned community members. But as we build up our programs, we'll have to be responsive to Discord to help it succeed.

• It's totally appropriate to direct questions in Discord to where they may be better served. Having norms about, for instance, design discussions in GitHub Discussions or code reviews in PRs will help it be successful. We don't want people being left out of decisions because it was discussed while their time zone was asleep.

The soft launch approach Gabe suggests sounds great to me. We can scale up and figure how we can make this work best for our contributors. 🤘🏻

[decentralgabe]

With broad consensus, I've generated us this invite link: https://discord.gg/3ZvYaxBgVz
I'll start selectively sharing...

[codi0]

I think Discord is the best option at this point.

One thought has crossed my mind, which is "should this be a TBD-run discord, with community participation" or "a community run discord, in which TBD is a participant" (or perhaps both will be needed).

Pros and cons to this, but my only concern with the first option is that it becomes too cantered around TBD, rather than the goal of building a community around the ipfs/did/vc/dweb-node stack (or whatever the precise goal is defined as). I think this has happened with other initiatives, albeit for reasons far deeper than how a Discord group is run (E.g. ICP and Dfinity Foundation), and it can then be hard to shake the perception.

This is perhaps a much wider consideration around how the effort as a whole is viewed, but I would find it somewhat refreshing to think of every entity involved as a participant in a newly-founded community, that is not run by a single entity.

[ALRubinger]

Good point to bring up.

The TBD Discord should be focused on projects that are stewarded by TBD. For instance, we're making an implementation of Web Nodes, and that's good to discuss there. The spec itself is in DID. So discussions around evolving the spec or other dependent projects should take place in the communities where those are centered.

[codi0]

I agree, it makes sense to use TBD stewardship as the defining factor at this very early stage. I do believe the base stack being developed (DWN etc) may morph, in a very positive way, to something that is bigger than TBD itself, but that will of course take time and effort. Perhaps just something to keep in mind as things progress.

P.S. Is the TBD discord up and running as yet?

[decentralgabe]

@codi-si yes -- https://discord.com/invite/3ZvYaxBgVz