I think this is a great initiative and we’ll definitely support it from data & infrastructure perspective. In addition to what was listed, I propose the following ideas that I think would make sense for the developer tooling:
- Data ingest for Paseo and making all the blocks available for developers, through a similar interface shared here on Dotlake. This is to not reinvent the wheel and save on integration costs into block explorers.
- Uptime / Availability & SLIs (service level indicators) monitoring for the testnet , this is essential to keep track of whether or not we’re doing a good job and for us to establish a way to communicate incidents, downtimes and more in a transparent manner.
More “meta” and not directly related to Developer tooling, I think the following are important to define too, especially to address the “where are we now?” painpoints:
- Agreed and defined SLOs/SLAs (Service level objectives & agreements) for the testnet (99%, 99,9%, etc) and what guarantees we want to give the community. The stricter the requirements are, the higher the associated tradeoffs and lower the development speed could end up being. We need to establish who will be doing this monitoring and how issues are communicated, otherwise we will be left guessing.
- Perhaps also agreed upon “time to get a slot” or “time to get something integrated”, to not leave teams who want to build guessing (which would be covered by SLAs but it’s good to treat them separately from the nodes & machines part)
These definitely don’t have to be over-engineered, but a first rough draft for target numbers we think are achievable would go a long way to give confidence and reliability.
Beyond that, perhaps also documentation updates for how to get started working with the new chain, who to contact etc. Again, this is just my 2 cents. Really looking forward to have the chain live and to replace Rococo in my own applications, thanks to everyone involved 