start netlify experiment

Signed-off-by: Surya Seetharaman <suryaseetharaman.9@gmail.com>

docs/blog/index.md

@@ -0,0 +1,2 @@
+# Blog
+

docs/governance/CODE_OF_CONDUCT.md

@@ -0,0 +1,133 @@
+
+# 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, caste, color, 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
+
+Community leaders 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.
+
+Community leaders 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.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement
+directly. Maintainers are identified in the [MAINTAINERS.md](MAINTAINERS.md) file and their contact information is on their GitHub profile page.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

docs/governance/CONTRIBUTING.md

@@ -0,0 +1,197 @@
+# Contributing Guide
+
+* [New Contributor Guide](#contributing-guide)
+  * [Ways to Contribute](#ways-to-contribute)
+  * [Find an Issue](#find-an-issue)
+  * [Ask for Help](#ask-for-help)
+  * [Pull Request Lifecycle](#pull-request-lifecycle)
+  * [Development Environment Setup](#development-environment-setup)
+  * [Sign Your Commits](#sign-your-commits)
+  * [Pull Request Checklist](#pull-request-checklist)
+
+Welcome! We are glad that you want to contribute to our project! 💖
+
+As you get started, you are in the best position to give us feedback on areas of
+our project that we need help with including:
+
+* Problems found during setting up a new developer environment
+* Gaps in our Quickstart Guide or documentation
+* Bugs in our automation scripts
+
+If anything doesn't make sense, or doesn't work when you run it, please open a
+bug report and let us know!
+
+## Ways to Contribute
+
+We welcome many different types of contributions including:
+
+* New features
+* Builds, CI/CD
+* Bug fixes
+* Documentation
+* Issue Triage
+* Answering questions on Slack/Mailing List
+* Web design
+* Communications / Social Media / Blog Posts
+* Release management
+
+Not everything happens through a GitHub pull request. Please come to our
+[meetings](./MEETINGS.md) or [contact us](https://ovn-org.slack.com/archives/C010SQ5FSNL) and let's discuss how we can work
+together. 
+
+### Come to Meetings
+
+Absolutely everyone is welcome to come to any of our meetings. You never need an
+invite to join us. In fact, we want you to join us, even if you don’t have
+anything you feel like you want to contribute. Just being there is enough!
+
+You can find out more about our meetings [here](./MEETINGS.md). You don’t have to turn on
+your video. The first time you come, introducing yourself is more than enough.
+Over time, we hope that you feel comfortable voicing your opinions, giving
+feedback on others’ ideas, and even sharing your own ideas, and experiences.
+
+## Find an Issue
+
+We have good first issues for new contributors and help wanted issues suitable
+for any contributor. [good first issue](https://github.com/ovn-org/ovn-kubernetes/labels/good%20first%20issue) has extra information to
+help you make your first contribution. [help wanted](https://github.com/ovn-org/ovn-kubernetes/labels/help%20wanted) are issues
+suitable for someone who isn't a core maintainer and is good to move onto after
+your first pull request.
+
+Sometimes there won’t be any issues with these labels. That’s ok! There is
+likely still something for you to work on. If you want to contribute but you
+don’t know where to start or can't find a suitable issue, you can you can reach out to us on [Slack](https://ovn-org.slack.com/) and we will be happy to help.
+
+Once you see an issue that you'd like to work on, please post a comment saying
+that you want to work on it. Something like "I want to work on this" is fine.
+
+## Ask for Help
+
+The best way to reach us with a question when contributing is to ask on:
+
+* The original github issue
+* The developer mailing list (mailing-list: https://groups.google.com/g/ovn-kubernetes)
+* Our Slack channel (workspace: https://ovn-org.slack.com/, channel: #ovn-kubernetes)
+
+## Pull Request Lifecycle
+
+1. When you open a PR a maintainer will automatically be assigned for review
+2. Make sure that your PR is passing CI - if you need help with failing checks please feel free to ask!
+3. Once it is passing all CI checks, a maintainer will review your PR and you may be asked to make changes.
+4. When you have received at least one approval from a maintainer, that maintainer will merge your PR.
+
+In some cases, other changes may conflict with your PR. If this happens, you will get notified by a comment in the issue that your PR requires a rebase, and the `needs-rebase` label will be applied. Once a rebase has been performed, this label will be automatically removed.
+
+## Development Environment Setup
+
+You can easily setup a developer environment by following the instructions [here](https://github.com/ovn-org/ovn-kubernetes/blob/master/docs/kind.md).
+
+## Sign Your Commits
+
+### DCO
+Licensing is important to open source projects. It provides some assurances that
+the software will continue to be available based under the terms that the
+author(s) desired. We require that contributors sign off on commits submitted to
+our project's repositories. The [Developer Certificate of Origin
+(DCO)](https://probot.github.io/apps/dco/) is a way to certify that you wrote and
+have the right to contribute the code you are submitting to the project.
+
+You sign-off by adding the following to your commit messages. Your sign-off must
+match the git user and email associated with the commit.
+
+    This is my commit message
+
+    Signed-off-by: Your Name <your.name@example.com>
+
+Git has a `-s` command line option to do this automatically:
+
+    git commit -s -m 'This is my commit message'
+
+If you forgot to do this and have not yet pushed your changes to the remote
+repository, you can amend your commit with the sign-off by running 
+
+    git commit --amend -s 
+
+## Logical Grouping of Commits
+
+It is a recommended best practice to keep your changes as logically grouped as
+possible within individual commits. If while you're developing you prefer doing
+a number of commits that are "checkpoints" and don't represent a single logical
+change, please squash those together before asking for a review.
+When addressing review comments, please perform an interactive rebase and edit commits directly rather than adding new commits with messages like "Fix review comments".
+
+## Commit message guidelines
+
+A good commit message should describe what changed and why.
+
+1. The first line should:
+
+* contain a short description of the change (preferably 50 characters or less,
+    and no more than 72 characters)
+* be entirely in lowercase with the exception of proper nouns, acronyms, and
+    the words that refer to code, like areas/function/variable names
+* be prefixed with the name of the sub component being changed
+
+  Examples:
+
+  * networkpolicy: validate ipBlock strictly
+  * egressip: fix frequently rebalancing IPs
+  * services: fix etp=local + session-affnity integration
+
+2. Keep the second line blank.
+3. Wrap all other lines at 72 columns (except for long URLs).
+4. If your patch fixes an open issue, you can add a reference to it at the end
+   of the log. Use the `Fixes: #` prefix and the issue number. For other
+   references use `Refs: #`. `Refs` may include multiple issues, separated by a
+   comma.
+
+   Examples:
+
+   * `Fixes: #1337`
+   * `Refs: #1234`
+
+Sample complete commit message:
+
+```txt
+subcomponent: explain the commit in one line
+
+Body of commit message is a few lines of text, explaining things
+in more detail, possibly giving some background about the issue
+being fixed, etc.
+
+The body of the commit message can be several paragraphs, and
+please do proper word-wrap and keep columns shorter than about
+72 characters or so. That way, `git log` will show things
+nicely even when it is indented.
+
+Fixes: #1337
+Refs: #453, #154
+```
+
+## Pull Request Checklist
+
+When you submit your pull request, or you push new commits to it, our automated
+systems will run some checks on your new code. We require that your pull request
+passes these checks, but we also have more criteria than just that before we can
+accept and merge it. We recommend that you check the following things locally
+before you submit your code:
+
+* Verify that Go code has been formatted and linted
+
+```console
+cd ovn-kubernetes/go-controller/
+make lint
+```
+
+* If you are introducing new CRDs verify that Yaml files have been formatted (see
+  [codegen generator](https://github.com/ovn-org/ovn-kubernetes/blob/master/docs/developer.md#generating-crd-yamls-using-codegen))
+* Verify that unit tests are passing locally
+
+```console
+cd ovn-kubernetes/go-controller/
+make test
+```
+
+* All modular changes must be accompanied by new unit tests if they don't exist already.
+
+* All functional changes and new features must be accompanied by extensive end-to-end test coverage