Add standard files (#3)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,26 @@
+---
+name: Bug report
+about: Create a report to help us improve
+label: bug
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+
+Steps to reproduce the behavior, such as:
+
+1. I used the library
+2. Returns a panic
+3. Here is the stacktrace
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Your environment**
+
+- Version of telemetry-exporter
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+label: enhancement
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,16 @@
+### Proposed changes
+
+Describe the use case and detail of the change. If this PR addresses an issue on GitHub, make sure to include a link to
+that issue here in this description (not in the title of the PR).
+
+### Checklist
+
+Before creating a PR, run through this checklist and mark each as complete.
+
+- [ ] I have read the [CONTRIBUTING](https://github.com/nginxinc/telemetry-exporter/blob/main/CONTRIBUTING.md)
+      guide
+- [ ] I have proven my fix is effective or that my feature works
+- [ ] I have checked that all unit tests pass after adding my changes
+- [ ] I have ensured the README is up to date
+- [ ] I have rebased my branch onto main
+- [ ] I will ensure my PR is targeting the main branch and pulling from my branch on my own fork

CODEOWNERS

@@ -0,0 +1 @@
+* @nginxinc/integrations

CODE_OF_CONDUCT.md

@@ -0,0 +1,75 @@
+# Code of Conduct
+
+This project and everyone participating in it is governed by this code.
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, 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.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+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, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project 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 [mailto:[email protected]]. 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 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

CONTRIBUTING.md

@@ -0,0 +1,83 @@
+# Contributing Guidelines
+
+The following is a set of guidelines for contributing to the NGINX Telemetry Exporter. We really appreciate that you are
+considering contributing!
+
+## Table Of Contents
+
+[Ask a Question](#ask-a-question)
+
+[Getting Started](#getting-started)
+
+[Contributing](#contributing)
+
+[Style Guides](#style-guides)
+
+- [Git Style Guide](#git-style-guide)
+- [Go Style Guide](#go-style-guide)
+
+[Code of Conduct](CODE_OF_CONDUCT.md)
+
+## Ask a Question
+
+To ask a question please use [Github Discussions](https://github.com/nginxinc/telemetry-exporter/discussions).
+
+You can also join our [Community Slack](https://community.nginx.org/joinslack) which has a wider NGINX audience.
+
+Please reserve GitHub issues for feature requests and bugs rather than general questions.
+
+## Getting Started
+
+Read the usage and testing steps in the [README](README.md).
+
+## Contributing
+
+### Report a Bug
+
+To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please
+ensure the issue has not already been reported.
+
+### Suggest an Enhancement
+
+To suggest an enhancement, please create an issue on GitHub with the label `enhancement` using the available feature
+issue template.
+
+### Open a Pull Request
+
+- Fork the repo, create a branch, submit a PR when your changes are tested and ready for review
+- Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md)
+
+> **Note**
+>
+> If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion
+> about the feature.
+
+### Issue lifecycle
+
+- When an issue or PR is created, it will be triaged by the core development team and assigned a label to indicate the
+  type of issue it is (bug, feature request, etc) and to determine the milestone. Please see the [Issue
+  Lifecycle](ISSUE_LIFECYCLE.md) document for more information.
+
+## Style Guides
+
+### Git Style Guide
+
+- Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before
+  submitting a PR
+- Follow the guidelines of writing a good commit message as described here <https://chris.beams.io/posts/git-commit/>
+  and summarized in the next few points
+  - In the subject line, use the present tense ("Add feature" not "Added feature")
+  - In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...")
+  - Limit the subject line to 72 characters or less
+  - Reference issues and pull requests liberally after the subject line
+  - Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in
+    your text editor to write a good message instead of `git commit -am`)
+
+### Go Style Guide
+
+- Run `gofmt` over your code to automatically resolve a lot of style issues. Most editors support this running
+  automatically when saving a code file.
+- Run `go lint` and `go vet` on your code too to catch any other issues.
+- Follow this guide on some good practice and idioms for Go - <https://github.com/golang/go/wiki/CodeReviewComments>
+- To check for extra issues, install [golangci-lint](https://github.com/golangci/golangci-lint) and run `make lint` or
+  `golangci-lint run`

ISSUE_LIFECYCLE.md

@@ -0,0 +1,53 @@
+# Issue Lifecycle
+
+To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on
+this project, we use the following issue lifecycle. (Note: The issue _creator_ refers to the community member that
+created the issue. The issue _owner_ refers to the NGINX team member that is responsible for managing the issue
+lifecycle.)
+
+1. New issue created by community member.
+
+2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the
+   issue through the subsequent stages in the issue lifecycle.
+
+3. Determine issue type: This is done with automation where possible, and manually by the owner where necessary. The
+   associated label is applied to the issue.
+
+   Possible Issue Types:
+
+   - `needs more info`: The owner should use the issue to request information from the creator. If we don't receive the
+     needed information within 7 days, automation closes the issue.
+
+   - `bug`: The implementation of a feature is not correct.
+
+   - `proposal`: Request for a change. This can be a new feature, tackling technical debt, documentation changes, or
+     improving existing features.
+
+   - `question`: The owner converts the issue to a github discussion and engages the creator.
+
+4. Determine milestone: The owner, in collaboration with the wider team (PM & engineering), determines what milestone to
+   attach to an issue. Generally, milestones correspond to product releases - however there are two 'magic' milestones
+   with special meanings (not tied to a specific release):
+
+   - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the
+     implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our
+     roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every
+     quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some
+     `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes
+     clear that they do not align with our evolving roadmap.
+
+   - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in
+     the issue and wants the community to weigh in before we make our final decision.
+
+   `backlog` issues can be labeled by the owner as `help wanted` and/or `good first issue` as appropriate.
+
+5. Promotion of `backlog candidate` issue to `backlog` issue: If an issue labelled `backlog candidate` receives more
+   than 30 upvotes within 60 days, we promote the issue by applying the `backlog` label. While issues promoted in this
+   manner have not been committed to a particular release, we welcome PRs from the community on them.
+
+   If an issue does not make our roadmap and has not been moved to a discussion, it is closed with the label `out of
+scope`. The goal is to get every issue in the issues list to one of the following end states:
+
+   - An assigned release.
+   - The `backlog` label.
+   - Closed as `out of scope`.

SECURITY.md

@@ -0,0 +1,18 @@
+# Security Policy
+
+## Supported Versions
+
+We advise users to use the most recent release of NGINX Telemetry Exporter. This project is not covered by the NGINX
+Plus support contract.
+
+## Reporting a Vulnerability
+
+The F5 Security Incident Response Team (F5 SIRT) has an email alias that makes it easy to report potential security
+vulnerabilities.
+
+- If you’re an F5 customer with an active support contract, please contact [F5 Technical
+  Support](https://www.f5.com/services/support).
+- If you aren’t an F5 customer, please report any potential or current instances of security vulnerabilities with any F5
+  product to the F5 Security Incident Response Team at <[email protected]>
+
+For more information visit <https://www.f5.com/services/support/report-a-vulnerability>