Initial commit

Author: minthukyawdd

.github/FUNDING.yml

@@ -0,0 +1,15 @@
+p# These are supported funding model platforms
+
+github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
+patreon: # Replace with a single Patreon username
+open_collective: # Replace with a single Open Collective username
+ko_fi: # Replace with a single Ko-fi username
+tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+community_bridge: # Replace with a single Community Bridge project-name, e.g., cloud-foundry
+liberapay: # Replace with a single Liberapay username
+issuehunt: # Replace with a single IssueHunt username
+lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-nam,e e.g., cloud-foundry
+polar: # Replace with a single Polar username
+buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
+thanks_dev: # Replace with a single thanks.dev username
+custom: # Replace with up to 4 custom sponsorship URLs, e.g., ['link1', 'link2']

.github/ISSUE_TEMPLATE/proposal-to-add-factor.md

@@ -0,0 +1,12 @@
+---
+name: Proposal for New Factor
+about: Large Change -- Adding a new factor
+title: Proposal to Add [Factor Title]
+labels: large change, proposal
+assignees: ''
+
+---
+
+> Describe the factor you'd like to include and why. Include why you think it
+> fits with the [vision](VISION.md).
+

.github/ISSUE_TEMPLATE/proposal-to-change-core-principles.md

@@ -0,0 +1,11 @@
+---
+name: Proposal for Change to Core Principles
+about: Large Change -- Substantial alteration to core principles
+title: Proposal to Change [Vision/Intro]
+labels: large change, proposal
+assignees: ''
+
+---
+
+> Describe what in the [vision](VISION.md) or [introduction](content/intro.md)
+> you think should be changed and why.

.github/ISSUE_TEMPLATE/proposal-to-remove-factor.md

@@ -0,0 +1,10 @@
+---
+name: Proposal to Remove Factor
+about: Large Change -- Removing an existing factor
+title: Proposal to Remove [Factor Title]
+labels: large change, proposal
+assignees: ''
+
+---
+
+> Explain which factor you think should be removed and why.

.github/ISSUE_TEMPLATE/proposal-to-update-factor.md

@@ -0,0 +1,11 @@
+---
+name: Proposal for Updating Scope of Factor
+about: Medium Change - Significant modifications to an existing factor
+title: Proposal to Modify Factor [Factor Title]
+labels: medium change, proposal
+assignees: ''
+
+---
+
+> Describe the proposed changes to the factor. Why does it need to be changed?
+> What are the benefits?

.github/workflows/blank.yml

@@ -0,0 +1,36 @@
+# This is a basic workflow to help you get started with Actions
+
+name: CI
+
+# Controls when the workflow will run
+on:
+  # Triggers the workflow on push or pull request events but only for the "next" branch
+  push:
+    branches: [ "next" ]
+  pull_request:
+    branches: [ "next" ]
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# A workflow run is made up of one or more jobs that can run sequentially or in parallel
+jobs:
+  # This workflow contains a single job called "build"
+  build:
+    # The type of runner that the job will run on
+    runs-on: ubuntu-latest
+
+    # Steps represent a sequence of tasks that will be executed as part of the job
+    steps:
+      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
+      - uses: actions/checkout@v4
+
+      # Runs a single command using the runners shell
+      - name: Run a one-line script
+        run: echo Hello, world!
+
+      # Runs a set of commands using the runners shell
+      - name: Run a multi-line script
+        run: |
+          echo Add other actions to build,
+          echo test, and deploy your project.

CODEOWNERS

@@ -0,0 +1 @@
+*   @twelve-factor/maintainers

CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing to the Twelve-Factor Project
+
+Thank you for your interest in contributing to the twelve-factor manifesto!
+This guide will help you get started with contributing to the project in a way
+that aligns with our community values and governance structure.
+
+## Getting Started
+
+1. **Familiarize Yourself with the Project**
+   - Begin by reviewing the [Twelve-Factor Manifesto](https://12factor.net) to
+     see the current state.
+   - Check out the [Twelve-Factor Vision](VISION.md) to understand the
+     project's goals and principles.
+   - Take a look at the [Twelve-Factor Governance document](GOVERNANCE.md) to
+     familiarize yourself with how we operate.
+
+2. **Find an Area to Contribute**
+   - Contributions come in many forms: documentation, bug fixes, new features,
+     or participating in discussions.
+   - Look for open issues on our GitHub repository that are tagged as [good
+     first issue](../../issues?q=is%3Aissue+is%3Aopen+label%3Agood+first+issue)
+     for beginners, or explore areas where you feel you can provide value.
+
+3. **Join the Discussion**
+   - Engaging with the community is crucial to contributing. You can:
+     - Participate in discussions on [open issues](../../issues).
+     - Broader discussions often happen on the [mailing
+       list](https://groups.google.com/g/twelve-factor)
+     - Near real-time collaboration happens on
+       [discord](https://discord.gg/9HFMDMt95z)
+   - Respectful dialogue and collaboration a key to our community's success.
+
+## How to Contribute
+
+### Code Contributions
+
+1. **Fork the Repository**
+   - Create a personal fork of the [twelve-factor
+     repository](https://github.com/twelve-factor/twelve-factor).
+2. **Clone Your Fork**
+   - Clone your fork to your local development environment targeting the
+     `next` branch.
+   ```bash
+   git clone -b next https://github.com/your-username/twelve-factor.git
+   cd twelve-factor
+   ```
+3. **Create a new Branch**
+    ```bash
+    git checkout -b your-branch-name
+    ```
+4. **Make Your Changes**
+   - Ensure your changes adhere to the project’s guidelines.
+5. **Submit a Pull Request**
+   - Push your changes to your fork and submit a pull request (PR) to the main
+     repository.
+   - In your PR description, link to any relevant issues and explain the
+     purpose and scope of your changes.
+6. **Review Process**
+   - A [maintainer](MAINTAINERS.md) will review your pull request. Feedback
+     might be provided to help align your contribution with the project’s
+     standards.
+   - Small changes require sign-off from one maintainer, while medium and large
+     changes will undergo a broader review process as outlined in the
+     [governance document](GOVERNANCE.md).

GOVERNANCE.md

@@ -0,0 +1,154 @@
+# Twelve-Factor Governance
+
+This document defines the governance structure for the twelve-factor manifesto
+maintained at [https://12factor.net](https://12factor.net). This project is
+committed to building an open, inclusive, productive and self-governing open
+source community. The guidelines herein describe how the twelve-factor
+community should work together to achieve this goal.
+
+## Membership
+
+A member of the project is a person who has contributed to twelve-factor via
+source code, documentation, pull requests, issues, or discussions. A member may
+additionally have one of the roles listed below. Roles are tied to individuals,
+not companies. Therefore a person leaving a role from a company cannot transfer
+the role to someone else in that company.
+
+### Maintainers
+
+Maintainers are members who are in charge of the day-to-day work of the project
+and its technical governing body. The [maintainership group](MAINTAINERS.md) should be
+sufficiently large to provide diverse perspectives and ensure sustainable
+governance, ideally comprising more than ten but fewer than fifty members.
+Maintainers oversee all aspects of the project and have a mandate to drive
+consensus for:
+
+* Defining and maintaining the mission and charter for the project.
+* Fostering a healthy and welcoming community, including by defining and
+  enforcing our Code of Conduct.
+* Defining the governance structure of the project including how changes are
+  proposed and merged.
+* Anything else that falls through the cracks.
+
+New maintainers must be nominated by existing maintainers and elected by a
+(66%+) supermajority of the maintainers. Maintainers may graduate to emeritus
+status by request or by a super-majority vote of the rest of the maintainers.
+
+### Contributors
+
+Contributors are members who make regular contributions (documentation,
+reviews, responding to issues, participation in proposal discussions, code,
+etc.) and are therefore granted additional permissions (triaging issues,
+merging approved PRs, pushing to non-protected branches) that support those
+activities.
+
+New contributors may be self-nominated or be nominated by existing
+contributors, and must be approved by a super-majority of the maintainers.
+Likewise, contributors may resign or can be removed by a super-majority of
+maintainers.
+
+### Emeritus
+
+Serving as a member of an open source project requires a significant amount of
+work that cannot be sustained indefinitely. The project recognizes emeritus
+members to whom we will always be grateful, but who no longer actively
+participate in the project.
+
+Project members should graduate to emeritus status through self-nomination when
+they no longer intend to actively fulfill an assigned role in the project.
+Members holding multiple roles may choose emeritus status for one role while
+retaining other roles.
+
+As a guideline, when members have not been active contributors for longer than
+3 months they should be nominated to be moved to emeritus. Out of courtesy, a
+notice for nomination should be given to members that fall under this category
+prior to being nominated.
+
+If emeritus members in a leadership position in the project wish to regain an
+active role, they may skip the normal nomination process and can do so by
+renewing their contributions for at least two weeks and contacting an existing
+maintainer to review their work and mark them active again.
+
+## Change Management Process
+
+The twelve-factor manifesto is treated as a foundational reference, so changes
+follow a defined process:
+
+* **Change Principles**: To accept or reject a change, the following principles
+  will be used:
+  * Changes should align with the core values and objectives in the
+    [Twelve-Factor Vision](VISION.md).
+  * Consensus among maintainers is preferred, aiming for broad agreement.
+* **Change Approval**: Changes require different levels of approval depending
+  on their significance. Medium and large changes should be open for feedback
+  for a minimum of one week. This ensures the community has time to comment.
+  Members can \-1 the change to represent concerns that need to be discussed. A
+  vote should only be held if consensus cannot be reached.
+  * **Small Changes**: These include minor updates such as grammar corrections,
+    clarifications, or updates to examples. Small changes require sign-off from
+    at least one maintainer, with no active maintainer concerns.
+  * **Medium Changes**: These include significant modifications to an existing
+    factor, such as changing recommendations or updating the scope of a factor.
+    Medium changes require sign-off from at least three maintainers, with no
+    active maintainer concerns.
+  * **Large Changes**: These include adding a new factor, removing an existing
+    factor, or making substantial alterations to core principles. Large changes
+    require sign-off from at least five maintainers, with no active maintainer
+    concerns.
+* **Version Control**: Medium and large changes will be made in a "next" branch
+  within the version control system (e.g., Git), allowing the community to test
+  and evaluate proposed modifications before they are finalized. This ensures
+  traceability and the ability to easily review and revert changes if needed.
+
+## Major Releases
+
+Once the changes in the "next" branch have been tested and reviewed,
+maintainers will review the set of changes and sign off with a supermajority on
+"major releases" of the principles. This process moves the changes from the
+"next" branch to the main branch, officially updating the manifesto. Major
+releases will happen no more than once a year to ensure stability and provide
+sufficient time for evaluation and community feedback.
+
+## Updating Governance
+
+All substantive changes in Governance require a supermajority agreement by the
+maintainers.
+
+## Brand
+
+In its pre-foundation form, Heroku will retain control over the brand of the
+project. The brand is inclusive of any associated logos, trademarks, and site
+designs. The intent is to find a longer term home where this will all be
+transferred to a foundation for community governance. The governance will be
+updated to reflect when this change occurs.
+
+## Code of Conduct
+
+For code of conduct, we will follow the [Contributor
+Covenant](https://www.contributor-covenant.org/). In case of violations of the
+covenant, the following process will be followed:
+
+1. **Initial Report**: Violations must be reported to the
+   [maintainers](MAINTAINERS.md). Reports can be submitted anonymously or
+   directly to a designated maintainer.
+2. **Assessment**: Upon receiving a report, a team of three (3) maintainers
+   will be selected to assess the situation and gather relevant information.
+   This may involve interviewing the involved parties and any witnesses.
+3. **Decision**: Based on the gathered information, maintainers will decide on
+   the appropriate action. Actions may include issuing warnings, requiring a
+   formal apology, removing members from roles, or banning individuals from
+   participation.
+4. **Notification**: The involved parties will be informed of the decision, and
+   a record will be kept for future reference.
+5. **Appeal**: The individual subject to disciplinary action has the right to
+   appeal the decision. Appeals will be reviewed by a panel of maintainers not
+   directly involved in the initial assessment.
+
+Actions may vary depending on the severity of the infraction, and maintainers
+will strive to apply consequences consistently and fairly.
+
+## Definitions
+
+#### Supermajority
+
+Throughout these documents, "supermajority" means 66%+.