From 776c8d43598a03ca8ac85ce6895dfc11a3f0c4e1 Mon Sep 17 00:00:00 2001 From: ory-bot <60093411+ory-bot@users.noreply.github.com> Date: Tue, 31 Dec 2024 10:01:29 +0000 Subject: [PATCH] chore: update repository templates to https://github.com/ory/meta/commit/a5e8b9ab819fac595e44e18edefcfb1363f9a021 --- .github/FUNDING.yml | 3 + .github/ISSUE_TEMPLATE/BUG-REPORT.yml | 122 ++++++++ .github/ISSUE_TEMPLATE/DESIGN-DOC.yml | 125 +++++++++ .github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml | 86 ++++++ .github/ISSUE_TEMPLATE/config.yml | 14 + .github/auto_assign.yml | 16 ++ .github/config.yml | 6 + .github/pull_request_template.md | 51 ++++ .github/workflows/closed_references.yml | 30 ++ .github/workflows/conventional_commits.yml | 59 ++++ .github/workflows/labels.yml | 25 ++ .github/workflows/licenses.yml | 28 ++ .github/workflows/stale.yml | 47 ++++ .reference-ignore | 3 + CODE_OF_CONDUCT.md | 145 ++++++++++ CONTRIBUTING.md | 306 +++++++++++++++------ LICENSE | 1 - SECURITY.md | 56 ++++ 18 files changed, 1045 insertions(+), 78 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/BUG-REPORT.yml create mode 100644 .github/ISSUE_TEMPLATE/DESIGN-DOC.yml create mode 100644 .github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml create mode 100644 .github/ISSUE_TEMPLATE/config.yml create mode 100644 .github/auto_assign.yml create mode 100644 .github/config.yml create mode 100644 .github/pull_request_template.md create mode 100644 .github/workflows/closed_references.yml create mode 100644 .github/workflows/conventional_commits.yml create mode 100644 .github/workflows/labels.yml create mode 100644 .github/workflows/licenses.yml create mode 100644 .github/workflows/stale.yml create mode 100644 .reference-ignore create mode 100644 CODE_OF_CONDUCT.md create mode 100644 SECURITY.md diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index eacb8f4..c440360 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,3 +1,6 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/FUNDING.yml + # These are supported funding model platforms # github: diff --git a/.github/ISSUE_TEMPLATE/BUG-REPORT.yml b/.github/ISSUE_TEMPLATE/BUG-REPORT.yml new file mode 100644 index 0000000..69b1a7c --- /dev/null +++ b/.github/ISSUE_TEMPLATE/BUG-REPORT.yml @@ -0,0 +1,122 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/BUG-REPORT.yml + +description: "Create a bug report" +labels: + - bug +name: "Bug Report" +body: + - attributes: + value: "Thank you for taking the time to fill out this bug report!\n" + type: markdown + - attributes: + label: "Preflight checklist" + options: + - label: + "I could not find a solution in the existing issues, docs, nor + discussions." + required: true + - label: + "I agree to follow this project's [Code of + Conduct](https://github.com/ory/ladon/blob/master/CODE_OF_CONDUCT.md)." + required: true + - label: + "I have read and am following this repository's [Contribution + Guidelines](https://github.com/ory/ladon/blob/master/CONTRIBUTING.md)." + required: true + - label: + "I have joined the [Ory Community Slack](https://slack.ory.sh)." + - label: + "I am signed up to the [Ory Security Patch + Newsletter](https://www.ory.sh/l/sign-up-newsletter)." + id: checklist + type: checkboxes + - attributes: + description: + "Enter the slug or API URL of the affected Ory Network project. Leave + empty when you are self-hosting." + label: "Ory Network Project" + placeholder: "https://.projects.oryapis.com" + id: ory-network-project + type: input + - attributes: + description: "A clear and concise description of what the bug is." + label: "Describe the bug" + placeholder: "Tell us what you see!" + id: describe-bug + type: textarea + validations: + required: true + - attributes: + description: | + Clear, formatted, and easy to follow steps to reproduce the behavior: + placeholder: | + Steps to reproduce the behavior: + + 1. Run `docker run ....` + 2. Make API Request to with `curl ...` + 3. Request fails with response: `{"some": "error"}` + label: "Reproducing the bug" + id: reproduce-bug + type: textarea + validations: + required: true + - attributes: + description: + "Please copy and paste any relevant log output. This will be + automatically formatted into code, so no need for backticks. Please + redact any sensitive information" + label: "Relevant log output" + render: shell + placeholder: | + log=error .... + id: logs + type: textarea + - attributes: + description: + "Please copy and paste any relevant configuration. This will be + automatically formatted into code, so no need for backticks. Please + redact any sensitive information!" + label: "Relevant configuration" + render: yml + placeholder: | + server: + admin: + port: 1234 + id: config + type: textarea + - attributes: + description: "What version of our software are you running?" + label: Version + id: version + type: input + validations: + required: true + - attributes: + label: "On which operating system are you observing this issue?" + options: + - Ory Network + - macOS + - Linux + - Windows + - FreeBSD + - Other + id: operating-system + type: dropdown + - attributes: + label: "In which environment are you deploying?" + options: + - Ory Network + - Docker + - "Docker Compose" + - "Kubernetes with Helm" + - Kubernetes + - Binary + - Other + id: deployment + type: dropdown + - attributes: + description: "Add any other context about the problem here." + label: Additional Context + id: additional + type: textarea diff --git a/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml b/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml new file mode 100644 index 0000000..8d24ee2 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml @@ -0,0 +1,125 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml + +description: + "A design document is needed for non-trivial changes to the code base." +labels: + - rfc +name: "Design Document" +body: + - attributes: + value: | + Thank you for writing this design document. + + One of the key elements of Ory's software engineering culture is the use of defining software designs through design docs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions. + + Ory is leaning heavily on [Google's design docs process](https://www.industrialempathy.com/posts/design-docs-at-google/) + and [Golang Proposals](https://github.com/golang/proposal). + + Writing a design doc before contributing your change ensures that your ideas are checked with + the community and maintainers. It will save you a lot of time developing things that might need to be changed + after code reviews, and your pull requests will be merged faster. + type: markdown + - attributes: + label: "Preflight checklist" + options: + - label: + "I could not find a solution in the existing issues, docs, nor + discussions." + required: true + - label: + "I agree to follow this project's [Code of + Conduct](https://github.com/ory/ladon/blob/master/CODE_OF_CONDUCT.md)." + required: true + - label: + "I have read and am following this repository's [Contribution + Guidelines](https://github.com/ory/ladon/blob/master/CONTRIBUTING.md)." + required: true + - label: + "I have joined the [Ory Community Slack](https://slack.ory.sh)." + - label: + "I am signed up to the [Ory Security Patch + Newsletter](https://www.ory.sh/l/sign-up-newsletter)." + id: checklist + type: checkboxes + - attributes: + description: + "Enter the slug or API URL of the affected Ory Network project. Leave + empty when you are self-hosting." + label: "Ory Network Project" + placeholder: "https://.projects.oryapis.com" + id: ory-network-project + type: input + - attributes: + description: | + This section gives the reader a very rough overview of the landscape in which the new system is being built and what is actually being built. This isn’t a requirements doc. Keep it succinct! The goal is that readers are brought up to speed but some previous knowledge can be assumed and detailed info can be linked to. This section should be entirely focused on objective background facts. + label: "Context and scope" + id: scope + type: textarea + validations: + required: true + + - attributes: + description: | + A short list of bullet points of what the goals of the system are, and, sometimes more importantly, what non-goals are. Note, that non-goals aren’t negated goals like “The system shouldn’t crash”, but rather things that could reasonably be goals, but are explicitly chosen not to be goals. A good example would be “ACID compliance”; when designing a database, you’d certainly want to know whether that is a goal or non-goal. And if it is a non-goal you might still select a solution that provides it, if it doesn’t introduce trade-offs that prevent achieving the goals. + label: "Goals and non-goals" + id: goals + type: textarea + validations: + required: true + + - attributes: + description: | + This section should start with an overview and then go into details. + The design doc is the place to write down the trade-offs you made in designing your software. Focus on those trade-offs to produce a useful document with long-term value. That is, given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals. + + The point of writing a document over a more formal medium is to provide the flexibility to express the problem at hand in an appropriate manner. Because of this, there is no explicit guidance on how to actually describe the design. + label: "The design" + id: design + type: textarea + validations: + required: true + + - attributes: + description: | + If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead, focus on the parts that are relevant to the design and its trade-offs. + label: "APIs" + id: apis + type: textarea + + - attributes: + description: | + Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead, focus on the parts that are relevant to the design and its trade-offs. + label: "Data storage" + id: persistence + type: textarea + + - attributes: + description: | + Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the feasibility of the design. + label: "Code and pseudo-code" + id: pseudocode + type: textarea + + - attributes: + description: | + One of the primary factors that would influence the shape of a software design and hence the design doc, is the degree of constraint of the solution space. + + On one end of the extreme is the “greenfield software project”, where all we know are the goals, and the solution can be whatever makes the most sense. Such a document may be wide-ranging, but it also needs to quickly define a set of rules that allow zooming in on a manageable set of solutions. + + On the other end are systems where the possible solutions are very well defined, but it isn't at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn't designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language. + + In this situation, you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are great, and hence such a document should focus on selecting the best way given all identified trade-offs. + label: "Degree of constraint" + id: constrait + type: textarea + + - attributes: + description: | + This section lists alternative designs that would have reasonably achieved similar outcomes. The focus should be on the trade-offs that each respective design makes and how those trade-offs led to the decision to select the design that is the primary topic of the document. + + While it is fine to be succinct about a solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals. + + label: Alternatives considered + id: alternatives + type: textarea diff --git a/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml b/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml new file mode 100644 index 0000000..a0de2ce --- /dev/null +++ b/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml @@ -0,0 +1,86 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml + +description: + "Suggest an idea for this project without a plan for implementation" +labels: + - feat +name: "Feature Request" +body: + - attributes: + value: | + Thank you for suggesting an idea for this project! + + If you already have a plan to implement a feature or a change, please create a [design document](https://github.com/aeneasr/gh-template-test/issues/new?assignees=&labels=rfc&template=DESIGN-DOC.yml) instead if the change is non-trivial! + type: markdown + - attributes: + label: "Preflight checklist" + options: + - label: + "I could not find a solution in the existing issues, docs, nor + discussions." + required: true + - label: + "I agree to follow this project's [Code of + Conduct](https://github.com/ory/ladon/blob/master/CODE_OF_CONDUCT.md)." + required: true + - label: + "I have read and am following this repository's [Contribution + Guidelines](https://github.com/ory/ladon/blob/master/CONTRIBUTING.md)." + required: true + - label: + "I have joined the [Ory Community Slack](https://slack.ory.sh)." + - label: + "I am signed up to the [Ory Security Patch + Newsletter](https://www.ory.sh/l/sign-up-newsletter)." + id: checklist + type: checkboxes + - attributes: + description: + "Enter the slug or API URL of the affected Ory Network project. Leave + empty when you are self-hosting." + label: "Ory Network Project" + placeholder: "https://.projects.oryapis.com" + id: ory-network-project + type: input + - attributes: + description: + "Is your feature request related to a problem? Please describe." + label: "Describe your problem" + placeholder: + "A clear and concise description of what the problem is. Ex. I'm always + frustrated when [...]" + id: problem + type: textarea + validations: + required: true + - attributes: + description: | + Describe the solution you'd like + placeholder: | + A clear and concise description of what you want to happen. + label: "Describe your ideal solution" + id: solution + type: textarea + validations: + required: true + - attributes: + description: "Describe alternatives you've considered" + label: "Workarounds or alternatives" + id: alternatives + type: textarea + validations: + required: true + - attributes: + description: "What version of our software are you running?" + label: Version + id: version + type: input + validations: + required: true + - attributes: + description: + "Add any other context or screenshots about the feature request here." + label: Additional Context + id: additional + type: textarea diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml new file mode 100644 index 0000000..1e3e292 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -0,0 +1,14 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/config.yml + +blank_issues_enabled: false +contact_links: + - name: Ory ladon Forum + url: https://github.com/orgs/ory/discussions + about: + Please ask and answer questions here, show your implementations and + discuss ideas. + - name: Ory Chat + url: https://www.ory.sh/chat + about: + Hang out with other Ory community members to ask and answer questions. diff --git a/.github/auto_assign.yml b/.github/auto_assign.yml new file mode 100644 index 0000000..c6cf23b --- /dev/null +++ b/.github/auto_assign.yml @@ -0,0 +1,16 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/auto_assign.yml + +# Set to true to add reviewers to pull requests +addReviewers: true + +# Set to true to add assignees to pull requests +addAssignees: true + +# A list of reviewers to be added to pull requests (GitHub user name) +assignees: + - ory/maintainers + +# A number of reviewers added to the pull request +# Set 0 to add all the reviewers (default: 0) +numberOfReviewers: 0 diff --git a/.github/config.yml b/.github/config.yml new file mode 100644 index 0000000..4fed118 --- /dev/null +++ b/.github/config.yml @@ -0,0 +1,6 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/config.yml + +todo: + keyword: "@todo" + label: todo diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..0796297 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,51 @@ + + +## Related Issue or Design Document + + + +## Checklist + + + +- [ ] I have read the [contributing guidelines](../blob/master/CONTRIBUTING.md) and signed the CLA. +- [ ] I have referenced an issue containing the design document if my change introduces a new feature. +- [ ] I have read the [security policy](../security/policy). +- [ ] I confirm that this pull request does not address a security vulnerability. + If this pull request addresses a security vulnerability, + I confirm that I got approval (please contact [security@ory.sh](mailto:security@ory.sh)) from the maintainers to push the changes. +- [ ] I have added tests that prove my fix is effective or that my feature works. +- [ ] I have added the necessary documentation within the code base (if appropriate). + +## Further comments + + diff --git a/.github/workflows/closed_references.yml b/.github/workflows/closed_references.yml new file mode 100644 index 0000000..9a1b483 --- /dev/null +++ b/.github/workflows/closed_references.yml @@ -0,0 +1,30 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/closed_references.yml + +name: Closed Reference Notifier + +on: + schedule: + - cron: "0 0 * * *" + workflow_dispatch: + inputs: + issueLimit: + description: Max. number of issues to create + required: true + default: "5" + +jobs: + find_closed_references: + if: github.repository_owner == 'ory' + runs-on: ubuntu-latest + name: Find closed references + steps: + - uses: actions/checkout@v2 + - uses: actions/setup-node@v2-beta + with: + node-version: "14" + - uses: ory/closed-reference-notifier@v1 + with: + token: ${{ secrets.GITHUB_TOKEN }} + issueLabels: upstream,good first issue,help wanted + issueLimit: ${{ github.event.inputs.issueLimit || '5' }} diff --git a/.github/workflows/conventional_commits.yml b/.github/workflows/conventional_commits.yml new file mode 100644 index 0000000..c4d3905 --- /dev/null +++ b/.github/workflows/conventional_commits.yml @@ -0,0 +1,59 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/conventional_commits.yml + +name: Conventional commits + +# This GitHub CI Action enforces that pull request titles follow conventional commits. +# More info at https://www.conventionalcommits.org. +# +# The Ory-wide defaults for commit titles and scopes are below. +# Your repository can add/replace elements via a configuration file at the path below. +# More info at https://github.com/ory/ci/blob/master/conventional_commit_config/README.md + +on: + pull_request_target: + types: + - edited + - opened + - ready_for_review + - reopened + # pull_request: # for debugging, uses config in local branch but supports only Pull Requests from this repo + +jobs: + main: + name: Validate PR title + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - id: config + uses: ory/ci/conventional_commit_config@master + with: + config_path: .github/conventional_commits.json + default_types: | + feat + fix + revert + docs + style + refactor + test + build + autogen + security + ci + chore + default_scopes: | + deps + docs + default_require_scope: false + - uses: amannn/action-semantic-pull-request@v4 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + with: + types: ${{ steps.config.outputs.types }} + scopes: ${{ steps.config.outputs.scopes }} + requireScope: ${{ steps.config.outputs.requireScope }} + subjectPattern: ^(?![A-Z]).+$ + subjectPatternError: | + The subject should start with a lowercase letter, yours is uppercase: + "{subject}" diff --git a/.github/workflows/labels.yml b/.github/workflows/labels.yml new file mode 100644 index 0000000..e903667 --- /dev/null +++ b/.github/workflows/labels.yml @@ -0,0 +1,25 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/labels.yml + +name: Synchronize Issue Labels + +on: + workflow_dispatch: + push: + branches: + - master + +jobs: + milestone: + if: github.repository_owner == 'ory' + name: Synchronize Issue Labels + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v2 + - name: Synchronize Issue Labels + uses: ory/label-sync-action@v0 + with: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + dry: false + forced: true diff --git a/.github/workflows/licenses.yml b/.github/workflows/licenses.yml new file mode 100644 index 0000000..0a12162 --- /dev/null +++ b/.github/workflows/licenses.yml @@ -0,0 +1,28 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/licenses.yml + +name: Licenses + +on: + pull_request: + push: + branches: + - main + - master + +jobs: + licenses: + name: License compliance + runs-on: ubuntu-latest + steps: + - name: Install script + uses: ory/ci/licenses/setup@master + with: + token: ${{ secrets.ORY_BOT_PAT || secrets.GITHUB_TOKEN }} + - name: Check licenses + uses: ory/ci/licenses/check@master + - name: Write, commit, push licenses + uses: ory/ci/licenses/write@master + if: + ${{ github.ref == 'refs/heads/main' || github.ref == + 'refs/heads/master' }} diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml new file mode 100644 index 0000000..ac48a5e --- /dev/null +++ b/.github/workflows/stale.yml @@ -0,0 +1,47 @@ +# AUTO-GENERATED, DO NOT EDIT! +# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/workflows/stale.yml + +name: "Close Stale Issues" +on: + workflow_dispatch: + schedule: + - cron: "0 0 * * *" + +jobs: + stale: + if: github.repository_owner == 'ory' + runs-on: ubuntu-latest + steps: + - uses: actions/stale@v4 + with: + repo-token: ${{ secrets.GITHUB_TOKEN }} + stale-issue-message: | + Hello contributors! + + I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue + + - open a PR referencing and resolving the issue; + - leave a comment on it and discuss ideas on how you could contribute towards resolving it; + - leave a comment and describe in detail why this issue is critical for your use case; + - open a new issue with updated details and a plan for resolving the issue. + + Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic. + + Unfortunately, [burnout](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes) has become a [topic](https://opensource.guide/best-practices/#its-okay-to-hit-pause) of [concern](https://docs.brew.sh/Maintainers-Avoiding-Burnout) amongst open-source projects. + + It can lead to severe personal and health issues as well as [opening](https://haacked.com/archive/2019/05/28/maintainer-burnout/) catastrophic [attack vectors](https://www.gradiant.org/en/blog/open-source-maintainer-burnout-as-an-attack-surface/). + + The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone. + + If this issue was marked as stale erroneously you can exempt it by adding the `backlog` label, assigning someone, or setting a milestone for it. + + Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you! + + Thank you 🙏✌️ + stale-issue-label: "stale" + exempt-issue-labels: "bug,blocking,docs,backlog" + days-before-stale: 365 + days-before-close: 30 + exempt-milestones: true + exempt-assignees: true + only-pr-labels: "stale" diff --git a/.reference-ignore b/.reference-ignore new file mode 100644 index 0000000..eee2a89 --- /dev/null +++ b/.reference-ignore @@ -0,0 +1,3 @@ +**/node_modules +docs +CHANGELOG.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..9cebaf3 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,145 @@ + + + +# 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 + +## Open Source Community Support + +Ory Open source software is collaborative and based on contributions by +developers in the Ory community. There is no obligation from Ory to help with +individual problems. If Ory open source software is used in production in a +for-profit company or enterprise environment, we mandate a paid support contract +where Ory is obligated under their service level agreements (SLAs) to offer a +defined level of availability and responsibility. For more information about +paid support please contact us at sales@ory.sh. + +## 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 at +[office@ory.sh](mailto:office@ory.sh). 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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a4c95fd..d313a4c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,119 +1,271 @@ -# Contribution Guide + + -We welcome and encourage community contributions to Ladon. - -Since the project is still unstable, there are specific priorities for development. Pull requests that do not address these priorities will not be accepted until Ladon is production ready. - -Please familiarize yourself with the Contribution Guidelines and Project Roadmap before contributing. - -There are many ways to help Ladon besides contributing code: - - - Fix bugs or file issues - - Improve the documentation +# Contribute to Ory ladon -**Table of Contents** -- [Contributing Code](#contributing-code) -- [Code Style](#code-style) -- [Developer’s Certificate of Origin](#developer%E2%80%99s-certificate-of-origin) -- [Pull request procedure](#pull-request-procedure) +- [Introduction](#introduction) +- [FAQ](#faq) +- [How can I contribute?](#how-can-i-contribute) +- [Communication](#communication) +- [Contribute examples](#contribute-examples) +- [Contribute code](#contribute-code) +- [Contribute documentation](#contribute-documentation) +- [Disclosing vulnerabilities](#disclosing-vulnerabilities) +- [Code style](#code-style) + - [Working with forks](#working-with-forks) - [Conduct](#conduct) -## Contributing Code +## Introduction -Unless you are fixing a known bug, we **strongly** recommend discussing it with the core team via a GitHub issue before getting started to ensure your work is consistent with Ladon's roadmap and architecture. +_Please note_: We take Ory ladon's security and our users' trust very +seriously. If you believe you have found a security issue in Ory ladon, +please disclose it by contacting us at security@ory.sh. -All contributions are made via pull request. Note that **all patches from all contributors get reviewed**. After a pull request is made other contributors will offer feedback, and if the patch passes review a maintainer will accept it with a comment. When pull requests fail testing, authors are expected to update their pull requests to address the failures until the tests pass and the pull request merges successfully. +There are many ways in which you can contribute. The goal of this document is to +provide a high-level overview of how you can get involved in Ory. -At least one review from a maintainer is required for all patches (even patches from maintainers). +As a potential contributor, your changes and ideas are welcome at any hour of +the day or night, on weekdays, weekends, and holidays. Please do not ever +hesitate to ask a question or send a pull request. -Reviewers should leave a "LGTM" comment once they are satisfied with the patch. If the patch was submitted by a maintainer with write access, the pull request should be merged by the submitter after review. +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. -## Code Style +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 with Ory +ladon's direction. A great way to +do this is via +[Ory ladon Discussions](https://github.com/orgs/ory/discussions) +or the [Ory Chat](https://www.ory.sh/chat). -Please follow these guidelines when formatting source code: +## FAQ -* Go code should match the output of `gofmt -s` +- I am new to the community. Where can I find the + [Ory Community Code of Conduct?](https://github.com/ory/ladon/blob/master/CODE_OF_CONDUCT.md) -## Developer’s Certificate of Origin +- I have a question. Where can I get + [answers to questions regarding Ory ladon?](#communication) -All contributions must include acceptance of the DCO: +- I would like to contribute but I am not sure how. Are there + [easy ways to contribute?](#how-can-i-contribute) + [Or good first issues?](https://github.com/search?l=&o=desc&q=label%3A%22help+wanted%22+label%3A%22good+first+issue%22+is%3Aopen+user%3Aory+user%3Aory-corp&s=updated&type=Issues) -```text -Developer Certificate of Origin -Version 1.1 +- I want to talk to other Ory ladon users. + [How can I become a part of the community?](#communication) -Copyright (C) 2004, 2006 The Linux Foundation and its contributors. -660 York Street, Suite 102, -San Francisco, CA 94110 USA +- I would like to know what I am agreeing to when I contribute to Ory + ladon. + Does Ory have + [a Contributors License Agreement?](https://cla-assistant.io/ory/ladon) -Everyone is permitted to copy and distribute verbatim copies of this -license document, but changing it is not allowed. +- I would like updates about new versions of Ory ladon. + [How are new releases announced?](https://www.ory.sh/l/sign-up-newsletter) +## How can I contribute? -Developer's Certificate of Origin 1.1 +If you want to start to contribute code right away, take a look at the +[list of good first issues](https://github.com/ory/ladon/labels/good%20first%20issue). -By making a contribution to this project, I certify that: +There are many other ways you can contribute. Here are a few things you can do +to help out: -(a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or +- **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 ladon. + Github stars help the project gain visibility and stand out. -(b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or +- **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 community events. More info + on this in [Communication](#communication). -(c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. +- **Answer discussions.** At all times, there are several unanswered discussions + on GitHub. You can see an + [overview here](https://github.com/discussions?discussions_q=is%3Aunanswered+org%3Aory+sort%3Aupdated-desc). + If you think you know an answer or can provide some information that might + help, please share it! Bonus: You get GitHub achievements for answered + discussions. -(d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -``` +- **Help with open issues.** We have a lot of open issues for Ory ladon 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. -To accept the DCO, simply add this line to each commit message with your name and email address (`git commit -s` will do this for you): +- **Review 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 the documentation [here](#contribute-documentation). -```text -Signed-off-by: Jane Example -``` +- **Help with tests.** Pull requests may lack proper tests or test plans. These + are needed for the change to be implemented safely. + +## Communication + +We use [Slack](https://www.ory.sh/chat). You are welcome to drop in and ask +questions, discuss bugs and feature requests, talk to other users of Ory, etc. -For legal reasons, no anonymous or pseudonymous contributions are accepted ([contact us](mailto:aeneas@ory.am) if this is an issue). +Check out [Ory ladon Discussions](https://github.com/orgs/ory/discussions). This is a great place for +in-depth discussions and lots of code examples, logs and similar data. -## Pull request procedure +You can also join our community calls if you want to speak to the Ory team +directly or ask some questions. You can find more info and participate in +[Slack](https://www.ory.sh/chat) in the #community-call channel. -To make a pull request, you will need a GitHub account; if you are unclear on this process, see GitHub's documentation on [forking](https://help.github.com/articles/fork-a-repo) and [pull requests](https://help.github.com/articles/using-pull-requests). Pull requests should be targeted at the `master` branch. Before creating a pull request, go through this checklist: +If you want to receive regular notifications about updates to Ory ladon, +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](https://twitter.com/orycorp). + +## Contribute examples + +One of the most impactful ways to contribute is by adding examples. You can find +an overview of examples using Ory services on the +[documentation examples page](https://www.ory.sh/docs/examples). Source code for +examples can be found in most cases in the +[ory/examples](https://github.com/ory/examples) repository. + +_If you would like to contribute a new example, we would love to hear from you!_ + +Please [open an issue](https://github.com/ory/examples/issues/new/choose) to +describe your example before you start working on it. We would love to provide +guidance to make for a pleasant contribution experience. Go through this +checklist to contribute an example: + +1. Create a GitHub issue proposing a new example and make sure it's different + from an existing one. +1. Fork the repo and create a feature branch off of `master` so that changes do + not get mixed up. +1. Add a descriptive prefix to commits. This ensures a uniform commit history + and helps structure the changelog. Please refer to this + [Convential Commits configuration](https://github.com/ory/ladon/blob/master/.github/workflows/conventional_commits.yml) + for the list of accepted prefixes. You can read more about the Conventional + Commit specification + [at their site](https://www.conventionalcommits.org/en/v1.0.0/). +1. Create a `README.md` that explains how to use the example. (Use + [the README template](https://github.com/ory/examples/blob/master/_common/README.md)). +1. Open a pull request and maintainers will review and merge your example. + +## Contribute 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](https://www.ory.sh/chat) +before getting started to ensure your work is consistent with Ory ladon'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](https://help.github.com/articles/fork-a-repo) and +[pull requests](https://help.github.com/articles/using-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. -1. [Rebase](https://git-scm.com/book/en/Git-Branching-Rebasing) your local changes against the `master` branch. -1. Run the full project test suite with the `go test ./...` (or equivalent) command and confirm that it passes. -1. Run `gofmt -s` (if the project is written in Go). -1. Accept the Developer's Certificate of Origin on all commits (see above). -1. Ensure that each commit has a subsystem prefix (ex: `controller: `). +1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your local + changes against the `master` branch. +1. Run the full project test suite with the `go test -tags sqlite ./...` (or + equivalent) command and confirm that it passes. +1. Run `make format` +1. Add a descriptive prefix to commits. This ensures a uniform commit history + and helps structure the changelog. Please refer to this + [Convential Commits configuration](https://github.com/ory/ladon/blob/master/.github/workflows/conventional_commits.yml) + for the list of accepted prefixes. You can read more about the Conventional + Commit specification + [at their site](https://www.conventionalcommits.org/en/v1.0.0/). + +If a pull request is not ready to be reviewed yet +[it should be marked as a "Draft"](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request). + +Before your contributions can be reviewed you need to sign our +[Contributor License Agreement](https://cla-assistant.io/ory/ladon). + +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](https://github.com/ory/meta/blob/master/LICENSE). + +When pull requests fail the automated testing stages (for example unit or E2E +tests), 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 that 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](https://cla-assistant.io/ory/ladon); +6. include a proper git commit message following the + [Conventional Commit Specification](https://www.conventionalcommits.org/en/v1.0.0/). -Pull requests will be treated as "review requests," and maintainers will give feedback on the style and substance of the patch. +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](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review). + +Reviewers will approve the pull request once they are satisfied with the patch. + +## Contribute documentation + +Please provide documentation when changing, removing, or adding features. All +Ory Documentation resides in the +[Ory documentation repository](https://github.com/ory/docs/). For further +instructions please head over to the Ory Documentation +[README.md](https://github.com/ory/docs/blob/master/README.md). + +## Disclosing vulnerabilities + +Please disclose vulnerabilities exclusively to +[security@ory.sh](mailto:security@ory.sh). Do not use GitHub issues. + +## Code style + +Please run `make format` to format all source code following the Ory standard. + +### Working with forks + +```bash +# First you clone the original repository +git clone git@github.com:ory/ory/ladon.git + +# Next you add a git remote that is your fork: +git remote add fork git@github.com:/ory/ladon.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 +``` -Normally, all pull requests must include tests that test your change. Occasionally, a change will be very difficult to test for. In those cases, please include a note in your commit message explaining why. +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. +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 Ladon core team immediately. -* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. +[Ory Community Code of Conduct](https://github.com/ory/ladon/blob/master/CODE_OF_CONDUCT.md) -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 with a GitHub issue. +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](https://www.ory.sh/chat). diff --git a/LICENSE b/LICENSE index d645695..261eeb9 100644 --- a/LICENSE +++ b/LICENSE @@ -1,4 +1,3 @@ - Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..6104514 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,56 @@ + + + +# Ory Security Policy + +This policy outlines Ory's security commitments and practices for users across +different licensing and deployment models. + +To learn more about Ory's security service level agreements (SLAs) and +processes, please [contact us](https://www.ory.sh/contact/). + +## Ory Network Users + +- **Security SLA:** Ory addresses vulnerabilities in the Ory Network according + to the following guidelines: + - Critical: Typically addressed within 14 days. + - High: Typically addressed within 30 days. + - Medium: Typically addressed within 90 days. + - Low: Typically addressed within 180 days. + - Informational: Addressed as necessary. + These timelines are targets and may vary based on specific circumstances. +- **Release Schedule:** Updates are deployed to the Ory Network as + vulnerabilities are resolved. +- **Version Support:** The Ory Network always runs the latest version, ensuring + up-to-date security fixes. + +## Ory Enterprise License Customers + +- **Security SLA:** Ory addresses vulnerabilities based on their severity: + - Critical: Typically addressed within 14 days. + - High: Typically addressed within 30 days. + - Medium: Typically addressed within 90 days. + - Low: Typically addressed within 180 days. + - Informational: Addressed as necessary. + These timelines are targets and may vary based on specific circumstances. +- **Release Schedule:** Updates are made available as vulnerabilities are + resolved. Ory works closely with enterprise customers to ensure timely updates + that align with their operational needs. +- **Version Support:** Ory may provide security support for multiple versions, + depending on the terms of the enterprise agreement. + +## Apache 2.0 License Users + +- **Security SLA:** Ory does not provide a formal SLA for security issues under + the Apache 2.0 License. +- **Release Schedule:** Releases prioritize new functionality and include fixes + for known security vulnerabilities at the time of release. While major + releases typically occur one to two times per year, Ory does not guarantee a + fixed release schedule. +- **Version Support:** Security patches are only provided for the latest release + version. + +## Reporting a Vulnerability + +For details on how to report security vulnerabilities, visit our +[security policy documentation](https://www.ory.sh/docs/ecosystem/security).