chore: update repository templates

[skip ci] - updated repository templates to 6b85804e79

.github/ISSUE_TEMPLATE/BUG-REPORT.yml

@@ -0,0 +1,113 @@
+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/hydra-maester/blob/master/CODE_OF_CONDUCT.md)."
+          required: true
+        - label:
+            "I have read and am following this repository's [Contribution
+            Guidelines](https://github.com/ory/hydra-maester/blob/master/CONTRIBUTING.md)."
+          required: true
+        - label:
+            'This issue affects my [Ory Cloud](https://www.ory.sh/) project.'
+        - label:
+            '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).'
+    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!'
+    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 Cloud
+        - macOS
+        - Linux
+        - Windows
+        - FreeBSD
+        - Other
+    id: operating-system
+    type: dropdown
+  - attributes:
+      label: 'In which environment are you deploying?'
+      options:
+        - Ory Cloud
+        - 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

.github/ISSUE_TEMPLATE/DESIGN-DOC.yml

@@ -0,0 +1,116 @@
+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 prior to contributing your change ensures that your ideas are checked with
+        the community and maintainers. It will save you a lot of time developing things which might need 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/hydra-maester/blob/master/CODE_OF_CONDUCT.md)."
+          required: true
+        - label:
+            "I have read and am following this repository's [Contribution
+            Guidelines](https://github.com/ory/hydra-maester/blob/master/CONTRIBUTING.md)."
+          required: true
+        - label:
+            'This issue affects my [Ory Cloud](https://www.ory.sh/) project.'
+        - label:
+            '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).'
+    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'
+    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 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'
+    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 implementability 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 really 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 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

.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml

@@ -0,0 +1,77 @@
+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/hydra-maester/blob/master/CODE_OF_CONDUCT.md)."
+          required: true
+        - label:
+            "I have read and am following this repository's [Contribution
+            Guidelines](https://github.com/ory/hydra-maester/blob/master/CONTRIBUTING.md)."
+          required: true
+        - label:
+            'This issue affects my [Ory Cloud](https://www.ory.sh/) project.'
+        - label:
+            '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).'
+    id: checklist
+    type: checkboxes
+  - 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

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,30 +0,0 @@
----
-name: Bug report
-about: Create a report to help us improve
----
-
-**Describe the bug**
-
-A clear and concise description of what the bug is.
-
-**To Reproduce**
-
-Steps to reproduce the behavior:
-
-<!--
-1. Call function `foo.Bar`
-2. Function returns invalid value `baz`
--->
-
-**Expected behavior**
-
-A clear and concise description of what you expected to happen.
-
-**Environment**
-
-- Version: v1.2.3, git sha hash
-- Environment: Debian, Docker, ...
-
-**Additional context**
-
-Add any other context about the problem here.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,11 +1,11 @@
 blank_issues_enabled: false
 contact_links:
-  - name: Ory Ory Oathkeeper Maester Forum
+  - name: Ory Ory Hydra Maester Forum
     url: https://github.com/ory/hydra-maester/discussions
-    about: Please ask and answer questions here, show your implementations and discuss ideas.
+    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.
+    about:
-  - name: Ory Support for Business
+      Hang out with other Ory community members to ask and answer questions.
-    url: https://github.com/ory/open-source-support/blob/master/README.md
-    about: Buy professional support for Ory Ory Oathkeeper Maester.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,22 +0,0 @@
----
-name: Feature request
-about: Suggest an idea for this project
----
-
-**Is your feature request related to a problem? Please describe.**
-
-A clear and concise description of what the problem is. Ex. I'm always
-frustrated when [...]
-
-**Describe the solution you'd like**
-
-A clear and concise description of what you want to happen.
-
-**Describe alternatives you've considered**
-
-A clear and concise description of any alternative solutions or features you've
-considered.
-
-**Additional context**
-
-Add any other context or screenshots about the feature request here.

.github/auto_assign.yml

@@ -11,5 +11,3 @@ assignees:
 # A number of reviewers added to the pull request
 # Set 0 to add all the reviewers (default: 0)
 numberOfReviewers: 0
-
-addAssignees: author

.github/config.yml

@@ -1,3 +1,3 @@
 todo:
-  keyword: "@todo"
+  keyword: '@todo'
   label: todo

.github/pull_request_template.md

@@ -10,14 +10,18 @@ behavior please do baz.
 ```
 -->
 
-## Related issue(s)
+## Related Issue or Design Document
 
 <!--
-Please link the GitHub issue this pull request resolves in the format of `#1234`. If you discussed this change
+If this pull request
-with a maintainer, please mention her/him using the `@` syntax (e.g. `@aeneasr`).
 
-If this change neither resolves an existing issue nor has sign-off from one of the maintainers, there is a
+1. is a fix for a known bug, link the issue where the bug was reported in the format of `#1234`;
-chance substantial changes will be requested or that the changes will be rejected.
+2. is a fix for a previously unknown bug, explain the bug and how to reproduce it in this pull request;
+2. implements a new feature, link the issue containing the design document in the format of `#1234`;
+3. improves the documentation, no issue reference is required.
+
+Pull requests introducing new features, which do not have a design document linked are more likely to be rejected and take on average 2-8 weeks longer to
+get merged.
 
 You can discuss changes with maintainers either in the Github Discusssions in this repository or
 join the [Ory Chat](https://www.ory.sh/chat).
@@ -32,6 +36,8 @@ them, don't hesitate to ask. We're here to help! This is simply a reminder of wh
 
 - [ ] 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

.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:

CONTRIBUTING.md

@@ -8,7 +8,7 @@ https://github.com/ory/meta/blob/master/templates/repository/common/CONTRIBUTING
 
 -->
 
-# Contributing to Ory Ory Oathkeeper Maester
+# Contributing to Ory Ory Hydra Maester
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -32,8 +32,8 @@ 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 Ory Oathkeeper Maester's security and our users' trust very
+_Please note_: We take Ory Ory Hydra Maester's security and our users' trust very
-seriously. If you believe you have found a security issue in Ory Ory Oathkeeper Maester,
+seriously. If you believe you have found a security issue in Ory Ory Hydra Maester,
 please responsibly disclose by contacting us at security@ory.sh.
 
 First: As a potential contributor, your changes and ideas are welcome at any
@@ -48,9 +48,9 @@ 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
-Ory Oathkeeper Maester's normal direction. A great way to
+Ory Hydra Maester's normal direction. A great way to
 do this is via
-[Ory Ory Oathkeeper Maester Discussions](https://github.com/ory/meta/discussions)
+[Ory Ory Hydra Maester Discussions](https://github.com/ory/meta/discussions)
 or the [Ory Chat](https://www.ory.sh/chat).
 
 ## FAQ
@@ -59,21 +59,21 @@ or the [Ory Chat](https://www.ory.sh/chat).
   [Ory Community Code of Conduct?](https://github.com/ory/hydra-maester/blob/master/CODE_OF_CONDUCT.md)
 
 - I have a question. Where can I get
-  [answers to questions regarding Ory Ory Oathkeeper Maester?](#communication)
+  [answers to questions regarding Ory Ory Hydra Maester?](#communication)
 
 - 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 Ory Oathkeeper Maester users.
+- I want to talk to other Ory Ory Hydra Maester 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
-  Ory Oathkeeper Maester.
+  Ory Hydra Maester.
   Does Ory have
   [a Contributors License Agreement?](https://cla-assistant.io/ory/hydra-maester)
 
-- I would like updates about new versions of Ory Ory Oathkeeper Maester.
+- I would like updates about new versions of Ory Ory Hydra Maester.
   [How are new releases announced?](https://ory.us10.list-manage.com/subscribe?u=ffb1a878e4ec6c0ed312a3480&id=f605a41b53)
 
 ## How can I contribute?
@@ -85,7 +85,7 @@ 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 Ory Oathkeeper Maester.
+  difference. This is something that everyone can do to help out Ory Ory Hydra Maester.
   Github stars help the project gain visibility and stand out.
 
 - **Join the community.** Sometimes helping people can be as easy as listening
@@ -93,7 +93,7 @@ a few things you can do to help out:
   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 Ory Oathkeeper Maester
+- **Helping with open issues.** We have a lot of open issues for Ory Ory Hydra Maester
   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
@@ -112,14 +112,14 @@ a few things you can do to help out:
 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 Ory Oathkeeper Maester Discussions](https://github.com/ory/meta/discussions). This is a great place for
+Check out [Ory Ory Hydra Maester Discussions](https://github.com/ory/meta/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).
 
-If you want to receive regular notifications about updates to Ory Ory Oathkeeper Maester,
+If you want to receive regular notifications about updates to Ory Ory Hydra Maester,
 consider joining the mailing list. We will _only_ send you vital information on
 the projects that you are interested in.
 
@@ -129,7 +129,7 @@ Also [follow us on twitter](https://twitter.com/orycorp).
 
 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 Ory Oathkeeper Maester's
+before getting started to ensure your work is consistent with Ory Ory Hydra Maester's
 roadmap and architecture.
 
 All contributions are made via pull requests. To make a pull request, you will
@@ -149,7 +149,7 @@ request, go through this checklist:
 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 Ory Oathkeeper Maester](https://github.com/ory/hydra-maester/blob/master/.github/semantic.yml)
+   [list of prefixes for Ory Hydra Maester](https://github.com/ory/hydra-maester/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
@@ -255,7 +255,7 @@ community a safe place for you and we've got your back.
   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 Ory Oathkeeper Maester
+  member, please contact one of the channel ops or a member of the Ory Ory Hydra Maester
   core team immediately.
 - Likewise any spamming, trolling, flaming, baiting or other attention-stealing
   behaviour is not welcome.