Unifying the Polkadot Developer Community

The Polkadot Growth Strategy wants to make Polkadot the best place to build Web3.

To make this a reality we need to talk about our developer community. There is a few issues that have regularly been mentioned in that context:

  1. there is too many different chats
    • Some of them are bridged, but the experience is not great
    • it is not clear where to send devs seeking help to
  2. unclear tech support: because Polkadot has such a broad range of tooling and SDKs, there are many different questions pouring in and it is unclear who is responsible for answering them.
  3. quality of debate “there is no place where devs can properly discuss”, some participants have been critized as rude or not constructive, leading us to lose devs to other ecosystems (they have choices turns out)

To address these issues, I would like to start a discussion around those issues with 3 proposed ideas:

  1. Agree on one place for developer discussion and make it really great. This could be Discord or some other place. If developers know that there is one place to go to, they will hang around and it can become a place where you quickly find multiple devs chiming in on a discussion. It is also a great opportunity for new devs to discover how much is going on in the eco. And it can lead to balanced debates where multiple perspectives are shared, instead of locking in to one technology.
  2. Create a developer support bounty or similar mechanism to ensure that tech support questions are answered. Since there is a broad range of tech and it is unlikely all devs will commit to support their users (sadly), we need to develop effective/efficient support structures.
  3. Develop a code of conduct of how we interact in a manner that is constructive and critical, but doesn’t push people away from our ecosystem when they have something good to contribute.
8 Likes

What about “the official one” that is being used in the water-cooler etc? https://hackmd.io/ULADdNflR2Sk-6AiPhSwmw

We just added this to Polkadot-SDK README. While it not being perfect, it is a start. I think having a unified chat room is nice. I don’t know what are the problems of bridged rooms? Otherwise we could just create these rooms on Discord and then bridge them to Element.

3 Likes

There’s channeldev-discussions at the Polkadot discord which isn’t currently bridged to Telegram/Matrix. Maybe we can do this?

We get lots of queries at discord side too.

2 Likes

Why exists there another channel? :smiley: Can we not merge that one with this one?

The points raised here were the central theme of our deliberations with the teams that promote Dev Rel one way or the other within our ecosystem (Parity, W3F, Papermoon, WebZero, OpenGuild, R0gue and members from parachain teams like Hydration and Bifrost and external teams like Encode Club, OpenZeppelin and EasyA). Here are a few solutions we are experimenting with starting on April 7th when the 4-week Polkadot Scalability Hackathon by EncodeClub goes live:

  1. Polkadot Developer Support:
  • 1:1 chat support on workdays with a ticketing system. Developers need to accept the discord invite and pick the role “builder” to access all of the technical channels https://polkadot-discord.w3f.tools/ We currently have 10 dedicated (and can I say qualified?) developer support personnel from Papermoon, W3F and Parity across the timezones, and dev support is part of their day jobs. We can grow this number if the demand surges with Hub launch. Any enthusiastic dev support volunteer is an added bonus! The ticketing system analytics will help improve this dedicated support.
  • Developer Q&A and knowledge base https://substrate.stackexchange.com/ - The dedicated dev support personnel on discord/telegram/matrix chats will be encouraged to share StackExchange posts whenever/wherever relevant. This ensures there is visibility and traction for that Q&A knowledge base. When a new question pops up, the dev support personnel in 1:1 chat are encouraged to create a question and answer it/get it answered on StackExchange for broader reach.
  1. Agreed. There is no Developer Support bounty right now, but on behalf of W3F, I am working with partners like Parity, Papermoon, OpenGuild etc. to provide dedicated support on developer platforms. One way to ensure this is to negotiate W3F funded contracts for the inclusion of formal dev support. The same norm should be applied to the treasury funded dev rel initiatives. There is a need for a dev rel support metrics dashboard to keep track of individual contributions for deciding on rewards/improvements. I will work on it.

  2. 100% with you on this. Although, I think this requires a cultural shift within the Polkadot developer ecosystem along with a code of conduct.

4 Likes

this points to dev-discussions which I mentioned earlier :sweat_smile:

I was too lazy to login to Discord to check it :see_no_evil_monkey: I thought this is already bridged or about to be bridged? I talked to @bill_w3f about it.

1 Like
  1. I agree unifying developer chat in one place, however I guess it’s more on the general chat because some of the developer discussion that hosted for high-level topics need to remain private.
  2. We should encourage and make it as bare minimum requirement for any hackathon campaigns to get developers join Polkadot main Discord “developer section” by some ways. On this, I’d recommend we have 2 main languages - English and Chinese with native support for both with different approach.
  3. I think for local level, developers should be able to have different discussion forums, because they should be able to chat where they feel good. However, for any funded local communities, encouraging these developers to join Polkadot main discussion forum should be their responsibility.
2 Likes

It’s being worked on.

1 Like

What you mean by this? Which discussions?

1 Like

Ah, sorry if my words confused you.

I mean, general chat would include new devs coming and going, asking questions, and daily chats about general technical topics.

Other discussions might cover advanced technical topics, etc., which should be separated to avoid confusion.