Creating a vibrant community. A few thoughts...

[pamtbaau]

Creating a vibrant community. A few thoughts...

Current situation

Several years ago, a "support" forum has been setup using Discourse, to facilitate users with (mostly) technical questions about Grav.

I've been actively participating by answering questions since April 2018. What struck me most over the years, was how much the forum (I'm not calling it a community yet) was left to its devices.

On top of that, a second platform has been launched (Discord) which competes for time and attention with Discourse, causing:

• A loss of knowledgeable people answering questions.
• A loss of enthusiastic promotors.
• Increase in unanswered questions.
• Decreasing quality of answers.
• Dissatisfied new users and existing users.
• Users leaving... "[..] an entire workday passed with no response [..] the grav project is incompatible with my needs" (visitor)
  Btw. sounds like a prospect for paid dedicated attention..

In my view, a thriving community requires ongoing investment to achieve its valuable return. It needs careful thought put in, research/reviews/surveys, planning, ongoing management, monitoring, promotion... In short: Cherishing it as a valuable resource. At least, if you think it is...

Yet a suggestion to move again?

A new platform has been suggested. So far, I have not heard good reasons to justify the move.

Moving again to a new platform (GitHub/Discussions) means again a loss in a knowledge base that has been build up over the years and also means ditching the personal investments made by enthusiastic community members.

Suggestions

My suggestion would be to rethink (and restart), the process of creating/managing a vibrant community.

1. Goal setting: "Begin with the end in mind"
   • What purpose should it serve both for the community and the Grav team. "Win-Win"
     • Providing support?
       • Community:
         • Tapping into a pool of knowledge.
         • Getting the job done more easily.
         • Enthusiasts can share there knowledge/experience/achievements.
       • Team:
         • Save time spent on support.
         • Focus on development.
         • Tap into a pool of users for bug hunting/solutions/whishes.
     • Marketing?
       • Community: Being aware of new (paid) products/services to ease development and hence revenue generation.
       • Team: Revenue.
   • Success indicators and how to measure?
2. Audience. There is no one-size-fits-all: Choose and communicate.
   • Pro developers with sufficient skillset? "Developers! Developers! Developers!" (Steve Ballmer)
     • Premium (paying) users and/or free users?
     • Freelance? Agencies? Any?
   • Hobbyist devs who need more handholding?
   • Non technical? May be served better by advising to use Wix/Weebly or other platform.
3. Identify key stakeholders for creating/maintaining/managing the community.
   • From team: Assign someone who will be dedicated to the community.
   • From community:
     • Identify champions/advocates/evangelists for reflection ("Seek first to understand, then to be understood") and participation.
   • "Synergize": Communicate/meet to combine strengths of stakeholders and create 1 + 1 = 3
4. Choose the right platform: Goals + Audience -> Platform.
   Platforms are not interchangeable. Discourse does not equal Discord does not equal Github/Discussions. They serve different purposes and attract different audiences.
   Choosing multiple platforms might be needed to serve the Goals + Audiences mix.
5. Manage the community to keep it thriving, which is an ongoing process:
   • Keeping in touch with it.
   • Show appreciation for the efforts from the community.
   • Honor the champions.
   • Monitor it and check against goals/audience.

Just my two cents...

Unattributed quotes are from the "The 7 habbits" by Stephen Covey.

[jeremycherfas]

I appreciate the effort you have put into this, and into the other forums.

One suggestion that might be worth consideration is to have some sort of wiki for "solved" problems and other knowledge that might have a longer shelf-life. Of course, that too runs the risk of neglect and being a burden on a few, but I do think there would be value in it.

I would also be willing tol pay (but not much) for ongoing support with a defined response time. Could even be some sort of bounty system.

[pamtbaau]

@jeremycherfas, Thanks for reading and your suggestions.

Back in Feb '20, I've suggested a wiki with best practices and solutions to common issues. Unfortunately, I haven't heard back... Might be because corona kicked in.

Since the team is looking into generating revenue, I've sprinkled some revenue opportunities in my suggestions. Payed support as a new services is certainly one of them. Businesses/agencies depending on a platform often want the security of support with SLAs.

I think enough OSS projects can be found on the web that have implemented paid services. E.g. October CMS

To help you and your business, we have developed the October CMS Premium Support Program.

We provide support through a private Slack channel or public GitHub issues and offer Service Level Agreements for 3 levels of priority: 8 hours, 24 hours, 5 days

[OleVik]

Thank you for gathering your thoughts and sharing them, @pamtbaau. From the rather brief discussion that first appeared on Discourse, to some follow-up on Discord, I'd add this:

Platforms
GitHub Discussions are far more repository-specific, and GitHub itself more apt for technical issues. Discourse is far better at complex solutions that often go beyond just Grav itself. GitHub Discussion's feature-set will probably catch up soon enough, but the threshold for entry is higher for many because they don't use GitHub itself as much. The same is of course true for Discord, which is as messy as you expect chat to be between a few to hundreds of people.

Be stricter about domains: Require Issue templates and Discussions to be thematically related to the specific repo, like when triaging Issues. Push people more towards existing Issues, Discussions, and forum Posts from all platforms. It has been, and continues to be, the case that Grav's community never blossomed as much as other CMS'. This is in large part because there's a quite small group of primary actors, and the broader community is very loosely knit. People have over time moved their activity between platforms, but a small set is most apt.

• Discord for rapid support, short and succinct solutions
• Issues for feature requests and bugs
• Discussions for repo-specific help
• Discourse for longer discussions that also go beyond Grav

There never was a centralized place for questions/answers like a Grav-StackExchange, possibly detrimentally. Searching for and finding old solutions is painful on Discord, GitHub, and Discourse, because they are all very bad at indexing.

Documentation
The Learn docs was always supposed to act like a Wiki in my view, and in many ways it is far easier to manage than any traditional Wiki-system. The problem with it is undefined standards and management. Its structure is decent enough, but as content grows there's a need for routinely cleaning up, and that should have a dedicated team behind it. There's also no clearly communicated changelog to the docs, so things can just pop up without anyone noticing.

Community
The Core Team and Core Developers, in as much as the former exists as any coherent group, clearly do not have the excess capacity to build and manage the community around a growing CMS alone. Even the presumably outdated GetGrav.org/about lists people I've not seen on any platforms for a long time. There's no reason every developer needs to follow every platform, nor have they done, but it's very much the time to support the supporters more.

Find the dedicated powerusers and ask them to contribute more substantially; there is a massive loss of knowledge on Discord, unanswered questions on Discourse, and stale issues on GitHub. More solutions need to be documented, I've seen the same basic questions and even advanced discussions repeat themselves many times on Discord. More attention needs to be diverted to specific questions across the platforms. And triage needs to happen more than every other year.

@rhukster, @w00fz, @mahagr, you need to elevate some community-contributors again, and use them to administer these platforms in a coherent manner. This was done during the end of the Gitter-period, and throughout the Slack-period, and at the start of the Discord-period, with the aim and possible result that their interest and dedication will yield better and more solutions even for those new to Grav or who cannot possibly traverse all platforms looking for answers.

[rhukster]

Thanks for these thoughts and insights. We are going to regroup in the new year and have a good think about what sort of direction we need to follow going forward. Clearly what we have currently is not ideal.

[hughbris]

Thanks everyone here for your thoughts, I can't express how happy I am to have this in the open being discussed in a civilised way.

I just mentioned some relevant points touching on this on another thread before seeing this. Must admit I've only just looked at this forum again having abandoned it for many of the reasons outlined above. Attempts to bring this up in the past have understandably triggered sensitive reactions from the core team, so I chose to stay away.

@pamtbaau is a patient legend here and on previous forums. I've been vocal in the past about recognising this better.

There's a ton of great input here in this thread, much of it I am still processing lol.

I only want to add now that the current culture/attitude around documentation is unhelpful. I'd love to see every enhancement PR accompanied by documentation as a requirement. It can't be an afterthought, or treated as less important. It's amazing how many cool features of Grav are still undocumented. I am guilty of this myself. Docs are often how I judge a project these days.

The Discord etc experience downright sucks outside the European/American timezones. There are other problems with it, but the important point is that it's not always the source of satisfactory quick answers, especially for non-trivial problems.

That will do.