Renovate OpenTracing project organization

[bhs]

OpenTracing has come a long way in less than a year! We hit a 1.0 spec, have a shiny website, linked up with CNCF, and so on. Certain things that we've been doing "out of habit" probably ought to be changed now that things are a little more stable. This issue is a proposal about same.

Briefly, these are the problems I'd like to solve:

• the "docs repo" (i.e., this github repository) is an odd place to discuss big semantic things, yet that's where those discussions take place
• the "weekly meeting" (sic) has been less-than-weekly lately given the lack of urgent topics to discuss; it's also at an inconvenient time for folks in many TZs (esp Europe)
• we don't have a good place to make changes that affect the semantics / reserved tags / etc of the downstream repos

My proposal is to...

• create a new repo called github.com/opentracing/common
• migrate all non-docs-site issues in this (github.com/opentracing/opentracing.io) repo over to opentracing/common... there's a script for that, hopefully it works
• actually make good on Consolidate common tags definition and auto-generate language bindings #76 and add some .yaml-style data to opentracing/common as well
• generally try to conduct consequential discussions via Github Issue, linking from Gitter where appropriate
• for things that are hard to decide about via Github, we will push agenda items onto a "monthly OT committer call"
  • (for more urgent matters, ad hoc hangout calls are fine, etc)
• keep up with quarterly calls for anyone who cares about OT, even if they're just in an adjacent project

Concerns about the above? Errors of omission? Other thoughts?

alphabetical cc: @adriancole @basvanbeek @beberlei @bg451 @cwe1ss @dawallin @dkuebric @jmacd @lookfwd @michaelsembwever @oibe @slimsag @yurishkuro

[cwe1ss]

Sounds great! My only small concern is the repo-name common as it's not clear to me whether it's about the standard itself or common programming tools/libraries/etc. Would using spec, specification, standard, discussions, ... be a better choice?

[yurishkuro]

+1 for specification

[codefromthecrypt]

ex in zipkin, we have zipkin-api for the thing holding the specs (openapi, thrift definitions), though that might not be the same (since maybe the output of the discussions won't be in the same repo)

[bhs]

@cwe1ss good idea re specification -- should make things clearer.

[bhs]

In light of the lack-of-complaints here, I've cancelled the formal gcal invite for the weds weekly meeting since it's going to die. :) In doing so I realized that the invite list had fallen out-of-date anyway.

[bhs]

Please comment at opentracing/specification#1 (comment) if you don't like the way this was migrated over!

[bhs]

... continued at opentracing/specification#1