Hey Dudley!
First of all, thank you so much for taking the time to provide such a detailed response. We’re passionate about this proposal and we’re always trying to refine it, so we appreciate your feedback and thoughtful questions! I’ll try to address them as best I can.
Fragmentation of documentation is somewhat of a concern, and while we do talk about it a little in 1.3.2 it’s not something we’re trying to solve with this proposal.
If you search for “how to develop on Solana”, you will find the Solana docs, but also SolDev, Udemy courses, Start on Solana, BuildSpace, freeCodeCamp, the Solana Cookbook, and hundreds of other tutorials and blog posts. I don’t see this as problematic; on the contrary, I envy the amount of in-depth content developers have available to them in their community.
There is no denying that our technology is complex; our hope is that placing the complexity in context will help with understanding and make it more approachable.
As mentioned in reply to Basti, written content wasn’t prioritised in our current roles, but we can provide examples from previous companies.
We’ve also mentored and spoken many times on how to write content for developers. You can view one such talk by Lauren online: The Art of Writing Technical Content. While writing for developers has its own particular nuances, it is worth noting that before transitioning to tech, Lauren was an English teacher and department head for ten years.
The governance chain mentioned in the proposal is a part of the educational content package itself. Each content package aims to help developers build an application with a real-world use case. The governance chain is part of the example application users will build in the first guide to learn how to build a DAO and a dApp.
I think these might all be related to the initial misconception about the governance chain. But to clarify our plans for the content package: the secondary chain is supplemental content; it won’t be as in-depth as the rest of the content package but instead aims to spark interest with developers and show them where to go next, in this instance, it will be to learn more about chain interoperability and XCMP.
We won’t be using InvArch for this example, but we are really keen to collaborate with parachains and other projects and would like to integrate their functionality into our content packages where it makes sense. A key aspect of the Polkadot ecosystem is interoperability. If we do not produce guides that demonstrate this, then we are only showing developers the tiniest fraction of what they can build. There’s more information about this in section 1.3.4 and some examples of where we could integrate existing projects into the first content package, including Kilt, in section 1.3.4.1.
We want to incorporate collaborators where it makes sense. We do not want any of the examples to be contrived. Sometimes, we might be able to think of suitable integration points ourselves (like in 1.3.4.1) but the topic of each content package will be decided via public discussion. Hopefully, if a project thinks they’re a good fit, they will make themselves known during this stage.
We are working under the assumption that we will produce all code and content. However, the level of commitment from a collaborator will really be up to them and what time they have available. If a collaborator is really keen, we’ll happily have them work directly on the code or the content, but it will not be a requirement. All that we would ask is that they have someone available should we have any questions during development and that they’re also available to perform technical reviews to ensure we’re following their best practices.
Also, if they want to join us on any of the live streams, they will always be welcome; it would be great to see you and Lauren streaming together again!
The Polkadot Developer Heroes, the PBA alumni, and other similar groups already building in the ecosystem will be acutely aware of where we lack documentation to help them achieve their goals. We hope that they will not only find our content useful but that they will provide valuable feedback and ideas for future content packages. Also, we hope that members of these groups will be some of the first contributors once we have tips and bounties (see 1.4.1.2 and 1.4.1.3).
Each deliverable within a content package is geared towards a different learning style. If we produced content only for a single style of learner, we would not reach those other developers, and the impact could not be reliably measured.
If we were to keep the different styles of content but reduce the scope of the example application, then we risk creating tutorials which do not contain enough context to allow people to really grasp how all of the technologies work in unison.
However, each content package is broken down into multiple deliverables, each of which will be published as soon as they are completed. This means that we will be publishing a new deliverable roughly every two weeks. This way, not only will the community be able to see constant progress, but should a package need refining, they can provide that feedback early.
As I mentioned when discussing fragmentation, that’s really out of the scope of this proposal. But, if you’re asking how I personally think they could be united, then I think our best chance will not come with having a single organisation attempting to do it solo but through shared responsibility (see 1.3.2).
Maybe it is time for a Polkadot Developer Education DAO/Fellowship!
We are proponents of data-driven decision-making and evidence-based education, so I’m glad the proposal made that clear. We’re also on the side of the community; we want to be open and transparent, not just for accountability but so that we can involve the community at every level of decision-making.
