Initial branch

[tylersnavely-wf]

@evanweible-wf had started this effort many months ago, and we want to pick it up and push it forward with dedicated resources.
Looking at where he left off, the code is in a pretty good state; much better than starting from scratch. The work is based on the OpenTelemetry Specification for language implementation.

This PR just copies all of Evan's work as a base for us to work off of. The first commit was authored by him, and then I added some new repo boilerplate stuff in the second.

[rmconsole-wf]

Merge Requirements Met ✅

Request Rosie to automerge this pull request by including @Workiva/release-management-p in a comment.

General Information

Ticket(s): None found in title
Code Review(s): #1
Release Image Tags:

Reviewers: blakeroberts-wk, tylersnavely-wf

Additional Information

Watchlist Notifications: None

	When this pull is merged I will add it to the following release:
	Version: opentelemetry-dart 0.1.0
	Release Ticket(s): None

---

Note: This is a shortened report. Click here to view Rosie's full evaluation.
Last updated on Thursday, July 22 11:26 AM CST

[aviary3-wk]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.

[blakeroberts-wk]

we should delete everything vm. I think that's outside the scope of this project and I don't want to support it.

[tylersnavely-wf]

For sure. I was planning to have us only keep the opentelemetry_api and opentelemetry_sdk sections, and move the opentelemetry_context into them. I think we can clear this up in a follow up PR. My intentions were to just include the original work so we could have a starting place for discussions and a place where we can start working async.

[evanweible-wf]

(sorry, late to the party 😄) totally agree on focusing on the browser use case for now, but it may be worth keeping in mind along the way whether there's anything in the implementations that requires browser APIs. If we can instead write it in a platform-agnostic way, then it becomes usable from VM, web, and flutter, which would be nice.

[blakeroberts-wk]

absolutely. I'd hope we wouldn't have any code that depends on browser specific APIs. If that becomes the case, it should be easy enough to label the overarching interface implementation as browser specific and leave room for a vm implementation

[tylersnavely-wf]

QA +1

[tylersnavely-wf]

@Workiva/release-management-p

[rmconsole-wf]

+1 from RM