diff --git a/.github/ISSUE_TEMPLATE/BUG-REPORT.yml b/.github/ISSUE_TEMPLATE/BUG-REPORT.yml index 02c1e6b5e55..0e152f537ac 100644 --- a/.github/ISSUE_TEMPLATE/BUG-REPORT.yml +++ b/.github/ISSUE_TEMPLATE/BUG-REPORT.yml @@ -1,17 +1,17 @@ -description: 'Create a bug report' +description: "Create a bug report" labels: - bug -name: 'Bug Report' +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' + label: "Preflight checklist" options: - label: - 'I could not find a solution in the existing issues, docs, nor - discussions.' + "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 @@ -22,18 +22,18 @@ body: Guidelines](https://github.com/ory/hydra/blob/master/CONTRIBUTING.md)." required: true - label: - 'This issue affects my [Ory Cloud](https://www.ory.sh/) project.' + "This issue affects my [Ory Cloud](https://www.ory.sh/) project." - label: - 'I have joined the [Ory Community Slack](https://slack.ory.sh).' + "I have joined the [Ory Community Slack](https://slack.ory.sh)." - label: - 'I am signed up to the [Ory Security Patch - Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53).' + "I am signed up to the [Ory Security Patch + Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)." id: checklist type: checkboxes - attributes: - description: 'A clear and concise description of what the bug is.' - label: 'Describe the bug' - placeholder: 'Tell us what you see!' + 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: @@ -47,17 +47,17 @@ body: 1. Run `docker run ....` 2. Make API Request to with `curl ...` 3. Request fails with response: `{"some": "error"}` - label: 'Reproducing the bug' + 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 + "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' + redact any sensitive information" + label: "Relevant log output" render: shell placeholder: | log=error .... @@ -65,10 +65,10 @@ body: type: textarea - attributes: description: - 'Please copy and paste any relevant configuration. This will be + "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' + redact any sensitive information!" + label: "Relevant configuration" render: yml placeholder: | server: @@ -77,14 +77,14 @@ body: id: config type: textarea - attributes: - description: 'What version of our software are you running?' + 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?' + label: "On which operating system are you observing this issue?" options: - Ory Cloud - macOS @@ -95,19 +95,19 @@ body: id: operating-system type: dropdown - attributes: - label: 'In which environment are you deploying?' + label: "In which environment are you deploying?" options: - Ory Cloud - Docker - - 'Docker Compose' - - 'Kubernetes with Helm' + - "Docker Compose" + - "Kubernetes with Helm" - Kubernetes - Binary - Other id: deployment type: dropdown - attributes: - description: 'Add any other context about the problem here.' + 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 index d26fb343332..69f87ac9346 100644 --- a/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml +++ b/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml @@ -1,8 +1,8 @@ description: - 'A design document is needed for non-trivial changes to the code base.' + "A design document is needed for non-trivial changes to the code base." labels: - rfc -name: 'Design Document' +name: "Design Document" body: - attributes: value: | @@ -18,11 +18,11 @@ body: after code reviews, and your pull requests will be merged faster. type: markdown - attributes: - label: 'Preflight checklist' + label: "Preflight checklist" options: - label: - 'I could not find a solution in the existing issues, docs, nor - discussions.' + "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 @@ -33,18 +33,18 @@ body: Guidelines](https://github.com/ory/hydra/blob/master/CONTRIBUTING.md)." required: true - label: - 'This issue affects my [Ory Cloud](https://www.ory.sh/) project.' + "This issue affects my [Ory Cloud](https://www.ory.sh/) project." - label: - 'I have joined the [Ory Community Slack](https://slack.ory.sh).' + "I have joined the [Ory Community Slack](https://slack.ory.sh)." - label: - 'I am signed up to the [Ory Security Patch - Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53).' + "I am signed up to the [Ory Security Patch + Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)." id: checklist type: checkboxes - 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' + label: "Context and scope" id: scope type: textarea validations: @@ -53,7 +53,7 @@ body: - 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' + label: "Goals and non-goals" id: goals type: textarea validations: @@ -65,7 +65,7 @@ body: 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 set at hand in an appropriate manner. Because of this, there is no explicit guidance for how to actually describe the design. - label: 'The design' + label: "The design" id: design type: textarea validations: @@ -74,21 +74,21 @@ body: - 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' + 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' + 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 implementability of the design. - label: 'Code and pseudo-code' + label: "Code and pseudo-code" id: pseudocode type: textarea @@ -101,7 +101,7 @@ body: 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 really great, and hence such a document should focus on selecting the best way given all identified trade-offs. - label: 'Degree of constraint' + label: "Degree of constraint" id: constrait type: textarea diff --git a/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml b/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml index bcb03404bf3..6e7fb2b3319 100644 --- a/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml +++ b/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml @@ -1,8 +1,8 @@ description: - 'Suggest an idea for this project without a plan for implementation' + "Suggest an idea for this project without a plan for implementation" labels: - feat -name: 'Feature Request' +name: "Feature Request" body: - attributes: value: | @@ -11,11 +11,11 @@ body: 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' + label: "Preflight checklist" options: - label: - 'I could not find a solution in the existing issues, docs, nor - discussions.' + "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 @@ -26,18 +26,18 @@ body: Guidelines](https://github.com/ory/hydra/blob/master/CONTRIBUTING.md)." required: true - label: - 'This issue affects my [Ory Cloud](https://www.ory.sh/) project.' + "This issue affects my [Ory Cloud](https://www.ory.sh/) project." - label: - 'I have joined the [Ory Community Slack](https://slack.ory.sh).' + "I have joined the [Ory Community Slack](https://slack.ory.sh)." - label: - 'I am signed up to the [Ory Security Patch - Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53).' + "I am signed up to the [Ory Security Patch + Newsletter](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)." id: checklist type: checkboxes - attributes: description: - 'Is your feature request related to a problem? Please describe.' - label: 'Describe your problem' + "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 [...]" @@ -50,20 +50,20 @@ body: Describe the solution you'd like placeholder: | A clear and concise description of what you want to happen. - label: 'Describe your ideal solution' + label: "Describe your ideal solution" id: solution type: textarea validations: required: true - attributes: description: "Describe alternatives you've considered" - label: 'Workarounds or alternatives' + label: "Workarounds or alternatives" id: alternatives type: textarea validations: required: true - attributes: - description: 'What version of our software are you running?' + description: "What version of our software are you running?" label: Version id: version type: input @@ -71,7 +71,7 @@ body: required: true - attributes: description: - 'Add any other context or screenshots about the feature request here.' + "Add any other context or screenshots about the feature request here." label: Additional Context id: additional type: textarea diff --git a/.github/config.yml b/.github/config.yml index 0d121fe184f..ea335697979 100644 --- a/.github/config.yml +++ b/.github/config.yml @@ -1,3 +1,3 @@ todo: - keyword: '@todo' + keyword: "@todo" label: todo diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d8bcb167f09..d22b92a3142 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -41,9 +41,9 @@ If you're unsure about any of them, don't hesitate to ask. We're here to help! - [ ] I have referenced an issue containing the design document if my change introduces a new feature. - [ ] I am following the [contributing code guidelines](../blob/master/CONTRIBUTING.md#contributing-code). - [ ] 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 green light (please contact [security@ory.sh](mailto:security@ory.sh)) from the - maintainers to push the changes. +- [ ] 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 green light (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 or changed [the documentation](https://github.com/ory/docs). diff --git a/.github/workflows/closed_references.yml b/.github/workflows/closed_references.yml index ebafc8a71af..2789ac42c2c 100644 --- a/.github/workflows/closed_references.yml +++ b/.github/workflows/closed_references.yml @@ -2,13 +2,13 @@ name: Closed Reference Notifier on: schedule: - - cron: '0 0 * * *' + - cron: "0 0 * * *" workflow_dispatch: inputs: issueLimit: description: Max. number of issues to create required: true - default: '5' + default: "5" jobs: find_closed_references: @@ -19,7 +19,7 @@ jobs: - uses: actions/checkout@v2 - uses: actions/setup-node@v2-beta with: - node-version: '14' + node-version: "14" - uses: ory/closed-reference-notifier@v1 with: token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/milestone.yml b/.github/workflows/milestone.yml index b4a30699f01..fb47e4a78f0 100644 --- a/.github/workflows/milestone.yml +++ b/.github/workflows/milestone.yml @@ -3,7 +3,7 @@ name: Generate and Publish Milestone Document on: workflow_dispatch: schedule: - - cron: '0 0 * * *' + - cron: "0 0 * * *" jobs: milestone: @@ -23,8 +23,8 @@ jobs: - name: Commit Milestone Documentation uses: EndBug/add-and-commit@v4.4.0 with: - message: 'autogen(docs): update milestone document' + message: "autogen(docs): update milestone document" author_name: aeneasr - author_email: '3372410+aeneasr@users.noreply.github.com' + author_email: "3372410+aeneasr@users.noreply.github.com" env: GITHUB_TOKEN: ${{ secrets.TOKEN_PRIVILEGED }} diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 395cb69206d..eb36db174bb 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -1,8 +1,8 @@ -name: 'Close Stale Issues' +name: "Close Stale Issues" on: workflow_dispatch: schedule: - - cron: '0 0 * * *' + - cron: "0 0 * * *" jobs: stale: @@ -35,10 +35,10 @@ jobs: 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' + 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' + only-pr-labels: "stale" diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index f9ab1ecc4db..2351896e4f5 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -2,14 +2,17 @@ ## Our Pledge -In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation -in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, -sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal -appearance, race, religion, or sexual identity and orientation. +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and +expression, level of experience, education, socio-economic status, nationality, +personal appearance, race, religion, or sexual identity and orientation. ## Our Standards -Examples of behavior that contributes to creating a positive environment include: +Examples of behavior that contributes to creating a positive environment +include: - Using welcoming and inclusive language - Being respectful of differing viewpoints and experiences @@ -19,43 +22,56 @@ Examples of behavior that contributes to creating a positive environment include Examples of unacceptable behavior by participants include: -- The use of sexualized language or imagery and unwelcome sexual attention or advances +- The use of sexualized language or imagery and unwelcome sexual attention or + advances - Trolling, insulting/derogatory comments, and personal or political attacks - Public or private harassment -- Publishing others' private information, such as a physical or electronic address, without explicit permission -- Other conduct which could reasonably be considered inappropriate in a professional setting +- Publishing others' private information, such as a physical or electronic + address, without explicit permission +- Other conduct which could reasonably be considered inappropriate in a + professional setting ## Our Responsibilities -Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and -fair corrective action in response to any instances of unacceptable behavior. +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and -other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other -behaviors that they deem inappropriate, threatening, offensive, or harmful. +Project maintainers have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, or to ban temporarily or permanently any +contributor for other behaviors that they deem inappropriate, threatening, +offensive, or harmful. ## Scope -This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its -community. Examples of representing a project or community include using an official project e-mail address, posting via an -official social media account, or acting as an appointed representative at an online or offline event. Representation of a project -may be further defined and clarified by project maintainers. +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at -office@ory.sh. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and -appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an -incident. Further details of specific enforcement policies may be posted separately. +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at office@ory.sh. All complaints will be +reviewed and investigated and will result in a response that is deemed necessary +and appropriate to the circumstances. The project team is obligated to maintain +confidentiality with regard to the reporter of an incident. Further details of +specific enforcement policies may be posted separately. -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions -as determined by other members of the project's leadership. +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html [homepage]: https://www.contributor-covenant.org -For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq +For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 08b796a088b..67c00c27e9d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -28,37 +28,45 @@ https://github.com/ory/meta/blob/master/templates/repository/common/CONTRIBUTING ## 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 Hydra's security and our users' trust very seriously. If you believe you have found a security issue -in Ory Hydra, please responsibly disclose by contacting us at security@ory.sh. - -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 +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 Hydra's security and our users' trust very +seriously. If you believe you have found a security issue in Ory Hydra, +please responsibly disclose by contacting us at security@ory.sh. + +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 Hydra's normal direction. A great way to do this is via -[Ory Hydra Discussions](https://github.com/ory/hydra/discussions) or the -[Ory Chat](https://www.ory.sh/chat). +[Ory Hydra Discussions](https://github.com/ory/hydra/discussions) +or the [Ory Chat](https://www.ory.sh/chat). ## FAQ - I am new to the community. Where can I find the [Ory Community Code of Conduct?](https://github.com/ory/hydra/blob/master/CODE_OF_CONDUCT.md) -- I have a question. Where can I get [answers to questions regarding Ory Hydra?](#communication) +- I have a question. Where can I get + [answers to questions regarding Ory Hydra?](#communication) -- I would like to contribute but I am not sure how. Are there [easy ways to contribute?](#how-can-i-contribute) +- 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) -- I want to talk to other Ory Hydra users. [How can I become a part of the community?](#communication) +- I want to talk to other Ory Hydra users. + [How can I become a part of the community?](#communication) - I would like to know what I am agreeing to when I contribute to Ory Hydra. @@ -73,63 +81,80 @@ do this is via If you want to start contributing code right away, we have a [list of good first issues](https://github.com/ory/hydra/labels/good%20first%20issue). -There are many other ways you can contribute without writing any code. Here are a few things you can do to help out: +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 Hydra. Github stars help the project gain visibility and stand 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 Hydra. + 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](#communication). +- **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](#communication). -- **Helping with open issues.** We have a lot of open issues for Ory Hydra 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. +- **Helping with open issues.** We have a lot of open issues for Ory Hydra + 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](#documentation). +- **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](#documentation). -- **Help with tests.** Some pull requests may lack proper tests or test plans. These are needed for the change to be implemented - safely. +- **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](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. +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. -Check out [Ory Hydra Discussions](https://github.com/ory/hydra/discussions). This is a great place for in-depth discussions and lots of code examples, logs -and similar data. +Check out [Ory Hydra Discussions](https://github.com/ory/hydra/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](https://www.ory.sh/chat). +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](https://www.ory.sh/chat). -If you want to receive regular notifications about updates to Ory Hydra, consider joining the mailing list. We will _only_ send -you vital information on the projects that you are interested in. +If you want to receive regular notifications about updates to Ory Hydra, +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). ## 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](https://www.ory.sh/chat) before getting started to ensure your work is consistent with Ory Hydra's roadmap and -architecture. +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 Hydra'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: +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](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` if a `Makefile` is available, `gofmt -s` if the project is written in Go, `npm run format` if the project is - written for NodeJS. -1. 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 Hydra](https://github.com/ory/hydra/blob/master/.github/semantic.yml) for an - overview. -1. 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. +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` if a `Makefile` is available, `gofmt -s` if the project is + written in Go, `npm run format` if the project is written for NodeJS. +1. 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 Hydra](https://github.com/ory/hydra/blob/master/.github/semantic.yml) + for an overview. +1. 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"](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). @@ -137,46 +162,55 @@ If a pull request is not ready to be reviewed yet Before your contributions can be reviewed you need to sign our [Contributor License Agreement](https://cla-assistant.io/ory/hydra). -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). +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 testing, authors are expected to update their pull requests to address the failures until the tests pass. +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; +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](https://cla-assistant.io/ory/hydra); +5. have signed our + [Contributor License Agreement](https://cla-assistant.io/ory/hydra); 6. include a proper git commit message following the [Conventional Commit Specification](https://www.conventionalcommits.org/en/v1.0.0/). -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 +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. ## Documentation -Please provide documentation when changing, removing, or adding features. Documentation resides in the project's -[docs](https://github.com/ory/hydra/tree/master/docs) folder. Generate API and configuration reference documentation using -`cd docs; npm run gen`. +Please provide documentation when changing, removing, or adding features. +Documentation resides in the project's +[docs](https://github.com/ory/hydra/tree/master/docs) folder. Generate API and +configuration reference documentation using `cd docs; npm run gen`. -For further instructions please head over to [docs/README.md](https://github.com/ory/hydra/blob/master/README.md). +For further instructions please head over to +[docs/README.md](https://github.com/ory/hydra/blob/master/README.md). ## Disclosing vulnerabilities -Please disclose vulnerabilities exclusively to [security@ory.sh](mailto:security@ory.sh). Do not use GitHub issues. +Please disclose vulnerabilities exclusively to +[security@ory.sh](mailto:security@ory.sh). 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. +- NodeJS and JavaScript code should be prettified using `npm run format` where + appropriate. ### Working with Forks @@ -207,19 +241,25 @@ 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. +- 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 Hydra 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](https://www.ory.sh/chat). +- 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 Hydra + 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](https://www.ory.sh/chat). diff --git a/README.md b/README.md index 966277254a3..a563ad77cc6 100644 --- a/README.md +++ b/README.md @@ -111,17 +111,21 @@ to verify user consent allowing you to use Ory Hydra with any authentication end -The Ory community stands on the shoulders of individuals, companies, and maintainers. We thank everyone involved - from submitting -bug reports and feature requests, to contributing patches, to sponsoring our work. Our community is 1000+ strong and growing -rapidly. The Ory stack protects 16.000.000.000+ API requests every month with over 250.000+ active service nodes. We would have +The Ory community stands on the shoulders of individuals, companies, and +maintainers. We thank everyone involved - from submitting bug reports and +feature requests, to contributing patches, to sponsoring our work. Our community +is 1000+ strong and growing rapidly. The Ory stack protects 16.000.000.000+ API +requests every month with over 250.000+ active service nodes. We would have never been able to achieve this without each and everyone of you! -The following list represents companies that have accompanied us along the way and that have made outstanding contributions to our -ecosystem. _If you think that your company deserves a spot here, reach out to +The following list represents companies that have accompanied us along the way +and that have made outstanding contributions to our ecosystem. _If you think +that your company deserves a spot here, reach out to office-muc@ory.sh now_! -**Please consider giving back by becoming a sponsor of our open source work on Patreon -or Open Collective.** +**Please consider giving back by becoming a sponsor of our open source work on +Patreon or +Open Collective.**