Propose a more precise tagline #256
Conversation
|
I don't want to back and forth on this, but I'd like to request to take Zipkin off opentracing's homepage. I'd suggest Jaeger instead. There are a few reasons for this:
I think this is just a legacy from before jaeger had a docker image. Anyway seems while you are adjusting your website you could consider addressing this. |
|
Since OpenTracing is a standard, would it make sense to call that out in the tagline? "Vendor neutral, standardized APIs for distributed tracing." |
|
I dont think, exist realy vendor neutral. Stardard group members come from vendors. Even Apache projects can't be considered as vendor neutral. It is just open , welcome and high valued everyone. |
|
Will the word 'Open-Source' make the tagline more effective? |
@saloni-garg I think open source is obvious, because OpenTracing hosted in GitHub, and CNCF. Which both required the project open source, especially CNCF asked for Apache 2.0 license. |
|
+1 about using Jaeger at home page. More opentracing native supported. |
|
@bhs I think "general purpose" qualifier is so broad that it would invite similar criticism as before. I like the following qualifiers:
|
|
+1 to Yuri's suggestion to add the word instrumentation to result in something like:
|
|
There is some concern with sing the term "Standard" on the website. Even though it's natural to say "standard tracing API" and "standard tags," the CNCF is not an official standards body. We can say "de-facto standard" or something similar – but it would be best if we avoided the word "Standard" in the main tagline until there is some resolution there. We do strive for vendor-neutrality, and go to great length to make sure the API works well with all the existing vendors. If it isn't working well for someone then we want to fix it. So that is an intentional goal of the project and I think we should stick with it. |
|
Sorry you don't want Zipkin listed @adriancole! But I understand, and we can take it off the marquee. I would still like to list it under "supported tracers" as there are a number of ot-zipkin bridges available to people. Is that all right with you? |
meh... I wouldn't be hung up on this. When a large group of entities comes up with a "Technical specifications contained in a document that lays characteristics of a product such as levels of quality, performance, safety, or dimensions" (GATT definition), they end up with a standard, whether the group chooses to call itself a "standards body" or not. Regardless, the current proposal is to use the word "standardized", which is different from "standard". |
|
I was one of people objecting the word standard, because it simply isn't a standard. It might become one, but standards usually have very strict guidelines how they are defined, how implementations are tested, etc. I would be fine with an "Open Source project aiming to define a standardized API for describing distributed traces". |
|
I'm not sure who's actually supporting the zipkin tracers, certainly very
few folks from opentracing are, and issues go unresolved that affect us*.
However, it is more important to me to not have the marquee. So anyway,
sure.. let's just start with the marquee as the "supported" vs "things
being available" issue is a bit separate
* a couple issues that have gone no-where that limit us. The idea of
"support" seems to be in conflict when we are stuck due to things not
moving, yet have demand inflicted on us.
opentracing/opentracing-java#212
opentracing/opentracing-java#256
|
As you wish, sure. I spun this off as #257 since this PR is meant to be about the big-font copy which can/should be clearer. |
|
OpenTracing is valuable both for the decoupled "whitebox" application-level instrumentation and – now that the project is further along – the (mostly contributed) instrumentation of 3rd-party OSS out in the wild. As such, I wonder if we should go with something like
As for the debate around the word "standard": with a "lower-case s" that word does not imply – at least to my brain – that OpenTracing is a "standard" in the same way that a centimeter is a standard. I read that word as a synonym for "general-purpose". I removed it in this pass since I don't think the word "standard" is literally necessary and – empirically – it ruffles feathers. |
+1. Only maybe APIs should come first, "APIs and instrumentation"? |
I agree... I'm embarrassed to admit this, but I started that way and got annoyed by the line breaks and couldn't figure out where the CSS was to control that particular
@yurishkuro I've never loved the "vendor" aspect of "vendor-neutral", as most people use OpenTracing with an OSS tracing system (rarely referred to as a "vendor"). But "implementation" feels too wonky. I don't have a better suggestion than "vendor" so I'm ok with this, but if there are other ideas, now's a good time to suggest them. |
|
You can use tool instead of vendor |
|
We could say "tool- and vendor-neutral"? |
|
I think "vendor-neutral" is a well understood & intuitive enough term to not confuse people. |
|
@yurishkuro I slept on it and agree that adding the "tool-" terminology doesn't make it clearer. I also updated the css a bit for various reasons and fixed an issue with "medium" screen sizes while I was in the area.
|
|
I added #258 and waiting for others in openzipkin who have burden supporting tracers agree that zipkin should be removed entirely. It isn't up to people who don't contribute to make this decision |
|
This PR doesn't seem to be generating new opinions. I think what's here is a net improvement for sure... the one phrase that's both (a) still present and (b) somewhat problematic is "vendor-neutral"... I have done a bunch of googling and see that term used for numerous efforts where "vendors" (sic) are often OSS. As such, I think the usage here is still idiomatic (as Yuri pointed out above). I'd like to merge this before Monday AM if there are no strong objections. |
This is just one option of many... here's how it looks:
Curious what people think. cc @opentracing/otsc since not many people watch this repo.