Add RFC process

[iredelmeier]

Also discussed during F2F Trace-Context meeting

We should use an RFC process for proposing and discussing specification and other cross-cutting concerns.

Why?

• Helps consolidate tracking of large issues across the discussion and implementation phases
• Facilitates discussion: it's easier to suggest changes by adding new issues and PRs related to an existing file than as part of a single PR
• Makes it easier to standardize the process for changes
  • This is particularly important for making sure that changes go through a consistent process
• Should help with visibility of changes, since RFCs will be distinguished from smaller PRs (e.g., PRs to fix typos)

Suggestions

• Base the RFC process on the Rust RFCs and possible Kubernetes Enhancements
• Track RFCs in their own repo
  • This is useful for ensuring that they're easy to find at a glance (vs a subdirectory in another repo)
  • Would let us keep issues and PRs based on RFCs separate from other issues and PRs, again helping with visibility and consolidation
• Clarify what does and doesn't require an RFC
  • e.g., spec changes require RFCs; language-specific implementation details don't; bug fixes don't

[tedsuo]

This is a great idea!

Please also have a look at the OpenTracing RFC process, as it specifically addresses the issue of specification changes which must be vetted and applied across all languages:
RFC Process: https://github.com/opentracing/specification/blob/master/rfc_process.md
RFC Template: https://github.com/opentracing/specification/blob/master/rfc_template.md

I think an RFC process is especially helpful for specification changes, which have a lot of moving parts and end up affecting a number of repositories. Besides specification changes, are there any other cases which would benefit from extra process?

[iredelmeier]

@tedsuo re: other changes, I think most cross-cutting changes could benefit from an RFC, e.g.:

• Process changes, e.g., how should we organize integrations
• Cross-cutting practices, e.g., setting up CI/CD for all SDKs/integrations/___
• Governance changes (maybe?)

This might be a discussion for its own issue (or set of RFCs!), but I strongly believe that consistency across and within languages, integrations, etc. is highly critical to a great user experience for OpenTelemetry. Some practices that help promote consistency won't necessarily conform well to the spec.

[SergeyKanzhelev]

I believe community and specifications repos would cover most of the topics. We also need to define an escalation process. I.e. how to identify that the issue is cross cutting to bubble up to specification/community repo and whether the issue is an RFC rather than simple doc update.

There is also some thoughts here: #41

[iredelmeier]

@SergeyKanzhelev escalation process, backlog management, etc. are among the sorts of "process changes" I was envisioning above.

[austinlparker]

In OpenTracing, RFCs would need implementations in language interfaces before they could be officially adopted - I think that worked well, to an extent, but sometimes put us in weird spots where an RFC would be crafted too closely for a single language. It might be useful to consider that in the new RFC process.

[iredelmeier]

Initial repo here