I am looking for tips into building a community bringing customers and internal dev/consultants where the current main communication tools are very formal like Jira and very liberal like Slack. The reason for that community is to be able to open up discussion more often and bring more people around the table but also replace some internal communication which were placed in other tools.
With that many tools competing for communicating and different focuses depending on the “goal” of each participant, how would you make the implementation of a community with discourse a success?
We’ve tried thinking along what scope for each tool but most of the time are failing to get internal people making use of Slack for about anything they can think of. Some people are also reluctant for having “just one more” tool/place to check regularly to get information from.
Perhaps taking the perspective of being a curator would help. I feel like we don’t do this enough in community building.
As community builders we see things many people don’t. We learn about our people. Their wins and pains. We know what comes up time and time again. We know who to tag in. We understand what gets shared around.
It almost becomes our job to support all of this ecosystem and bring it in an organised and systemised way. I think Discourse can be great for this.
We can cross post repeat questions, summarise stuff, ask/tag/quote people.
“But it doesn’t scale”
It can do, the people scale it, if it’s done well and in a way that is actually helpful.
I wanted to take a moment to summarise what I have learned so far through various discussions we had on the chat to bring it back into the open. First of all thanks to @JammyDodger and @tobiaseigen for the time they spent into it!
Time and planning
Building a community takes time and requires some planning. It could become quite overwhelming to do everything in one big step.
I'd take it category by category, and plan out what you'd like each to function as. So the first 'division' would be between public and private information (customer vs staff/insider), and permission-gating some of the categories to provide those private areas
One of the main concern I had was how to bring internal, knowledgeable people into the community:
Providing a space and shape for that purpose is the first step, though you will likely have to also adapt and encourage as you go. Though this also helps the contributors feel a sense of ownership of the space too, which can motivate them to help build it further
Knowledge management is a key when we talk about a community and Discourse can help when everything is centralised:
I also like the idea of having as much activity as possible in one place, so you don't end up scattering everyone's attention (and the info!) all over the place
Discourse has some powerful functionalities like Wiki, group inbox, whispers, read indicators and plugins like Discourse policy and Discourse Docs. However in some complex infrastructure with many assets, it may be interesting to invest a bit more to connect the dots or do it step by step:
As you have probably seen, discourse has an API and webhooks, so you can set up your monitoring tools to send to discourse instead of slack. This is what we have done ourselves since we switched from mattermost (and previously slack) to discourse chat, our internal discourse.
One other key concept is bringing structure through curators (as @rosiesherry says above) but also:
I think a lot of those elements can be catered for with a bit of structure to your different areas. A mix of formal guides, and more informal discussion topics which encourage more back and forth
Basically, there is no “one way” to build a community and it is a matter of trial & error, do it step by step, engaging and encouraging people and structure where there is need after gaining some more insights.
This is all about motivation and persuasion. Social science. What do these people want? A platform to show off their knowledge? To be challenged by peers? To learn from others? Crack that and you’ve got them.