specification
specification copied to clipboard
opentracing
Renovate OpenTracing project organization
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 toopentracing/common... there's a script for that, hopefully it works - actually make good on https://github.com/opentracing/opentracing.io/issues/76 and add some
.yaml-style data toopentracing/commonas 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
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?
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)
@cwe1ss good idea re specification -- should make things clearer.
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.
Well, the importer thing works, at least to a first approximation... I'll give people a few days to say "STOP STOP TERRIBLE IDEA" before doing this for all non-documentation issues (including closed ones).
Well, the migration tool was a total fail. It has lots of soft-errors and was only partially migrating issues.
I decided to just do them manually. :-/ Sad times.
But what's done is done! With that migration behind us, I will now go through and update the docs site to point to the right place(s) and fix a few other issues in the documentation spec along the way.
Oh, PS: all imported issues have the imported label and can be found here: https://github.com/opentracing/specification/labels/imported
@bensigelman , May be you should add all contributors, for OpenTracing spec or Platform-impl , to the Collaborators list of this repo?
Because this repo is only used in discussion, few people will become contributors. It will be hard to tell the diff when read the issue comments. This is not so cool.
@wu-sheng I understand what you're suggesting, but I'm reluctant to pursue that path since it will be difficult to maintain. I think we just need better docs and pointers to the specification repo, or that's where I'd like to start.