chore: update spec-new in CONTRIBUTING.md [skip ci]

[JLHwung]

Q	A
License	MIT

This PR updates the process of developing a new babel plugin in this repo. It features a detailed checklist and an updated example of a new parser feature PR.

The process also requires an AST PR addressed in ESTree before implementation. By doing so we can gather more feedback, especially about the AST shape, before a new proposal is implemented in Babel. In the future we will follow ESTree unless the new AST is not consistent with current Babel AST.

/cc @nzakas @RReverser

[nicolo-ribaudo]

In the future we will follow ESTree unless the new AST is not consistent with current Babel AST.

Also not if the experimental estree nodes change after that we implemented them (and they are free to do so).

[JLHwung]

@nicolo-ribaudo Though it is called experimental in ESTree, the AST changes are still rare once it gets approved: https://github.com/estree/estree/commits/master/experimental

We should document our AST stability policy somewhere. Here it works as a rough guideline to new contributors working on new language features.

[hzoo]

Cool!

it would be nice to maybe document where/when we do things somewhere (I used to do it at https://github.com/babel/proposals, example like babel/proposals#18) so you can track history but it's been some work to keep it all organized/updated

[existentialism]

👍

[JLHwung]

it would be nice to maybe document where/when we do things somewhere (I used to do it at https://github.com/babel/proposals, example like babel/proposals#18) so you can track history but it's been some work to keep it all organized/updated

Yeah a repo / issue tracking each proposals is always good-to-have but proves a bit overhead, at it is prone to become outdated compared to https://github.com/tc39/proposals.

Currently we use labels to track issues related to specific proposals. It is easier to maintain rather than updating stages/status manually in babel/proposals.