Prepare OSS Files

- Updates the README to include current build and deploy instructions.

- Adds license, contributing guidelines, code of conduct, pull request template, CODEOWNERS, and the CLA agreement.

- Makes the registry PREFIX used in make container configurable by user.

- Adds README to cafe example

Author: Kate Osborn

.github/CODEOWNERS

@@ -0,0 +1 @@
+@pleshakov @f5yacobucci @kate-osborn

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,12 @@
+### 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/nginx-gateway-kubernetes/blob/main/CONTRIBUTING.md) doc
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] I have checked that all unit tests pass after adding my changes
+- [ ] I have updated necessary documentation
+- [ ] I have rebased my branch onto main
+- [ ] I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

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,80 @@
+# Contributing Guidelines
+
+The following is a set of guidelines for contributing to NGINX Kubernetes Gateway. 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](https://github.com/nginxinc/nginx-gateway-kubernetes/blob/master/CODE_OF_CONDUCT.md)
+
+[Contributor License Agreement](#contributor-license-agreement)
+
+## Ask a Question
+
+We will have a public forum soon where you can come and ask questions and have a discussion. For now please open an Issue on GitHub with the label `question`.
+
+## Getting Started
+
+Follow our [Installation Instructions](README.md#run-nginx-gateway) to get the NGINX Kubernetes Gateway up and running.
+
+### Project Structure
+
+* NGINX Kubernetes Gateway is written in Go and uses the open source NGINX software as the data plane.
+* The project follows a standard Go project layout
+    * The main code is found at `cmd/gateway/`
+    * The internal code is found at `internal/`
+    * Build files for Docker are found under `build/`
+    * Deployment yaml files are found at `deploy/`
+* We use [Go Modules](https://github.com/golang/go/wiki/Modules) for managing dependencies.
+* We use [Ginkgo](https://onsi.github.io/ginkgo/) and [Gomega](https://onsi.github.io/gomega/) for our BDD style unit tests. 
+
+## 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](https://github.com/nginxinc/nginx-gateway-kubernetes/blob/main/.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.
+
+## 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 summarised 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`
+
+## Contributor License Agreement
+
+Individuals or business entities who contribute to this project must have completed and submitted the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf) prior to their code submission being included in this project. 
+To submit, please print out the [F5® Contributor License Agreement](F5ContributorLicenseAgreement.pdf), fill in the required sections, sign, scan, and send executed CLA to [email protected].
+Please include your github handle in the CLA email.