Skip to content

Latest commit

 

History

History
265 lines (199 loc) · 11.8 KB

CONTRIBUTING.md

File metadata and controls

265 lines (199 loc) · 11.8 KB
Raw

Contributing to Ory Kubernetes Resources

Introduction

There are many ways in which you can contribute, beyond writing code. The goal of this document is to provide a high-level overview of how you can get involved.

Please note: We take Ory Kubernetes Resources's security and our users' trust very seriously. If you believe you have found a security issue in Ory Kubernetes Resources, please responsibly disclose by contacting us at [email protected].

First: As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a pull request.

If you are unsure, just ask or submit the issue or pull request anyways. You won't be yelled at for giving it your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions, and don't want a wall of rules to get in the way of that.

That said, if you want to ensure that a pull request is likely to be merged, talk to us! You can find out our thoughts and ensure that your contribution won't clash or be obviated by Ory Kubernetes Resources's normal direction. A great way to do this is via Ory Kubernetes Resources Discussions or the Ory Chat.

FAQ

How can I contribute?

If you want to start contributing code right away, we have a list of good first issues.

There are many other ways you can contribute without writing any code. Here are a few things you can do to help out:

  • Give us a star. It may not seem like much, but it really makes a difference. This is something that everyone can do to help out Ory Kubernetes Resources. Github stars help the project gain visibility and stand out.

  • Join the community. Sometimes helping people can be as easy as listening to their problems and offering a different perspective. Join our Slack, have a look at discussions in the forum and take part in our weekly hangout. More info on this in Communication.

  • Helping with open issues. We have a lot of open issues for Ory Kubernetes Resources and some of them may lack necessary information, some are duplicates of older issues. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem.

  • Reviewing documentation changes. Most documentation just needs a review for proper spelling and grammar. If you think a document can be improved in any way, feel free to hit the edit button at the top of the page. More info on contributing to documentation here.

  • Help with tests. Some pull requests may lack proper tests or test plans. These are needed for the change to be implemented safely.

Communication

We use Slack. You are welcome to drop in and ask questions, discuss bugs and feature requests, talk to other users of Ory, etc.

Check out Ory Kubernetes Resources Discussions. This is a great place for in-depth discussions and lots of code examples, logs and similar data.

You can also join our community hangout, if you want to speak to the Ory team directly or ask some questions. You can find more info on the hangouts in Slack.

If you want to receive regular notifications about updates to Ory Kubernetes Resources, consider joining the mailing list. We will only send you vital information on the projects that you are interested in.

Also follow us on twitter.

Contributing Code

Unless you are fixing a known bug, we strongly recommend discussing it with the core team via a GitHub issue or in our chat before getting started to ensure your work is consistent with Ory Kubernetes Resources's roadmap and architecture.

All contributions are made via pull requests. To make a pull request, you will need a GitHub account; if you are unclear on this process, see GitHub's documentation on forking and pull requests. Pull requests should be targeted at the master branch. Before creating a pull request, go through this checklist:

  1. Create a feature branch off of master so that changes do not get mixed up.
  2. Rebase your local changes against the master branch.
  3. Run the full project test suite with the go test -tags sqlite ./... (or equivalent) command and confirm that it passes.
  4. Run make format if a Makefile is available, gofmt -s if the project is written in Go, npm run format if the project is written for NodeJS.
  5. Ensure that each commit has a descriptive prefix. This ensures a uniform commit history and helps structure the changelog.
    Please refer to this list of prefixes for Kubernetes Resources for an overview.
  6. Sign-up with CircleCI so that it has access to your repository with the branch containing your PR. Simply creating a CircleCI account is sufficient for the CI jobs to run, you do not need to setup a CircleCI project for the branch.

If a pull request is not ready to be reviewed yet it should be marked as a "Draft".

Before your contributions can be reviewed you need to sign our Contributor License Agreement.

This agreement defines the terms under which your code is contributed to Ory. More specifically it declares that you have the right to, and actually do, grant us the rights to use your contribution. You can see the Apache 2.0 license under which our projects are published here.

When pull requests fail testing, authors are expected to update their pull requests to address the failures until the tests pass.

Pull requests eligible for review

  1. follow the repository's code formatting conventions;
  2. include tests which prove that the change works as intended and does not add regressions;
  3. document the changes in the code and/or the project's documentation;
  4. pass the CI pipeline;
  5. have signed our Contributor License Agreement;
  6. include a proper git commit message following the Conventional Commit Specification.

If all of these items are checked, the pull request is ready to be reviewed and you should change the status to "Ready for review" and request review from a maintainer.

Reviewers will approve the pull request once they are satisfied with the patch.

Documentation

Please provide documentation when changing, removing, or adding features. Documentation resides in the project's docs folder. Generate API and configuration reference documentation using cd docs; npm run gen.

For further instructions please head over to docs/README.md.

Disclosing vulnerabilities

Please disclose vulnerabilities exclusively to [email protected]. Do not use GitHub issues.

Code Style

Please follow these guidelines when formatting source code:

  • Go code should match the output of gofmt -s and pass golangci-lint run.
  • NodeJS and JavaScript code should be prettified using npm run format where appropriate.

Working with Forks

# First you clone the original repository
git clone [email protected]:ory/ory/k8s.git

# Next you add a git remote that is your fork:
git remote add fork [email protected]:<YOUR-GITHUB-USERNAME-HERE>/ory/k8s.git

# Next you fetch the latest changes from origin for master:
git fetch origin
git checkout master
git pull --rebase

# Next you create a new feature branch off of master:
git checkout my-feature-branch

# Now you do your work and commit your changes:
git add -A
git commit -a -m "fix: this is the subject line" -m "This is the body line. Closes #123"

# And the last step is pushing this to your fork
git push -u fork my-feature-branch

Now go to the project's GitHub Pull Request page and click "New pull request"

Conduct

Whether you are a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back.

  • We are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, disability, ethnicity, religion, or similar personal characteristic.
  • Please avoid using nicknames that might detract from a friendly, safe and welcoming environment for all.
  • Be kind and courteous. There is no need to be mean or rude.
  • We will exclude you from interaction if you insult, demean or harass anyone. In particular, we do not tolerate behavior that excludes people in socially marginalized groups.
  • Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or a member of the Ory Kubernetes Resources core team immediately.
  • Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.

We welcome discussion about creating a welcoming, safe, and productive environment for the community. If you have any questions, feedback, or concerns please let us know.