Contributing - Clarify RFC process vs PRs

[hamishwillee]

Contributing does not reflect current practice.

Contributing guide is clear that RFC process should be used for microservices - big changes that require a lot of discussion. This is to get consensus that people will adopt common definition and to remove ambiguity. It is also to highlight contentious changes.

The guide is also clear that more minor changes like documentation-only changes and some field additions can often be done as PRs.

The guide is not clear about what is intended for simple message additions that are not part of larger microservices. Currently we accept these as PRs and that process appears to be accepted and working.

[hamishwillee]

FWIW I see no benefit in following a heavyweight process "by default" to add a simple message to common. If we do this for every new message then we're no longer highlighting changes that are controversial or require more input, because almost everything will go through RFC process ("cannot see the wood for the trees").

So my proposal is that we clarify the intent of RFCs around complexity and "potential contentiousness". So the assumption would be that by default microservices are RFC and anything else is not.

BUT, we do need to make sure that PRs include a sensible default set of information including the same sorts of justifications and impact assessment that an RFC might have.

[hamishwillee]

Dev call agreed that RFC is for major changes that require a lot of discussion, or which have a huge impact. Microservices are in this category.

Most single new messages and message changes can be dealt with in the context of a PR. There may be a few exceptions, but the default is PR for these cases.