Oh got it – The Technical fellowship is for people building Polkadot, and this PBC is for people building with/on Polkadot. Not sure how to rename it, please suggest something? Concretely –
PBC is about:
- CoreTime buyers/sellers helping each other
- Substrate builders, up to the point where the parachain is launched but even thereafter – helping each other
- ink/WASM contract builders – helping each other
- dapp builders (who need help with XCM, etc.) – helping each other
- CoreJam+CorePlay builders, DA builders – helping each other
- builders on builder-oriented parachains (MoveVM! CairoVM!) – helping each other
- how to build your own collective (ha!)
Please share other cases! But the core is “helping each other”.
PBC is not about:
- building Polkadot itself (the super engineers of the Polkadot Fellowship do this)
- serious business/technical issues of maturing parachains (which would be the Polkadot Alliance, or a Parachain Technical Fellowship)
- any kind of general retail/investor focussed “you should {stake, buy} Polkadot and its parachains” or let us help you use the dapps/staking dashboard/find out where your crowdloan DOT went – all helpful, but not about building
Seeding is absolutely essential, please share your thoughts! I believe a good PBC seeding would be people who have educated, want to educate + help others, or are learning something new and can teach others. The end result should be builders building more, buying CoreTime, ideally visible in github and working products that are used by thousands of people every day. This kind of education is the best form of marketing and increasing awareness, and does not have to be in the form of expensive events and hackathons – small, even one-on-one online meetups are fine.
In this seeding, we definitely want technical and educational “content creators” who can teach (through code-centric activities) and help people in an online meetup in any language – but if they are reading translations and not directly actually actually helping builders, and we’re counting how many views/retweets/likes, we will have seeded it badly. The act of content creation is secondary to the offer to help. There should be no reason to require that a PBC member is a Paid Member of the Polkadot Builder Collective any more than a current educator who gets paid to educate people on Polkadot does. You may go so far as to say that a PBC member has to be a software engineer, but I think that’s too much. But a “content creator” with just a camera, mic and video editing skills and “oh, I don’t know any code”… epic fail. In between you usually have “oh, I don’t know the answer to that, but I know X who does”. So its a spectrum to navigate.
On “github commits”, I often see this as a coarse measure of developer activity (Polkadot is the #2 ecosystem, supposedly, on this measure), but I find it superficial for simple reasons mentioned here:
- commits are akin to hitting “save” on a Word document and do not necessarily reflect meaningful progress,
- developer counts do not reveal whether projects involve “10x engineers” who do disproportionately more work than others, and
- more lines of code could be a sign of poor code structure rather than new features.
If the promoteMember in the PBC is based on subjective metrics rather than superficially crappy metrics like “github commits” (or good heavens, “lines of code”), in addition to the people-level seeding, the way we promote/demote people for being “high/low impact” (as opposed to just putting more work hours) is just as critical. Using rank to indicate knowledge as well as monthly impact is problematic – people should be able to take a summer vacation and get their rank back. What are your thoughts on this?
We need a strong open welcoming, inviting, supportive, collaborative builder community in the PBC. How would you like to help?