From 7a93658e4bee106005422a922c086e944f4ce628 Mon Sep 17 00:00:00 2001 From: Peter ONeill Date: Wed, 1 Dec 2021 19:58:01 +0200 Subject: [PATCH] Update Contributing Docs Signed-off-by: Peter ONeill --- docs/content/contrib-code.md | 152 ++++++++++++++++ ...{development.md => contrib-development.md} | 2 +- docs/content/contrib-docs.md | 68 +++++++ docs/content/contributing.md | 168 ++---------------- 4 files changed, 238 insertions(+), 152 deletions(-) create mode 100644 docs/content/contrib-code.md rename docs/content/{development.md => contrib-development.md} (99%) create mode 100644 docs/content/contrib-docs.md diff --git a/docs/content/contrib-code.md b/docs/content/contrib-code.md new file mode 100644 index 0000000000..29057242c3 --- /dev/null +++ b/docs/content/contrib-code.md @@ -0,0 +1,152 @@ +--- +title: Contributing Code +kind: contrib +weight: 3 +--- + +## Code Contributions + +If you are contributing code, please consider the following: + +- Most changes should be accompanied with tests. +- All commits must be signed off (see next section). +- Related commits must be squashed before they are merged. +- All tests must pass and there must be no warnings from the `make + check` target. + +If you are new to Go, consider reading [Effective +Go](https://golang.org/doc/effective_go.html) and [Go Code Review +Comments](https://github.com/golang/go/wiki/CodeReviewComments) for +guidance on writing idiomatic Go code. + +When you implement new features in OPA, consider whether the +types/functions you are adding need to be exported. Prefer +unexported types and functions as much as possible. + +If you need to share logic across multiple OPA packages, consider +implementing it inside of the +`github.com/open-policy-agent/opa/internal` package. The `internal` +package is not visible outside of OPA. + +Avoid adding thirdparty dependencies (vendoring). OPA is designed to be minimal, +lightweight, and easily embedded. Vendoring may make features _easier_ to +implement however they come with their own cost for both OPA developers and +OPA users (e.g., vendoring conflicts, security, debugging, etc.) + +### Commit Messages + +Commit messages should explain *why* the changes were made and should probably +look like this: + +``` +Description of the change in 50 characters or less + +More detail on what was changed. Provide some background on the issue +and describe how the changes address the issue. Feel free to use multiple +paragraphs but please keep each line under 72 characters or so. +``` + +If your changes are related to an open issue (bug or feature), please include +the following line at the end of your commit message: + +``` +Fixes # +``` + +If the changes are isolated to a specific OPA package or directory please +include a prefix on the first line of the commit message with the following +format: + +``` +: +``` + +For example, a change to the `ast` package: +``` +ast: Fix X when Y happens + + + +Fixes: #123 +Signed-off-by: Random J Developer +``` + +or a change in the OPA website content (found in `./docs/content`): +``` +docs/website: Add X to homepage for Y + + + +Fixes: #456 +Signed-off-by: Random J Developer +``` + +### Developer Certificate Of Origin + +The OPA project requires that contributors sign off on changes submitted to OPA +repositories. +The [Developer Certificate of Origin (DCO)](https://developercertificate.org/) +is a simple way to certify that you wrote or have the right to submit the code +you are contributing to the project. + +The DCO is a standard requirement for Linux Foundation and CNCF projects. + +You sign-off by adding the following to your commit messages: + + This is my commit message + + Signed-off-by: Random J Developer + +Git has a `-s` command line option to do this automatically. + + git commit -s -m 'This is my commit message' + +You can find the full text of the DCO here: https://developercertificate.org/ + +### Code Review + +Before a Pull Request is merged, it will undergo code review from other members +of the OPA community. In order to streamline the code review process, when +amending your Pull Request in response to a review, do not squash your changes +into relevant commits until it has been approved for merge. This allows the +reviewer to see what changes are new and removes the need to wade through code +that has not been modified to search for a small change. + +When adding temporary patches in response to review comments, consider +formatting the message subject like one of the following: + +- `Fixup into commit (squash before merge)` +- `Fixed changes requested by @username (squash before merge)` +- `Amended (squash before merge)` + +The purpose of these formats is to provide some context into the reason the +temporary commit exists, and to label it as needing squashed before a merge +is performed. + +It is worth noting that not all changes need be squashed before a merge is +performed. Some changes made as a result of review stand well on their own, +independent of other commits in the series. Such changes should be made into +their own commit and added to the PR. + +If your Pull Request is small though, it is acceptable to squash changes during +the review process. Use your judgement about what constitutes a small Pull +Request. If you aren't sure, send a message to the OPA slack or post a comment +on the Pull Request. + +## Contribution process + +Small bug fixes (or other small improvements) can be submitted directly via a +[Pull Request](https://github.com/open-policy-agent/opa/pulls) on GitHub. +You can expect at least one of the OPA maintainers to respond quickly. + +Before submitting large changes, please open an issue on GitHub outlining: + +- The use case that your changes are applicable to. +- Steps to reproduce the issue(s) if applicable. +- Detailed description of what your changes would entail. +- Alternative solutions or approaches if applicable. + +Use your judgement about what constitutes a large change. If you aren't sure, +send a message in +[#development](https://openpolicyagent.slack.com/archives/C02L1TLPN59) on Slack +or submit [an issue on GitHub](https://github.com/open-policy-agent/opa/issues). diff --git a/docs/content/development.md b/docs/content/contrib-development.md similarity index 99% rename from docs/content/development.md rename to docs/content/contrib-development.md index bcad583b00..b3f59ac21e 100644 --- a/docs/content/development.md +++ b/docs/content/contrib-development.md @@ -1,7 +1,7 @@ --- title: Development kind: contrib -weight: 2 +weight: 4 --- OPA is written in the [Go](https://golang.org) programming language. diff --git a/docs/content/contrib-docs.md b/docs/content/contrib-docs.md new file mode 100644 index 0000000000..e1d1629359 --- /dev/null +++ b/docs/content/contrib-docs.md @@ -0,0 +1,68 @@ +--- +title: Contributing Docs +kind: contrib +weight: 2 +--- + +Contributing to our docs is one of the best ways to get started contributing to the OPA project. The OPA docs are one of the first places most people go for help, so any changes are impactful for the community. Thanks in advance for contributing to the docs. + +## Sub-project docs + +Docs for the OPA sub-projects each have their own home. Check out their docs to see how to contribute. + +* [Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/) docs for Kubernetes Admission Control +* [Conftest](https://www.conftest.dev/) docs for validating your structured configuration data, like YAML and HCL files + + +## Docs File Structure + +- [devel/](https://github.com/open-policy-agent/opa/blob/main/docs/devel) - Developer documentation for OPA (not part of the website) +- [website/](https://github.com/open-policy-agent/opa/blob/main/docs/website) - This directory contains all of the Markdown, HTML, Sass/CSS, and other assets needed to build the [openpolicyagent.org](https://openpolicyagent.org) website. See the section below for steps to build the site and test documentation changes locally. This content is not versioned for each release, it is common scaffolding for the website. +- [content/](https://github.com/open-policy-agent/opa/blob/main/docs/content) - The raw OPA documentation can be found under the directory. This content is versioned for each release and should have all images and code snippets alongside the markdown content files. +- [website/data/integrations.yaml](https://github.com/open-policy-agent/opa/blob/main/docs/website/data/integrations.yaml) - Source for the integrations index. See [Integration Index](https://github.com/open-policy-agent/opa/blob/main/docs/README.md#integration-index) below for more details. + +## Markdown Page Structure + +Each page starts with a Frontmatter block that provides the necessary metadata to format the Docs website. For example, the frontmatter for this page is as follows: + +```YAML +--- +title: Contributing Docs #Title of the page +kind: contrib #Section the page belongs to +weight: 2 #Order the page should appear in the left hand nav +--- +``` + +After the Frontmatter block, each page uses standard markdown formatting. For a primer on Markdown, check out the [GitHub Markdown Guide](https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax). + +## Create a local branch + +To get started, fork the OPA repository and create a local branch for your Docs changes. Check out the [Development Guide](../development/#fork-clone-create-a-branch) if you need some help setting this up. + +## Update Existing Docs + +Navigate to the [content/](https://github.com/open-policy-agent/opa/blob/main/docs/content) folder in your local environment. Each top level item in the documentation nav will have an associated markdown file in the content folder. Locate the file you wish to update and confirm the title in the Frontmatter matches. Once you've located the correct page, edit the markdown page as necessary. + +## Adding New Pages + +In the case where you want to add a topic that doesn't fit nicely into any of the existing pages, it may make sense to add a new page. Create a markdown file in the content folder and add the appropriate Frontmatter heading. Aside from the title, you will need to specify the `kind` (section in the docs) and `weight` (order the page appears). + +## Test your changes + +Once you have made your updates, the next step is to test that they look as expected. To test your changes, generate a local preview with your updated files and preview them with Netlify. + +Summary of steps: +1. Install dependencies: [Hugo](#installing-hugo), [NodeJS](https://nodejs.org), and [Netlify CLI](https://www.netlify.com/products/dev/) +1. Build artifacts: `make build` +1. Generate HTML files: `make docs-serve-local` (*This can take up to 5 min*) +1. Start preview server: `netlify dev` + +For detailed instructions on setting up local preview, and remote previews with Netlify, check out the docs [README page](https://github.com/open-policy-agent/opa/blob/main/docs/README.md#how-to-edit-and-test). + +## Submit a Pull Request + +Once you've tested your changes and you're happy with how they look, commit them to your branch and open a pull request. If this is your first time opening a pull request with the OPA repository, check out the [Contributing Guide](../contributing). Once your PR has been received a Netlify preview will be automatically created, check the PR for a unique link. + +## Having trouble + +Reach out in the [#development](https://openpolicyagent.slack.com/archives/C02L1TLPN59) channel to ask for help. \ No newline at end of file diff --git a/docs/content/contributing.md b/docs/content/contributing.md index 72af8de0db..453fbc7aea 100644 --- a/docs/content/contributing.md +++ b/docs/content/contributing.md @@ -8,160 +8,26 @@ Thanks for your interest in contributing to the Open Policy Agent project! ## Where to start? -If you have questions, comments, or requests please file [an issue on -GitHub](https://github.com/open-policy-agent/opa/issues). +* Ask for help on the [OPA Discussions Board](https://github.com/open-policy-agent/feedback/discussions) +* Use [#development](https://openpolicyagent.slack.com/archives/C02L1TLPN59) in Slack to talk to the OPA maintainers and other contributors. +* File a [GitHub Issue](https://github.com/open-policy-agent/opa/issues) to request features or report bugs. +* Join the OPA bi-weekly meetings every other Tuesday at 10:00 (Pacific Timezone): + * [Meeting Notes](https://docs.google.com/document/d/1v6l2gmkRKAn5UIg3V2QdeeCcXMElxsNzEzDkVlWDVg8/edit?usp=sharing) + * [Zoom](https://zoom.us/j/97827947600) + * [Calendar Invite](https://calendar.google.com/event?action=TEMPLATE&tmeid=MnRvb2M4amtldXBuZ2E1azY0MTJndjh0ODRfMjAxODA5MThUMTcwMDAwWiBzdHlyYS5jb21fY28zOXVzc3VobnE2amUzN2l2dHQyYmNiZGdAZw&tmsrc=styra.com_co39ussuhnq6je37ivtt2bcbdg%40group.calendar.google.com&scp=ALL) -If you want to contribute code and you are new to the Go programming language, check out -the [development reference](../development/) for help getting started. - -We currently welcome contributions of all kinds. For example: - -- Development of features, bug fixes, and other improvements. -- Documentation including reference material and examples. -- Bug and feature reports. - -## Contribution process - -Small bug fixes (or other small improvements) can be submitted directly via a -[Pull Request](https://github.com/open-policy-agent/opa/pulls) on GitHub. -You can expect at least one of the OPA maintainers to respond quickly. - -Before submitting large changes, please open an issue on GitHub outlining: - -- The use case that your changes are applicable to. -- Steps to reproduce the issue(s) if applicable. -- Detailed description of what your changes would entail. -- Alternative solutions or approaches if applicable. - -Use your judgement about what constitutes a large change. If you aren't sure, -send a message to the [OPA slack](https://slack.openpolicyagent.org/) or submit -[an issue on GitHub](https://github.com/open-policy-agent/opa/issues). - -### Code Contributions - -If you are contributing code, please consider the following: - -- Most changes should be accompanied with tests. -- All commits must be signed off (see next section). -- Related commits must be squashed before they are merged. -- All tests must pass and there must be no warnings from the `make - check` target. - -If you are new to Go, consider reading [Effective -Go](https://golang.org/doc/effective_go.html) and [Go Code Review -Comments](https://github.com/golang/go/wiki/CodeReviewComments) for -guidance on writing idiomatic Go code. - -When you implement new features in OPA, consider whether the -types/functions you are adding need to be exported. Prefer -unexported types and functions as much as possible. - -If you need to share logic across multiple OPA packages, consider -implementing it inside of the -`github.com/open-policy-agent/opa/internal` package. The `internal` -package is not visible outside of OPA. - -Avoid adding thirdparty dependencies (vendoring). OPA is designed to be minimal, -lightweight, and easily embedded. Vendoring may make features _easier_ to -implement however they come with their own cost for both OPA developers and -OPA users (e.g., vendoring conflicts, security, debugging, etc.) - -### Commit Messages - -Commit messages should explain *why* the changes were made and should probably -look like this: - -``` -Description of the change in 50 characters or less - -More detail on what was changed. Provide some background on the issue -and describe how the changes address the issue. Feel free to use multiple -paragraphs but please keep each line under 72 characters or so. -``` - -If your changes are related to an open issue (bug or feature), please include -the following line at the end of your commit message: - -``` -Fixes # -``` -If the changes are isolated to a specific OPA package or directory please -include a prefix on the first line of the commit message with the following -format: - -``` -: -``` - -For example, a change to the `ast` package: -``` -ast: Fix X when Y happens - - - -Fixes: #123 -Signed-off-by: Random J Developer -``` - -or a change in the OPA website content (found in `./docs/content`): -``` -docs/website: Add X to homepage for Y - - - -Fixes: #456 -Signed-off-by: Random J Developer -``` - -### Developer Certificate Of Origin - -The OPA project requires that contributors sign off on changes submitted to OPA -repositories. -The [Developer Certificate of Origin (DCO)](https://developercertificate.org/) -is a simple way to certify that you wrote or have the right to submit the code -you are contributing to the project. - -The DCO is a standard requirement for Linux Foundation and CNCF projects. - -You sign-off by adding the following to your commit messages: - - This is my commit message - - Signed-off-by: Random J Developer - -Git has a `-s` command line option to do this automatically. - - git commit -s -m 'This is my commit message' - -You can find the full text of the DCO here: https://developercertificate.org/ - -### Code Review - -Before a Pull Request is merged, it will undergo code review from other members -of the OPA community. In order to streamline the code review process, when -amending your Pull Request in response to a review, do not squash your changes -into relevant commits until it has been approved for merge. This allows the -reviewer to see what changes are new and removes the need to wade through code -that has not been modified to search for a small change. - -When adding temporary patches in response to review comments, consider -formatting the message subject like one of the following: +If you want to contribute code and you are new to the Go programming language, check out +the [development reference](../contrib-development/) for help getting started. -- `Fixup into commit (squash before merge)` -- `Fixed changes requested by @username (squash before merge)` -- `Amended (squash before merge)` +## Other types of contributions -The purpose of these formats is to provide some context into the reason the -temporary commit exists, and to label it as needing squashed before a merge -is performed. +We welcome contributions of all kinds. For example: -It is worth noting that not all changes need be squashed before a merge is -performed. Some changes made as a result of review stand well on their own, -independent of other commits in the series. Such changes should be made into -their own commit and added to the PR. +- [Documentation](../contrib-docs) including reference material and examples. +- Help out other members in the OPA Slack Org and on the [GitHub Discussions Board](https://github.com/open-policy-agent/feedback/discussions) +- Spreading the word about OPA by speaking at conferences +- Adding integrations to the OPA [ecosystem](https://www.openpolicyagent.org/docs/latest/ecosystem/) +- Creating Blog and Videos to show how your organization has implemented OPA -If your Pull Request is small though, it is acceptable to squash changes during -the review process. Use your judgement about what constitutes a small Pull -Request. If you aren't sure, send a message to the OPA slack or post a comment -on the Pull Request. +If you're interested in any non-code contributions, please reach out on the #help channel on [Slack](https://slack.openpolicyagent.org/) \ No newline at end of file