Add some documentation on how to use this

[djc]

I have just gotten tracing set up for the first time, exporting my traces to Jaeger locally for testing. Now I would like to build out support for inspecting traces in production, with my application running in GCP. I think your crate can help with this, but I'm pretty unclear on how to set it up. If you can provide some hints, I'd be happy to flesh that out into documentation for this crate (and bump it to the latest version of upstream crates where useful).

[Xaeroxe]

Hey, here's a couple things that might help you.

https://vivint-smarthome.github.io/opentelemetry-stackdriver/opentelemetry_stackdriver/

https://github.com/vivint-smarthome/opentelemetry-stackdriver/blob/master/examples/basic.rs

If you feel those aren't sufficient maybe we can talk about how it could be improved.

[djc]

I found that pretty sparse. It would be great to have a little documentation on the SpanExporter::connect() method that explains what the arguments do and how it fits together. In the meantime, I've made some progress on figuring it out for myself.

Which leads me to another question: given that it took 22 days to respond to this issue, and #10 hasn't had a response for 8 days, I was wondering what the intention/motivation around open sourcing this code is? For my current work project I need a good solution to get tracing data into Cloud Trace, and I could work on this crate, but in the end it's not a lot of code and I could easily fork it. Would you be able to provide code reviews, or alternatively make me a co-maintainer?

[Xaeroxe]

The motivation for open sourcing this was a desire to prevent others from having to repeat the work I did. I apologize for not being very responsive, my work schedule is pretty full as of late and this project is merely one cog in the greater whole I maintain. I saw #10 when it went up, but reviewing it had to go down on the priority list because it was non-trivial to review and I had higher priorities. You're welcome to fork this crate, I won't have any hard feelings about it.

[djc]

All other things equal, I'd prefer to work together to make this crate useful and preventing yet more others from having to duplicate our work. Do you think that is achievable, or will your work schedule make it harder to move forward? Or, should I just accumulate potential changes and will you potentially have some time to review them in the future?

[Xaeroxe]

It's likely I'll have time to review it in the future yes. That works for me.

[ErichDonGubler]

Because the sequence of steps and types to walk through is complicated, perhaps the best way to approach this might be with a step-by-step example? This could be implemented with a doctest, which would have the benefit of being type-checked...that is, once this gets resolved:

opentelemetry-stackdriver/src/lib.rs

Lines 17 to 21 in 38c1e3e

	#![cfg(not(doctest))]
	// unfortunately the proto code includes comments from the google proto files
	// that are interpreted as "doc tests" and will fail to build.
	// When this PR is merged we should be able to remove this attribute:
	// https://github.com/danburkert/prost/pull/291

I've given it a shot at #12, adapting the basic example to have local imports (to make the source of symbols abundantly clear) and changing the code's style to be as incremental as possible. What do you think, @djc? :)