Define incubation process for proposed specification changes

[yurishkuro]

In the last OTSC meeting (2017/03/24) we discussed that it would be good to define a process for incubating new features being suggested for the specification, such as #57. It should probably be defined in the project_organization.md document.

Some of the guidelines that come to mind:

• languages like Java that support method overloading are very suitable for defining the proposed extension as an optional interface in opentracing-contrib that can be implemented by the tracers to allow the extended functionality (e.g. #62)
• the incubating project can provide a downgrade wrapper for tracers that do not support the new functionality. For example, #62 suggests adding a new "log level" argument to the log methods. It can provide a wrapper that implements the new extension methods by delegating to the official API in some way, e.g. by moving the log level from an argument to a tag.
• if it 's demonstrated that at least three existing OT implementations support the incubating specification change it can be considered for becoming a part of the official API

[wu-sheng]

First, how should we do to accept new features, is very important. But these guidelines are facing some situations. Some incubating project, like #62 , can use overloading and wrapper to provide new API. But As it is not an official spec, why the projects are going to support?

It has been proved. Even it is a very important feature, like globaltracer or spanmanager, nearly no project use them before they become official. They are in afraid of API changing, this is a bigger cost than a new feature.

[bhs]

@yurishkuro demonstrated support from three impls seems sufficient, though I wonder if it's "necessary" in many cases. So much of this depends on the complexity and impact of the proposed change, and unfortunately that's more than just API-breaking-ness. E.g., the log verbosity thing is really just agreement about the comments for a string constant, yet it's controversial and will probably remain that way.

Another idea would be to require a sort of 1-pager summarizing "significant" (definition of significant left as an "exercise to the reader"!) changes, possible benefits for tracing systems, possible risks, and alternatives. Essentially a concise design doc; maybe just an issue template, I don't know. Anyway, if those proposals are uncontroversial as far as the OTSC is concerned, then great. And otherwise, we could just take things case-by-case.