Draft: Defining clear rules regarding merging a PR

[Noc2]

Given that we now have separated the website repo and the spec repo, it might make sense to define clear rules regarding who decided what should be merged and what shouldn't. Therefore I quickly came up with a Spec Committee and potentially we can also integrate some additional rules (e.g., the spec needs to be based on research and/or existing implementations). My main goals here are:

• convince more implementers to actively participate when it comes to the specification
• overall improve the quality
• an initial step to further decentralize the spec

[danforbes]

Per my comment here, it seems like this may be a good opportunity to deploy the Polkadot Fellowship.

[Noc2]

The idea behind introducing the Spec Committee, in addition to the technical fellowship:

• was to have a group with a clearly defined responsibility to maintain the spec
• and to convince more people to contribute

That said, I'm happy also to move the spec to the fellowship and to discuss or help fellowship members with the transition.

[Noc2]

Any additional comments here? Given the response here, I would like to at least give it a try and see if this leads to more/better contributions to the spec.