Add required repo files

CHANGELOG.md

@@ -0,0 +1,37 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [v0.9.0] - 2021-03-08
+
+### Added
+
+- Added Windows TomEE image and test. [#122](https://github.com/signalfx/splunk-otel-java/pull/122)
+- Added OpenJ9 smoke test Docker images. [#127](https://github.com/signalfx/splunk-otel-java/pull/127)
+
+### Changed
+
+- Use upstream opentelemetry-java-instrumentation 1.0.0. [#124](https://github.com/signalfx/splunk-otel-java/pull/124)
+
+### Deprecated
+
+- Property `signalfx.auth.token` has been renamed to `splunk.access.token`. [#125](https://github.com/signalfx/splunk-otel-java/pull/125)
+
+## [v0.8.0] - 2021-02-12
+
+### Added
+
+- Instrument Netty 4.0 to add Server-Timing header [#108](https://github.com/signalfx/splunk-otel-java/pull/108)
+
+### Changed
+
+- Use upstream opentelemetry-java-instrumentation 0.16.1. [#117](https://github.com/signalfx/splunk-otel-java/pull/117)
+
+[Unreleased]: https://github.com/signalfx/splunk-otel-java/compare/v0.9.0...HEAD
+[v0.9.0]: https://github.com/signalfx/splunk-otel-java/compare/v0.8.0...v0.9.0
+[v0.8.0]: https://github.com/signalfx/splunk-otel-java/compare/v0.7.0...v0.8.0

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances
+  of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or email address,
+  without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for
+moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail
+address, posting via an official social media account, or acting as an
+appointed representative at an online or offline event. Representation of a
+project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at splunk-oss-admin@splunk.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
+available at https://www.contributor-covenant.org/version/2/0/code-of-conduct.html

CONTRIBUTING.md

@@ -0,0 +1,76 @@
+# Contributing Guidelines
+
+Thank you for your interest in contributing to our project! Whether it's a bug
+report, new feature, question, or additional documentation, we greatly value
+feedback and contributions from our community. Read through this document
+before submitting any issues or pull requests to ensure we have all the
+necessary information to effectively respond to your bug report or
+contribution.
+
+In addition to this document, please review our [Code of
+Conduct](CODE_OF_CONDUCT.md). For any code of conduct questions or comments
+please email oss@splunk.com.
+
+## Reporting Bugs/Feature Requests
+
+We welcome you to use the GitHub issue tracker to report bugs or suggest
+features. When filing an issue, please check existing open, or recently closed,
+issues to make sure somebody else hasn't already reported the issue. Please try
+to include as much information as you can. Details like these are incredibly
+useful:
+
+- A reproducible test case or series of steps
+- The version of our code being used
+- Any modifications you've made relevant to the bug
+- Anything unusual about your environment or deployment
+- Any known workarounds
+
+When filing an issue, please do *NOT* include:
+
+- Internal identifiers such as JIRA tickets
+- Any sensitive information related to your environment, users, etc.
+
+## Contributing via Pull Requests
+
+Contributions via Pull Requests (PRs) are much appreciated. Before sending us a
+pull request, please ensure that:
+
+1. You are working against the latest source on the `main` branch.
+2. You check existing open, and recently merged, pull requests to make sure
+   someone else hasn't addressed the problem already.
+3. You open an issue to discuss any significant work - we would hate for your
+   time to be wasted.
+4. You submit PRs that are easy to review and ideally less 500 lines of code.
+   Multiple PRs can be submitted for larger contributions.
+
+To send us a pull request, please:
+
+1. Fork the repository.
+2. Modify the source; please ensure a single change per PR. If you also
+   reformat all the code, it will be hard for us to focus on your change.
+3. Ensure local tests pass and add new tests related to the contribution.
+4. Commit to your fork using clear commit messages.
+5. Send us a pull request, answering any default questions in the pull request
+   interface.
+6. Pay attention to any automated CI failures reported in the pull request, and
+   stay involved in the conversation.
+
+GitHub provides additional documentation on [forking a
+repository](https://help.github.com/articles/fork-a-repo/) and [creating a pull
+request](https://help.github.com/articles/creating-a-pull-request/).
+
+## Finding contributions to work on
+
+Looking at the existing issues is a great way to find something to contribute
+on. As our projects, by default, use the default GitHub issue labels
+(enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at
+any 'help wanted' issues is a great place to start.
+
+## Licensing
+
+See the [LICENSE](LICENSE) file for our project's licensing. We will ask you to
+confirm the licensing of your contribution.
+
+We may ask you to sign a [Contributor License Agreement
+(CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) for larger
+changes.

README.md

@@ -9,7 +9,7 @@ distributed traces to Splunk APM.
 
 If you're currently using the SignalFx Java Agent and want to
 migrate to the Splunk Distribution of OpenTelemetry Java Instrumentation,
-see [Migrate from the SignalFx Java Agent](migration.md).
+see [Migrate from the SignalFx Java Agent](MIGRATING.md).
 
 This Splunk distribution comes with the following defaults:
 

RELEASING.md

@@ -1,3 +1,5 @@
+# Release Process
+
 ## Releasing a new version
 
 [This GitHub Action](.github/workflows/release.yaml) builds, uploads and releases a new version of
@@ -14,4 +16,11 @@ E.g. `v0.9.0`.
 Unless you have a specific reason to do otherwise, new to-be-released version should be obtained
 by incrementing the minor version of [the last released version](https://github.com/signalfx/splunk-otel-java/releases)
 * Push newly created tag by running `git push origin <tagname>`.
-* GitHub Action will kick in and do the rest.
+* GitHub Action will kick in and do the rest.
+
+## Post-release
+
+* Update the release notes for the latest release.
+* Update README.md with all changes (new configuration options, new upstream versions, etc)
+that happened in the latest release.
+* Update CHANGELOG.md and change the Unreleased section to reflect the latest tag.

SECURITY.md

@@ -0,0 +1,7 @@
+# Security
+
+## Reporting Security Issues
+
+Please *DO NOT* report security vulnerabilities with public GitHub issue
+reports. Please [report security issues here](
+https://www.splunk.com/en_us/product-security/report.html).