The focus is on creating a PR. But this has two problems:
In many cases, particularly feature additions rather than bugfixes, it's
better to start with a high-level discussion of the proposed change than
trying to draft exact wording. This is done by giving an explanation of the
proposed changes in an issue, rather than filing a PR, and having a discussion
about it. (Exact text would need to morph and be rewritten a lot if the shape
of the solution changes significantly as the discussion evolves; working with
actual spec text at the beginning distracts from focusing on the higher level
design; and not everyone knows how to write good spec text, so starting with a
PR is not always a good idea.)
It makes it harder for people who don't have the time or skills to
figure out how to put together a PR to contribute change proposals. Focusing
on PRs as the way to contribute changes excludes their participation.
It's OK for the editor to have to draft up the actual spec text. That's their
job, essentially. It's nice to have help with that, but it's more important to
have a good discussion and consensus, and to allow people to contribute useful
things at whatever level they are capable of.
I agree with this. Although the earlier sections are intended to be about discussing and presenting research in the spec issue, before creating a PR, this can certainly be made clearer and the guide can discuss the points above in the Change the spec section.
zcorpan
commented
4 years ago
Feedback from @fantasai
I agree with this. Although the earlier sections are intended to be about discussing and presenting research in the spec issue, before creating a PR, this can certainly be made clearer and the guide can discuss the points above in the Change the spec section.