Improvements in minimal template

[gupnik]

This PR makes a few improvements in the docs for the minimal template.

[kianenigma]

Great start. I think last step you should run this, and see what details you need to provide to the user about how to run etc.

[kianenigma]

• https://github.com/paritytech/polkadot-sdk/pull/4119/files#r1565970574

Regarding running the node:

• The block time being configurable
• Fixed transaction fees

[gupnik]

Where will the readme.md be hosted? Could you remind me the distinction between deciding between whether to put content in the readme or rustdoc?

My preference would be to move most of it to rustdoc and keep readme as a light intro.

[kianenigma]

I don't think pallet developers should be concerned about needing to write a default config for every runtime variation the pallet could be used in, the point of pallets exposing a config is so the customisation happens in the runtime?

Is a correct comment in general. I foresee that a pallet can expose optionally, at most 3 configs:

1. Test, non-important and should be permissive to allow things in test
2. Solochain config, restrictive.
3. Parachain config, mostly same as Solochain, but with higher emphasis on weights or other concepts that differ between parachain and Solochains.

And anything more can live in independent crate, possibly even outside polkadot-sdk. A crate that uses pallet-x as a dependency and exposes defaults for pallet-x. Imagine many variants of pallet-balances-default-config, provided by different teams with varying degrees of opinionation.

I've also raised that a team (eg. OZ) can instead of building a full runtime with 10 pallets, simply provide a set of defaults for those 10 pallets.

This also encourages lazy, or blind runtime development. Critical configuration of your runtime is decided for you in a crates.io package you'll probably only skim read. Even if you do check it thoroughly, what if a new default config item is added to the downstream package in an upgrade that doesn't suit your runtime? There is a risk that decisions will be made for you without you knowing.

Indeed, any default configs added to polkadot-sdk should be carefully reviewed for safety. If any doubt remains, we should not provide a default.

A downstream team can always opt out of using derive_impl if they feel more comfortable not using arbitrary defaults from upstream.

Possibly, we can even provide a default type that does nothing and raises a compiler_error! such that a downstream teams, even if they opted into derive_impl have to provide their own.

[gupnik]

@liamaharon @franciscoaguirre @ggwpez Could you take a look at this again please?

[ggwpez]

I actually had the same issue on the polkadot-sdk umbrella crate and ended up using ::tt * since path seems to also not be enough.