diff --git a/.github/ISSUE_TEMPLATE/departure.md b/.github/ISSUE_TEMPLATE/departure.md new file mode 100644 index 0000000..ff870e7 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/departure.md @@ -0,0 +1,52 @@ +--- +name: Departure Notice +about: Formal notice for a community member stepping down from a role +title: "Departure Notice: [Your Name]" +labels: ["departure", "community"] +--- + +This template helps community members formally announce that they are stepping down from +a role in the AReaL project. See +[Voluntary Departure](../../COMMUNITY_MEMBERSHIP.md#voluntary-departure) for the full +process. Thank you for your contributions! + +## Basic Information + +- **Name**: +- **GitHub ID**: @ +- **Current role(s)**: +- **Date of notice**: +- **Effective departure date**: + +## Reason for Departure (optional) + + + +## Handover + +Please check all that apply and provide details where necessary. + +- [ ] Code review assignments / area ownership +- [ ] Ongoing pull request ownership +- [ ] Release management responsibilities +- [ ] Repository access / permissions to be revoked +- [ ] Other: + +## Future Involvement (optional) + +- [ ] I would like to remain a casual contributor when time permits. +- [ ] I prefer a clean break with no future involvement. +- [ ] I am open to returning in the future if circumstances change. + +## Additional Notes + + + +______________________________________________________________________ + +### For Maintainers + +- [ ] Remove repository access and team memberships. +- [ ] Reassign ongoing responsibilities. +- [ ] Move the member to the emeritus section of the relevant `roles/` file. +- [ ] Acknowledge the departure with a thank-you message. diff --git a/.github/ISSUE_TEMPLATE/nominate.md b/.github/ISSUE_TEMPLATE/nominate.md new file mode 100644 index 0000000..db5eb8c --- /dev/null +++ b/.github/ISSUE_TEMPLATE/nominate.md @@ -0,0 +1,65 @@ +--- +name: Role Nomination +about: Nominate a candidate for a community role (Member, Approver, or Maintainer) +title: "Nomination: [Candidate's Name] for [Role]" +labels: ["nomination", "community"] +--- + +Use this template to nominate a candidate for a community role. See the +[Community Membership](../../COMMUNITY_MEMBERSHIP.md) and +[Contributor Ladder](../../COMMUNITY_LADDER.md) documents for the full process. + +> **Self-nomination**: Member candidates may nominate themselves. Approver and +> Maintainer candidates **cannot** self-nominate — the nominator and the nominee must be +> different people. Approver nominations must come from an existing Approver or +> Maintainer, and Maintainer nominations must come from an existing Maintainer. If you +> are self-nominating for Member, fill in the same GitHub ID in both the Nominee and +> Nominator sections and note that this is a self-nomination. + +## Nominee Information + +- **GitHub ID**: +- **Name**: +- **Company / Organization**: +- **Role applied for**: + +## Nominator Information + +- **GitHub ID**: +- **Current role**: +- **Self-nomination?**: + +## Requirements for the Nominee + +- [ ] Nominee's GitHub account has 2FA enabled. +- [ ] Nominee has a history of contributions (code, reviews, issue discussions). +- [ ] Nominee meets the qualifications for the role in the + [Contributor Ladder](../../COMMUNITY_LADDER.md). +- [ ] Nominee has read and agrees to the [Code of Conduct](../../CODE_OF_CONDUCT.md). + +## Nominator's Checklist + +- [ ] For Approver/Maintainer nominations, I am not the nominee (no self-nomination), + and I hold a role eligible to nominate for this position. +- [ ] I have discussed this nomination with the nominee, and they agree to be nominated + (not required when self-nominating for Member). +- [ ] I confirm the nominee meets the requirements listed above. + +## Contributions to AReaL + + + +## Nomination Justification + +### Why this candidate + + + +### Future plans + + + +## Endorsements (optional) + + diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 360424e..6a252e5 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -124,7 +124,7 @@ skipped. 1. Repair: There is no possible repair in cases of this severity. This enforcement ladder is intended as a guideline. It does not limit the ability of -Community Managers to use their discretion and judgment, in keeping with the best +Community Moderators to use their discretion and judgment, in keeping with the best interests of our community. ## Scope diff --git a/COMMUNITY_LADDER.md b/COMMUNITY_LADDER.md new file mode 100644 index 0000000..f75657f --- /dev/null +++ b/COMMUNITY_LADDER.md @@ -0,0 +1,253 @@ +# AReaL Contributor Ladder + +This document outlines the different contributor roles and responsibilities within the +AReaL project. Think of it as a guide to help you understand your role, what is expected +of you, and how you can grow with us in the community. + +- [Goals](#goals) +- [Scope](#scope) +- [General Guidelines](#general-guidelines) + - [Everyone is Welcome](#everyone-is-welcome) + - [Guidance](#guidance) + - [Continued Contributions](#continued-contributions) + - [Consensus for Merging](#consensus-for-merging) + - [Starting the Conversation](#starting-the-conversation) +- [Contributor Ladder](#contributor-ladder) + - [Contributor](#contributor) + - [Member](#member) + - [Approver](#approver) + - [Maintainer](#maintainer) + +## Goals + +We have put this document together with a few key goals in mind: + +- To ensure the long-term health and sustainability of the AReaL community. +- To encourage new contributors to get more involved and take on formal roles. +- To provide a clear path for those looking to grow into leadership positions. +- To build a strong pipeline of future leaders for the project. + +## Scope + +This guide covers the roles and responsibilities for everyone who contributes to the +AReaL open-source project and its repositories. Whether you are writing training code, +improving documentation, adding examples, creating tests, or helping in other ways, this +is for you. + +## General Guidelines + +### Everyone is Welcome + +We truly appreciate every contribution. You do not need a formal title to create or +review pull requests, help with issues, or join discussions. Taking on a formal role is +completely optional, so feel free to contribute in any way that works for you. + +### Guidance + +As described in our [Contributing Guide](CONTRIBUTING.md), we welcome all kinds of +contributions, whether it is pull requests, issues, or new feature ideas. If you are new +here, we recommend starting with smaller, meaningful changes. They are easier to review +and a great way to get familiar with our processes and our [roadmap](ROADMAP.md). + +Because AReaL is an open-source project, review times can vary depending on when +Maintainers and Approvers are available. You can build trust and speed up your +progression by making consistent, smaller contributions or by giving constructive +feedback on other people's work. + +Every time we merge a contribution, we are committing to maintaining it for the long +haul. That is why larger changes require not just a lot of effort, but also a proven +track record so the community can trust that you will be around to support your changes. +For substantial features or refactoring, please open an issue or a draft pull request to +discuss the design with the maintainers before writing the code. + +### Continued Contributions + +If you are thinking about applying for one of the roles below, we hope it is because you +plan to stay active at that level. If life gets in the way and you can no longer keep up +with the responsibilities of your role, it is perfectly fine to step down. Members who +are inactive for an extended period may be moved to emeritus status and removed from the +AReaL GitHub organization, but you can always go through the process again when you are +ready. See +[Removing Inactive Members](COMMUNITY_MEMBERSHIP.md#removing-an-inactive-memberapprovermaintainer) +for details. + +### Consensus for Merging + +If you think a change might be controversial, please hold off on merging and give others +a chance to share their thoughts. Even if you have merge access, it does not mean you +should always use it. We want to avoid blocking pull requests indefinitely, but it is +important to make sure everyone's perspective is heard first. + +### Starting the Conversation + +If you are interested in moving up the ladder and taking on one of these roles, reach +out to an existing Approver or Maintainer in a +[GitHub Discussion](https://github.com/areal-project/AReaL/discussions) or at a +community meeting. We are here to help you get started. + +## Contributor Ladder + +Our ladder has four main roles: **Contributor**, **Member**, **Approver**, and +**Maintainer**. Contributors usually start at the first level and move up as they become +more involved and make a bigger impact. Each role comes with its own set of +responsibilities, qualifications, and privileges that reflect a contributor's level of +involvement and the trust they have earned in the community. + +Here is a quick look at the roles: + + + +| Role | Responsibilities | Qualifications | Privileges | +| --------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------ | +| **Contributor** | Follow our Code of Conduct & Contributing Guide | Anyone who participates in the community | Can be assigned issues and request reviews | +| **Member** | Contribute regularly and complete tasks you volunteer for | A history of contributions over at least three months | Trigger CI/CD, review PRs, and recommend others for Member status | +| **Approver** | Review PRs in your area of expertise and maintain quality | A Member with a solid track record of high-quality reviews | Approve PRs in specific areas and recommend others for Approver | +| **Maintainer** | Merge PRs, coordinate releases, and help shape the project's direction | Long-term contributions, leadership, and a deep understanding of the project | Merge code, represent the project publicly, and nominate new Maintainers | + + + +Each role is defined by three key things: + +- **Responsibilities**: The tasks and duties we expect from you at this level. +- **Qualifications**: The criteria you need to meet to earn this role. +- **Privileges**: The rights and benefits you get as a contributor at this level. + +As the project grows, these roles and responsibilities might evolve. The final say on +role assignments belongs to the project Maintainers, following the process in +[Community Membership](COMMUNITY_MEMBERSHIP.md). + +### Contributor + +A **Contributor** is anyone who adds value to the project. This can be through code, but +it does not have to be. This role is where most new or occasional contributors start. + +- **Responsibilities**: + + - Follow the project's [Code of Conduct](CODE_OF_CONDUCT.md). + - Stick to the [Contributing Guide](CONTRIBUTING.md). + +- **Qualifications**: + + - Open to anyone who wants to be part of the community. + - Contributions can include things like: + - Joining community discussions. + - Reporting bugs or giving feedback. + - Testing new releases and sharing your experience. + - Helping out with documentation, tutorials, or translations. + - Attending or speaking at community events. + - Submitting pull requests. + - Helping other users or answering questions. + - Spreading the word about the project. + +- **Privileges**: + + - You can be assigned to issues and request reviews on your contributions. + +This is the first step toward becoming a Member. + +### Member + +A **Member** is a consistent contributor who is actively involved in the project. +Members have more permissions in our repositories and are trusted to act in the +community's best interest. + +- **Responsibilities**: + + - Make regular contributions to the project. + - Finish any tasks or initiatives you volunteer for. + - Continue to follow the [Code of Conduct](CODE_OF_CONDUCT.md). + +- **Qualifications**: + + - A history of successful contributions, including at least one of these: + - Submitting or reviewing pull requests. + - Fixing issues or bugs. + - Making other impactful contributions. + - You are actively contributing to an area of the project where Member privileges + would be helpful. + - A track record of contributing (code, reviews, discussions) for at least three + months. + - You consistently follow the project's Code of Conduct. + +- **Privileges**: + + - You can trigger CI/CD pipelines (for example, by applying the `safe-to-test` label). + - You can leave reviews and comments on pull requests. + - You can triage issues and apply labels. + - You can recommend other Contributors to become Members. + - You can be nominated for higher roles as described in our governance. + +The current Member list is maintained in [roles/Members.md](roles/Members.md). + +### Approver + +An **Approver** is a Member who takes ownership of a specific part of the project (such +as a training engine, an algorithm, the documentation, or the test suite). Approvers +play a key role in keeping our quality high by reviewing and approving changes in their +area. + +- **Responsibilities**: + + - Handle all the responsibilities of a Member. + - Regularly review pull requests in your area of expertise. + - Make sure changes meet our coding standards, do not introduce regressions, and are + good for the project. + - Help triage issues in your area. + - Help other contributors grow toward becoming Approvers. + +- **Qualifications**: + + - You must already be a Member. + - A proven track record of high-quality reviews and contributions. + - Deep understanding of your specific area. + - A commitment to maintaining responsibility for your designated area. + - Supportive of new and occasional contributors, helping refine pull requests for + merging. + +- **Privileges**: + + - GitHub permissions to approve pull requests and manage labels in your areas. + - You can recommend and review other Members for the Approver role. + +The current Approver list is maintained in [roles/Approvers.md](roles/Approvers.md). + +### Maintainer + +A **Maintainer** is a highly trusted member of the project with the authority to merge +code, vote on project matters, and help guide the project's direction. This role is for +those who have shown a deep, sustained commitment to the community. + +- **Responsibilities**: + + - Fulfill all the responsibilities of an Approver. + - Merge pull requests to the main branch. + - Maintain the codebase's overall quality, stability, and performance. + - Coordinate releases and keep documentation up to date. + - Shape the project's technical direction and [roadmap](ROADMAP.md). + - Mentor new contributors and Maintainers. + - Engage in strategic and policy discussions for the project. + - Participate in voting on key project decisions as per the + [governance rules](GOVERNANCE.md#decision-making). + - Help enforce the [Code of Conduct](CODE_OF_CONDUCT.md) as a Community Moderator. + - Review and approve promotions to the various roles within the project. + +- **Qualifications**: + + - A history of long-term, high-quality contributions and leadership. + - An in-depth understanding of the project's architecture and design. + - Supportive of new contributors, aiding in refining their contributions. + - Demonstrates independent judgment for the project's benefit, beyond personal or + employer interests. + - Actively mentors others in the community. + - Additional requirements are detailed in + [Community Membership](COMMUNITY_MEMBERSHIP.md#how-to-become-a-maintainer). + +- **Privileges**: + + - You can merge code into the project repositories. + - You can vote on project-level decisions. + - You can represent the project in public. + - You can nominate new Maintainers. + +The current Maintainer list is maintained in +[roles/Maintainers.md](roles/Maintainers.md). diff --git a/COMMUNITY_MEMBERSHIP.md b/COMMUNITY_MEMBERSHIP.md new file mode 100644 index 0000000..2caccbd --- /dev/null +++ b/COMMUNITY_MEMBERSHIP.md @@ -0,0 +1,288 @@ +# AReaL Community Membership + +This document explains the responsibilities that come with the different contributor +roles in the AReaL community, and the concrete processes for joining, advancing, and +stepping down. For a full breakdown of the roles, responsibilities, and qualifications, +please also read the [Contributor Ladder](COMMUNITY_LADDER.md). For the project's +governing principles, see [GOVERNANCE.md](GOVERNANCE.md). + +- [How We Make Decisions](#how-we-make-decisions) + - [Solving Conflicts](#solving-conflicts) + - [Handling Abstentions](#handling-abstentions) +- [Managing Membership](#managing-membership) + - [How to Become a Member](#how-to-become-a-member) + - [How to Become an Approver](#how-to-become-an-approver) + - [How to Become a Maintainer](#how-to-become-a-maintainer) + - [Removing an Inactive Member/Approver/Maintainer](#removing-an-inactive-memberapprovermaintainer) + - [Voluntary Departure](#voluntary-departure) +- [Governance and Project Goal Changes](#governance-and-project-goal-changes) +- [Election Process](#election-process) + - [Election Additional Remarks](#election-additional-remarks) + - [Maximum Representation](#maximum-representation) + - [Vacancies](#vacancies) +- [Worked Example: Adding a New Member](#worked-example-adding-a-new-member) + +## How We Make Decisions + +AReaL is an open-source project that thrives on transparency. Our repositories are the +single source of truth for everything — our values, designs, documentation, roadmap, and +interfaces. + +In short, every decision is made by updating the project. Any change, big or small, that +impacts AReaL follows these simple steps: + +1. Open an issue in the relevant repository to propose a change or raise a concern. +1. Discuss the issue in the comments. +1. Merge or close the issue based on community consensus. + +For most issues (excluding those that add new Maintainers), an issue can be approved if: + +- At least one active Maintainer comments "LGTM" (Looks Good To Me). +- No other Maintainer objects to the change. + +For the purpose of this document, an **active Maintainer** is one who has participated +in community activities (such as reviewing pull requests, attending meetings, or +contributing to discussions) within the past three months. + +For significant issues, we use a **lazy consensus period**: after an issue receives +initial approval, it is held for a set amount of time (typically seven days) to give +everyone a final chance to discuss it. If no one objects, it can be merged or closed. If +concerns are raised, we resolve them before moving forward. + +### Solving Conflicts + +In the rare event of a disagreement among Maintainers that cannot be resolved through +discussion, we use a voting process to reach a decision: + +- Any Maintainer can call for a vote by creating a new issue in the relevant repository, + outlining the conflict and the proposed options. +- All active Maintainers are notified and given a chance to vote. +- The outcome is determined by a simple majority (more than 50%) of the votes cast, + unless a higher threshold is required elsewhere in this document. + +### Handling Abstentions + +If a Maintainer chooses to abstain from voting on a particular issue, their abstention +does not count toward the total number of votes cast. The decision is based solely on +the votes of those who actively participate. + +## Managing Membership + +Our Members (and Approvers and Maintainers) share responsibility for the project's +success. In general, they: + +- Are accountable for the project's outcomes. +- Are invested in the long-term improvement of the project. +- Dedicate time to all the necessary tasks, not just the fun ones. + +Members often work hard behind the scenes, and their efforts are not always visible. +While it is easy to get excited about new features, it is just as important — and often +more challenging — to handle bug fixes, small improvements, stability work, and all the +other foundational tasks that keep the project strong. + +### How to Become a Member + +Members start out as dedicated contributors who are committed to the long-term success +of the project. If you aspire to become a Member, you should be actively involved in +resolving issues, contributing code, and reviewing pull requests for at least three +months. + +Membership is built on trust, and that goes beyond just writing code. You earn the trust +of the current Members by consistently acting in the best interest of the project. + +New Members can self-nominate or be nominated by an existing Approver or Maintainer +(through a nomination issue) and need a simple majority vote from the current eligible +voters to be approved. See the [Election Process](#election-process) for details. + +### How to Become an Approver + +Building on the [Election Process](#election-process), the additional requirements are: + +1. You must already be a Member. +1. Be nominated by an existing Approver or Maintainer. Self-nomination is not allowed; + the nominator and the nominee must be different people. +1. Document your contribution history and explain why you are suitable for the role, + listing the specific areas you want to be responsible for. +1. Approval must be given by a simple majority (more than 50%) of current Maintainers. + +### How to Become a Maintainer + +Building on the [Election Process](#election-process), the additional requirements are: + +1. You must have been an Approver for at least three months. +1. Be nominated by an existing Maintainer. Self-nomination is not allowed; the nominator + and the nominee must be different people. +1. Be approved by a supermajority vote (at least 65% of current Maintainers). + +### Removing an Inactive Member/Approver/Maintainer + +An existing Member, Approver, or Maintainer can be removed from the active list if they +are no longer meeting the expectations of the role. If a person meets one of the +following criteria, any other Member, Approver, or Maintainer may propose their removal +through a pull request: + +- They have not participated in community activities (such as reviewing pull requests, + attending meetings, contributing to discussions, or submitting code) for a period + exceeding the following limits: + - Maintainer: more than three months. + - Approver: more than six months. + - Member: more than twelve months. +- They have violated the governance rules more than twice, with documented evidence. + +Once the conditions are confirmed, the person can be removed following the same voting +thresholds as their election. The affected individual has the right to appeal within 14 +days by creating an issue in this community repository, which triggers a review by the +current Maintainers. If someone is removed, they are added to the emeritus section of +the relevant roles file to recognize their past contributions. + +### Voluntary Departure + +If a Member, Approver, or Maintainer wishes to voluntarily step down, they may do so at +any time by creating a departure issue in this community repository. In this case: + +- Create a departure notice: + - Open an issue using the [departure template](.github/ISSUE_TEMPLATE/departure.md). + - Notify the community at least seven days before your last day. + - Specify your exact departure date. +- Provide transition details: + - Share handover information. + - Explain any ongoing responsibilities. + +The departure is publicly announced and remains visible for at least seven days. During +this period: + +- No formal voting is required. +- The departing person should include any relevant handover information in their notice. +- Other Members acknowledge the departure with a thank-you message. +- The departing person is added to the emeritus section of the relevant roles file to + honor their contributions. + +After the departure date, the Maintainer team moves the person and their GitHub ID to +the emeritus section and removes them from the AReaL GitHub organization if necessary. +This process ensures a proper handover and recognition while giving the community +sufficient notice. + +## Governance and Project Goal Changes + +Significant changes to the governance structure or project direction require special +consideration to ensure community alignment. + +This process applies to: + +- **Governance document updates**: major revisions to the governance, membership, or + ladder documents. +- **Decision-making changes**: modifications to voting thresholds or consensus + mechanisms. +- **Role structure changes**: adding or modifying community roles or responsibilities. +- **Project goal changes**: updates to the mission, vision, or strategic direction. +- **Repository structure changes**: significant reorganization of project repositories. +- **Other major changes**: any other changes with substantial community impact. + +The process is: + +1. **Proposal**: Any Maintainer creates an issue with the `governance` label including: + - A description of the proposed changes. + - The rationale and expected benefits. + - An impact analysis and migration plan, if applicable. +1. **Discussion**: The community discusses the proposal in the issue to gather feedback. +1. **Voting**: Maintainers vote. Major governance changes require a supermajority (at + least 65%) of active Maintainers; minor clarifications may proceed by general + agreement. +1. **Documentation**: A pull request updates the governance documents to reflect the + change and references the related issue. +1. **Announcement**: The change is announced publicly and noted in the next community + meeting. + +## Election Process + +Candidates in an election should explain their past contributions to the project and +community, as well as their future plans and intentions. + +To become a **Member**, follow these steps: + +1. A nomination issue is created using the + [nomination template](.github/ISSUE_TEMPLATE/nominate.md) in this community + repository. You may create it yourself, or ask an existing Approver or Maintainer to + help. The Approver and Maintainer lists are in + [roles/Approvers.md](roles/Approvers.md) and + [roles/Maintainers.md](roles/Maintainers.md). +1. While the nomination issue is open, the community can discuss it in the comments. +1. The nomination issue remains open for seven days for discussion and feedback. +1. The nominee is encouraged to attend the next community meeting with a short + self-introduction and a summary of their contributions. +1. If there are no objections from eligible voters during the discussion period, a + Maintainer starts the voting process in the nomination issue. +1. The election is voted on by current Maintainers and Approvers, and a simple majority + (more than 50%) is needed to pass. +1. If approved, a Maintainer creates a pull request to update + [roles/Members.md](roles/Members.md). The PR must link to the nomination/voting issue + and receive at least two "LGTM" reviews from existing Approvers or Maintainers. +1. Once merged, the Maintainer team adds the new Member to the AReaL GitHub + organization. + +The process is similar for becoming an Approver or Maintainer, with the additional +requirements described above. Unlike Member nominations, Approver and Maintainer +nominations cannot be self-nominations: each one must have a nominee who is different +from the nominator. Approver nominations must be made by an existing Approver or +Maintainer, and Maintainer nominations must be made by an existing Maintainer. + +To ensure a fair and transparent process, AReaL uses the following parameters for each +role: + + + +| Role | Nomination Period | Voting Period | Eligible Voters | Voting Requirement | +| ---------- | ----------------- | ------------- | --------------------------------- | ---------------------- | +| Member | 7 days | 7 days | Current Maintainers and Approvers | Simple majority (>50%) | +| Approver | 7 days | 14 days | Current Maintainers only | Simple majority (>50%) | +| Maintainer | 7 days | 14 days | Current Maintainers only | Supermajority (≥65%) | + + + +- **Nomination Period**: The nominator creates an issue that remains open for seven days + to allow community discussion. +- **Voting Period**: After the discussion phase, the voting period begins. It must be + started by a Maintainer and remain open for the duration shown above. +- **Voting Eligibility**: Member votes are open to current Maintainers and Approvers; + Approver and Maintainer votes are open to current Maintainers only. +- **Results and Implementation**: Votes are counted and the outcome is documented in the + nomination issue and the meeting summary. New role holders are added to the GitHub + organization by the Maintainer team and recorded in the relevant [roles/](roles/) + file. + +### Election Additional Remarks + +#### Maximum Representation + +To ensure balanced representation, no more than half of the active Maintainers may be +from the same company or organization. If an election would exceed this limit, only the +top vote recipients up to the limit serve, and additional seats are filled by the next +highest vote recipients from other organizations. + +#### Vacancies + +If an elected Maintainer leaves, the candidate with the next most votes from the +previous election may be offered the seat. If that is not possible, a special election +is held using the eligible voters from the most recent election. + +## Worked Example: Adding a New Member + +**Background**: Jane Doe has been contributing to AReaL for three months, consistently +submitting bug fixes, documentation improvements, and participating in community +discussions. + +1. **Nomination**: Jane creates a nomination issue using the + [nomination template](.github/ISSUE_TEMPLATE/nominate.md), or an existing Maintainer + helps her create it. +1. **Community discussion**: The nomination issue stays open for seven days. Community + members ask questions, and Jane responds about her commitment and future plans. + Eligible voters (Maintainers and Approvers) can raise concerns. +1. **Voting initiation**: Jane gives a short self-introduction at the next community + meeting. If there are no objections, a Maintainer starts the vote in the issue. +1. **Voting**: Eligible voters cast their votes over seven days using GitHub issue + reactions (👍 yes, 👎 no, 👀 abstain). A simple majority of the votes cast is required. +1. **Results and onboarding**: The result is announced (for example, 5 yes / 1 no / 1 + abstain — passes). A Maintainer opens a pull request to update + [roles/Members.md](roles/Members.md). Once merged, Jane is added to the AReaL GitHub + organization with the appropriate permissions and welcomed in the next meeting + summary. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1802faa..e9fe116 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -10,6 +10,8 @@ Please review our [Code of Conduct](CODE_OF_CONDUCT.md) before participating and ## Table of Contents - [Quick Start](#quick-start) +- [Sign Your Work: Developer Certificate of Origin (DCO)](#sign-your-work-developer-certificate-of-origin-dco) +- [Licensing of Contributions](#licensing-of-contributions) - [Tips for Using AI-Assisted Coding](#tips-for-using-ai-assisted-coding) - [CI/CD](#cicd) @@ -34,8 +36,9 @@ Please review our [Code of Conduct](CODE_OF_CONDUCT.md) before participating and ```bash # Install hooks (includes formatting, linting, and commit message checks) pre-commit install --install-hooks - # Subsequent commits will automatically check your files and commit messages: - git commit -a -m 'feat(engine): my change' + # Subsequent commits will automatically check your files and commit messages. + # Use -s to add the required Developer Certificate of Origin sign-off (see below): + git commit -s -a -m 'feat(engine): my change' ``` 1. **Find an Issue:** @@ -95,6 +98,84 @@ issue or open a draft PR to discuss with the core developers before making any c changes. Directly opening a PR that conflicts with our future [roadmap](ROADMAP.md) may waste your effort. +## Sign Your Work: Developer Certificate of Origin (DCO) + +Following common open-source and Linux Foundation practice, AReaL requires every commit +to be **signed off** under the +[Developer Certificate of Origin (DCO)](https://developercertificate.org/), version 1.1. +The DCO is a lightweight way for contributors to certify that they wrote the +contribution, or otherwise have the right to submit it under the project's open-source +license. We use the DCO instead of a Contributor License Agreement (CLA). + +To sign off, add a `Signed-off-by` line to each commit message using your real name and +an email address you can be reached at: + +```text +Signed-off-by: Jane Doe +``` + +Git can add this line for you automatically with the `-s` (or `--signoff`) flag: + +```bash +git commit -s -m 'feat(engine): my change' +``` + +If you forget to sign off, you can amend the most recent commit: + +```bash +git commit --amend -s --no-edit +``` + +or sign off a range of earlier commits with an interactive rebase: + +```bash +git rebase --signoff HEAD~ +``` + +Pull requests whose commits are not signed off cannot be merged. By signing off, you +make the certification reproduced below. + +
+Developer Certificate of Origin 1.1 + +```text +By making a contribution to this project, I certify that: + +(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 + +(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 + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(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. +``` + +
+ +## Licensing of Contributions + +AReaL is released under the [Apache License 2.0](LICENSE). Unless explicitly stated +otherwise, all contributions you submit are accepted under the same license on an +"inbound = outbound" basis: the terms under which you contribute are the same terms +under which the project is distributed. Do not submit code, documentation, datasets, or +other material that you are not authorized to contribute under this license, and +properly credit any third-party sources as required by the +[Code of Conduct](CODE_OF_CONDUCT.md). + ## Tips for Using AI-Assisted Coding See the full diff --git a/GOVERNANCE.md b/GOVERNANCE.md index b49c31e..f518460 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,86 +1,220 @@ # AReaL Project Governance -This document describes how the AReaL project is governed. - -## Roles - -### Contributors - -Anyone who files issues, submits pull requests, or participates in discussions is -considered a contributor. All contributors are expected to follow the -[Code of Conduct](CODE_OF_CONDUCT.md). - -### Maintainers - -Maintainers have write access to the repository and are responsible for reviewing pull -requests, triaging issues, and guiding the technical direction of the project. Two -maintainer approvals are required to merge a pull request (see -[Decision-Making](#decision-making)). - -| Name | Organization | GitHub | -| ------------ | ------------------------- | --------------------- | -| Wei Fu | IIIS, Tsinghua University | @garrett4wade | -| Wentai Zhang | AReaL Team, Ant Group | @rchardx | -| Zhiyu Mei | AReaL Team, Ant Group | @nuzant | -| Xujie Shen | AReaL Team, Ant Group | @fishcrap | -| Tongkai Yang | AReaL Team, Ant Group | @fredy12 | -| Han Jiang | AReaL Team, Ant Group | @CormickKneey | -| Yong Zhang | Huawei | @HwVanICI | -| Zhenan Fan | Huawei | @zhenanf | -| Ge Shi | Huawei | @geshi001 | -| Xiaojie Xu | Huawei | @PrometheusComing | -| Bingye Chen | ByteDance | @TaoZex | -| Zhihao Guo | Xiaomi | @guozhihao-224 | -| Ming Li | AReaL Team, Ant Group | @sitabulaixizawaluduo | -| Huaqing Yuan | Tencent | @HT-Yuan | - -### Lead Maintainer (BDFL) - -Wei Fu ([@garrett4wade](https://github.com/garrett4wade)) serves as the lead maintainer. -The lead maintainer has final authority on technical decisions when maintainers cannot -reach consensus, and holds the repository **administrator** role on GitHub. As an -administrator, the lead maintainer may bypass the two-approval requirement to merge -trivial changes (typo fixes, documentation-only edits, dependency bumps verified by CI) -or time-sensitive hotfixes. Bypasses must still go through a pull request and should be -disclosed in the PR description. +Welcome to the AReaL project's governance guide. AReaL is a community-driven open-source +project, and we believe that open, transparent collaboration is the best way to build a +healthy, inclusive, and effective community. This document explains how the project is +run — our principles, roles, responsibilities, and the way we make decisions. We have +kept things as simple and practical as possible so that everyone can understand how to +get involved and how the project operates. + +## Core Principles + +- **Openness.** All of our communication and decision-making happens in the open. + Discussions, proposals, and decisions are recorded in public issues, pull requests, + and community meetings so anyone can follow along. +- **Inclusivity.** We are committed to a friendly and welcoming environment where people + from all backgrounds and organizations can participate and feel included. +- **Neutrality.** AReaL is a community-driven project. Decisions are based on technical + merit and community consensus, and are not controlled by any single company or + individual. +- **Meritocracy.** Influence and responsibility are earned through sustained, + high-quality contributions and constructive participation, not through title or + affiliation. +- **Simplicity.** We keep our governance processes as lightweight as possible and avoid + unnecessary bureaucracy. + +## Scope + +This governance document applies to the AReaL project and all repositories owned by the +[`areal-project`](https://github.com/areal-project) GitHub organization, including the +main [areal-project/AReaL](https://github.com/areal-project/AReaL) repository and this +community repository. The complete list of official repositories is maintained in +[REPOSITORIES.md](REPOSITORIES.md). + +## Roles and Responsibilities + +AReaL uses a contributor ladder with four roles: **Contributor**, **Member**, +**Approver**, and **Maintainer**. Each role carries its own responsibilities, +qualifications, and privileges that reflect a person's level of involvement and the +trust they have earned in the community. + +| Role | Summary | +| --------------- | ------------------------------------------------------------------------------- | +| **Contributor** | Anyone who files issues, opens pull requests, or joins discussions. | +| **Member** | A consistent contributor trusted with triage and review permissions. | +| **Approver** | A Member who reviews and approves changes in a specific area of the project. | +| **Maintainer** | A trusted leader who merges code, votes on project matters, and sets direction. | + +For a detailed description of each role — including responsibilities, qualifications, +and privileges — see the [AReaL Contributor Ladder](COMMUNITY_LADDER.md). The current +holders of each role are listed under [roles/](roles/). + +There is no single "benevolent dictator" or lead maintainer with final authority over +the project. Authority is shared by the Maintainer team and exercised through the +decision-making process described below. ### Community Moderators -The [Code of Conduct](CODE_OF_CONDUCT.md) refers to "Community Moderators" as the -individuals responsible for enforcement. In this project, community moderators are the -current maintainers listed above. +The [Code of Conduct](CODE_OF_CONDUCT.md) refers to "Community Moderators" as the people +responsible for enforcement. In this project, the Community Moderators are the current +Maintainers listed in [roles/Maintainers.md](roles/Maintainers.md). ## Decision-Making -Decisions are made by consensus among maintainers whenever possible. When consensus -cannot be reached, the lead maintainer makes the final decision. +AReaL's repositories are the single source of truth for the project — its code, designs, +documentation, roadmap, and policies. In practice, every decision is made by proposing a +change and reaching agreement on it in the open: -Pull request approval policy: +1. Open an issue (or pull request) in the relevant repository to propose a change or + raise a concern. +1. Discuss it in the comments so that everyone has a chance to weigh in. +1. Merge or close it based on community consensus. -- All pull requests require approval from at least **two maintainers** before they can - be merged. At least one approval must come from a code owner of the modified paths - (see - [`.github/CODEOWNERS`](https://github.com/areal-project/areal/blob/main/.github/CODEOWNERS)). -- The **lead maintainer**, acting as repository administrator, may bypass the - two-approval requirement for trivial or time-sensitive changes as described in the - [Lead Maintainer](#lead-maintainer-bdfl) section. +We strive to make decisions by **consensus** among the Maintainers whenever possible. +Consensus does not require unanimity; it means that concerns raised during discussion +have been heard and addressed, and no Maintainer actively objects. + +### Lazy consensus + +For most non-controversial changes we rely on *lazy consensus*: once a proposal has +received initial approval, it is held for a short review window (typically **7 days**) +so that everyone has a final chance to comment. If no Maintainer objects within that +period, the change is considered approved. + +### Resolving conflicts by vote + +If the Maintainers cannot reach consensus through discussion, any Maintainer may call +for a vote by opening (or labeling) an issue that describes the conflict and the +proposed options. All active Maintainers are notified and given a chance to vote. Unless +a higher threshold is specified elsewhere in this document, the outcome is decided by a +**simple majority (more than 50%)** of the votes cast. Abstentions do not count toward +the total. + +An **active Maintainer** is one who has participated in community activities (such as +reviewing pull requests, attending meetings, or contributing to discussions) within the +past three months. + +### Pull request approval policy + +The following rules apply to code and documentation changes in the project's +repositories: + +- All pull requests require approval from at least **two Maintainers (or Approvers in + their area of ownership)** before they can be merged. At least one approval must come + from a code owner of the modified paths (see + [`.github/CODEOWNERS`](https://github.com/areal-project/AReaL/blob/main/.github/CODEOWNERS)). +- A Maintainer who holds the repository **administrator** role may merge trivial changes + (typo fixes, documentation-only edits, or dependency bumps verified by CI) and + time-sensitive hotfixes without the second approval. Such bypasses must still go + through a pull request and must be disclosed in the PR description. - The branch protection rules on `main` are documented in - [`.github/ruleset.json`](https://github.com/areal-project/areal/blob/main/.github/ruleset.json) - and are the source of truth for mechanical enforcement of this policy. + [`.github/ruleset.json`](https://github.com/areal-project/AReaL/blob/main/.github/ruleset.json) + and are the source of truth for the mechanical enforcement of this policy. -## Becoming a Maintainer +## Membership and Elections -New maintainers are added through nomination by an existing maintainer, followed by -consensus approval from the current maintainers. There are no strict criteria, but -candidates are generally expected to have a track record of quality contributions and -constructive participation in the project. +We use a structured membership system to recognize and empower active contributors. The +process for becoming (or stepping down from) a Member, Approver, or Maintainer — along +with the voting thresholds, election timelines, and inactivity rules — is documented in +[Community Membership](COMMUNITY_MEMBERSHIP.md) and the +[Contributor Ladder](COMMUNITY_LADDER.md). -## Code of Conduct +## Rights and Responsibilities of Participants -All participants are expected to follow the [Code of Conduct](CODE_OF_CONDUCT.md). -Violations can be reported to fuwth17@gmail.com. +Everyone who participates in the AReaL community has certain rights and +responsibilities. + +**Your rights:** -## Amendments +- To participate in any public discussion, issue, or pull request. +- To be treated with respect and in accordance with the + [Code of Conduct](CODE_OF_CONDUCT.md). +- To have your contributions reviewed and considered on their technical merit. +- To propose changes to the project, including to this governance document. +- To grow into formal roles through the [Contributor Ladder](COMMUNITY_LADDER.md). -Changes to this governance document require consensus among maintainers. If consensus -cannot be reached, the lead maintainer decides. +**Your responsibilities:** + +- Follow the [Code of Conduct](CODE_OF_CONDUCT.md) and the + [Contributing Guide](CONTRIBUTING.md). +- Act in the long-term best interest of the project and its users. +- Communicate openly, kindly, and honestly, and assume good faith in others. +- Give and accept constructive feedback gracefully. +- Disclose relevant conflicts of interest when participating in decisions. + +The additional responsibilities that come with each formal role are described in the +[Contributor Ladder](COMMUNITY_LADDER.md). + +## Communication + +AReaL's day-to-day collaboration happens in public. The main channels are: + +- **GitHub Issues** — bug reports, feature requests, and proposals in the + [main issue tracker](https://github.com/areal-project/AReaL/issues). +- **GitHub Discussions** — questions, ideas, and open-ended discussion in + [AReaL Discussions](https://github.com/areal-project/AReaL/discussions). +- **Community meetings** — regular community calls. Agendas, slides, and recordings are + indexed in [meeting/README.md](meeting/README.md). +- **Security reports** — see [SECURITY.md](SECURITY.md) for private disclosure channels. + +A fuller list of channels is kept in the [README](README.md#community--communication). + +## Code of Conduct + +All participants are expected to follow the [Code of Conduct](CODE_OF_CONDUCT.md). +Violations can be reported privately to the Community Moderators (the current +Maintainers) at . + +## Feedback + +We welcome feedback on the project and on how the community is run: + +- For ideas and product feedback, open a + [discussion](https://github.com/areal-project/AReaL/discussions) or a feature-request + issue. +- For feedback on governance or community process, open an issue in this repository with + the `governance` label, or raise it in a community meeting. + +Maintainers aim to acknowledge governance and community feedback within a reasonable +time and to respond to it transparently. + +## Security + +Security is a priority for the project. If you discover a vulnerability, please follow +the responsible-disclosure process described in [SECURITY.md](SECURITY.md). Do not +report security issues through public issues, discussions, or pull requests. + +## Legal and Compliance + +AReaL follows widely adopted open-source governance practices, consistent with the +expectations the Linux Foundation sets for the projects it hosts: + +- **Licensing.** AReaL is released under the [Apache License 2.0](LICENSE). + Contributions are accepted under the same license on an "inbound = outbound" basis. + See [Licensing of Contributions](CONTRIBUTING.md#licensing-of-contributions). +- **Developer Certificate of Origin (DCO).** Every commit must be signed off under the + [DCO](https://developercertificate.org/) to certify the contributor's right to submit + it. We use the DCO in place of a Contributor License Agreement (CLA). See + [Sign Your Work](CONTRIBUTING.md#sign-your-work-developer-certificate-of-origin-dco). +- **Vendor neutrality and antitrust.** AReaL is governed for the benefit of the project + and its users, not any single company. To preserve neutrality, no more than half of + the active Maintainers may be affiliated with the same company or organization (see + [Maximum Representation](COMMUNITY_MEMBERSHIP.md#maximum-representation)). + Participants in community meetings and discussions are expected to comply with + applicable antitrust and competition laws, and must not use community forums to + coordinate on pricing, markets, or other anticompetitive matters. +- **Trademarks.** "AReaL" and associated names and logos are used to identify the + project. Please do not use them in a way that implies endorsement or affiliation + without permission. Nominative references (for example, "compatible with AReaL") are + welcome. + +## Amending this Document + +Changes to this governance document follow the +[Governance Change Process](COMMUNITY_MEMBERSHIP.md#governance-and-project-goal-changes). +In short: + +- **Major changes** (for example, to roles, voting thresholds, or decision-making rules) + require a **supermajority vote of at least 65%** of the active Maintainers. +- **Minor changes** (clarifications, typo fixes, formatting) may be made by a Maintainer + after reaching general agreement, via a normal pull request. diff --git a/README.md b/README.md index 512b3cd..3216dcb 100644 --- a/README.md +++ b/README.md @@ -7,15 +7,18 @@ AReaL itself, please visit the main repository at ## What lives here -| Document | Purpose | -| ---------------------------------------- | ---------------------------------------------------------------------- | -| [GOVERNANCE.md](GOVERNANCE.md) | Project roles, maintainers, decision-making process. | -| [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | Community standards based on Contributor Covenant 3.0. | -| [CONTRIBUTING.md](CONTRIBUTING.md) | How to contribute to the community (events, docs, translations, etc.). | -| [SECURITY.md](SECURITY.md) | How to responsibly disclose security vulnerabilities. | -| [REPOSITORIES.md](REPOSITORIES.md) | Index of repositories that make up the AReaL ecosystem. | -| [ROADMAP.md](ROADMAP.md) | Pointer to the official AReaL project roadmap. | -| [LICENSE](LICENSE) | Apache License 2.0, under which AReaL is released. | +| Document | Purpose | +| -------------------------------------------------- | ---------------------------------------------------------------------- | +| [GOVERNANCE.md](GOVERNANCE.md) | Governing principles, decision-making, and how the project is run. | +| [COMMUNITY_LADDER.md](COMMUNITY_LADDER.md) | Contributor roles (Contributor, Member, Approver, Maintainer). | +| [COMMUNITY_MEMBERSHIP.md](COMMUNITY_MEMBERSHIP.md) | Elections, promotions, departures, and membership processes. | +| [roles/](roles/) | The people who currently hold each community role. | +| [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) | Community standards based on Contributor Covenant 3.0. | +| [CONTRIBUTING.md](CONTRIBUTING.md) | How to contribute to the community (events, docs, translations, etc.). | +| [SECURITY.md](SECURITY.md) | How to responsibly disclose security vulnerabilities. | +| [REPOSITORIES.md](REPOSITORIES.md) | Index of repositories that make up the AReaL ecosystem. | +| [ROADMAP.md](ROADMAP.md) | Pointer to the official AReaL project roadmap. | +| [LICENSE](LICENSE) | Apache License 2.0, under which AReaL is released. | ## Get involved @@ -31,11 +34,43 @@ There are many ways to participate, regardless of your background: See [CONTRIBUTING.md](CONTRIBUTING.md) for more details. -## Governance & maintainers +## Community & communication -The project is governed as described in [GOVERNANCE.md](GOVERNANCE.md). The list of -current maintainers, the decision-making process, and the path to becoming a maintainer -are all documented there. +AReaL's collaboration happens in the open. The main ways to reach the community are: + +- **GitHub Issues** -- bug reports, feature requests, and proposals in the + [main issue tracker](https://github.com/areal-project/AReaL/issues). +- **GitHub Discussions** -- questions, ideas, and open-ended discussion in + [AReaL Discussions](https://github.com/areal-project/AReaL/discussions). +- **Community meetings** -- regular community calls. Agendas, slides, and recordings are + indexed in [meeting/README.md](meeting/README.md). +- **Security reports** -- private disclosure channels described in + [SECURITY.md](SECURITY.md). + +## Governance & roles + +The project is governed as described in [GOVERNANCE.md](GOVERNANCE.md). AReaL is a +community-driven project with a four-rung contributor ladder -- Contributor, Member, +Approver, and Maintainer -- described in [COMMUNITY_LADDER.md](COMMUNITY_LADDER.md). The +decision-making process, election and promotion procedures, and the people who hold each +role are documented in [COMMUNITY_MEMBERSHIP.md](COMMUNITY_MEMBERSHIP.md) and under +[roles/](roles/). + +## Feedback + +We welcome your feedback. Share product ideas in +[Discussions](https://github.com/areal-project/AReaL/discussions), raise governance or +community-process feedback in an issue labeled `governance` in this repository or at a +community meeting. See [GOVERNANCE.md](GOVERNANCE.md#feedback) for details. + +## Community + +WeChat QR Code + +We warmly welcome everyone to join our community! We have a _**WeChat group**_ for +real-time discussions and a +[GitHub discussion board](https://github.com/areal-project/AReaL/discussions) for +asynchronous conversations. ## Community diff --git a/SECURITY.md b/SECURITY.md index 35a0d06..b6b1208 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -15,8 +15,9 @@ To report a vulnerability, use one of the following private channels: affected repository (for example [areal-project/AReaL](https://github.com/areal-project/AReaL/security/advisories)), open **Advisories**, and click **Report a vulnerability**. -1. **Email.** If you cannot use GitHub advisories, send an email to the lead maintainer - at ****. Encrypt sensitive details if possible. +1. **Email.** If you cannot use GitHub advisories, send an email to the + [Security Team](roles/Security-Team.md) at ****. Encrypt sensitive + details if possible. When reporting, please include: @@ -27,7 +28,7 @@ When reporting, please include: You can expect an acknowledgement within **3 business days**. If you do not hear back within that window, please follow up via the same channel or contact another maintainer -listed in [GOVERNANCE.md](GOVERNANCE.md). +listed in [roles/Maintainers.md](roles/Maintainers.md). ## Disclosure process diff --git a/roles/Approvers.md b/roles/Approvers.md new file mode 100644 index 0000000..20f4775 --- /dev/null +++ b/roles/Approvers.md @@ -0,0 +1,31 @@ +# Approvers + +This document lists the current Approvers of the AReaL community. For details on the +Approver role and its responsibilities, see +[COMMUNITY_LADDER.md](../COMMUNITY_LADDER.md#approver) and +[COMMUNITY_MEMBERSHIP.md](../COMMUNITY_MEMBERSHIP.md#how-to-become-an-approver). For +governance processes, see [GOVERNANCE.md](../GOVERNANCE.md). + +## Current Approvers + + + +| GitHub ID | Name | Area(s) of Ownership | Company / Organization | +| :-------: | :--: | :------------------: | :--------------------: | + + + +> No Approvers have been elected yet. To nominate a candidate, follow the +> [Election Process](../COMMUNITY_MEMBERSHIP.md#election-process). + +## Emeritus Approvers + +Below is the list of emeritus (retired) Approvers. We thank them for their contributions +to the project. + + + +| GitHub ID | Name | Company / Organization | +| :-------: | :--: | :--------------------: | + + diff --git a/roles/Maintainers.md b/roles/Maintainers.md new file mode 100644 index 0000000..e2d75d4 --- /dev/null +++ b/roles/Maintainers.md @@ -0,0 +1,42 @@ +# Maintainers + +This document lists the current Maintainers of the AReaL community. For details on the +Maintainer role and its responsibilities, see +[COMMUNITY_LADDER.md](../COMMUNITY_LADDER.md#maintainer) and +[COMMUNITY_MEMBERSHIP.md](../COMMUNITY_MEMBERSHIP.md#how-to-become-a-maintainer). For +governance processes, see [GOVERNANCE.md](../GOVERNANCE.md). + +## Current Maintainers + + + +| GitHub ID | Name | Company / Organization | +| :-------------------------------------------------------------: | :----------: | :-----------------------: | +| [garrett4wade](https://github.com/garrett4wade) | Wei Fu | IIIS, Tsinghua University | +| [rchardx](https://github.com/rchardx) | Wentai Zhang | AReaL Team, Ant Group | +| [nuzant](https://github.com/nuzant) | Zhiyu Mei | AReaL Team, Ant Group | +| [fishcrap](https://github.com/fishcrap) | Xujie Shen | AReaL Team, Ant Group | +| [fredy12](https://github.com/fredy12) | Tongkai Yang | AReaL Team, Ant Group | +| [CormickKneey](https://github.com/CormickKneey) | Han Jiang | AReaL Team, Ant Group | +| [HwVanICI](https://github.com/HwVanICI) | Yong Zhang | Huawei | +| [zhenanf](https://github.com/zhenanf) | Zhenan Fan | Huawei | +| [geshi001](https://github.com/geshi001) | Ge Shi | Huawei | +| [PrometheusComing](https://github.com/PrometheusComing) | Xiaojie Xu | Huawei | +| [TaoZex](https://github.com/TaoZex) | Bingye Chen | ByteDance | +| [guozhihao-224](https://github.com/guozhihao-224) | Zhihao Guo | Xiaomi | +| [sitabulaixizawaluduo](https://github.com/sitabulaixizawaluduo) | Ming Li | AReaL Team, Ant Group | +| [HT-Yuan](https://github.com/HT-Yuan) | Huaqing Yuan | Tencent | + + + +## Emeritus Maintainers + +Below is the list of emeritus (retired) Maintainers. We thank them for their +contributions to the project. + + + +| GitHub ID | Name | Company / Organization | +| :-------: | :--: | :--------------------: | + + diff --git a/roles/Members.md b/roles/Members.md new file mode 100644 index 0000000..8aeb727 --- /dev/null +++ b/roles/Members.md @@ -0,0 +1,31 @@ +# Members + +This document lists all current Members of the AReaL community. Membership is open to +anyone who actively contributes to the project and adheres to our +[Code of Conduct](../CODE_OF_CONDUCT.md). For details on the Member role, see +[COMMUNITY_LADDER.md](../COMMUNITY_LADDER.md#member) and +[COMMUNITY_MEMBERSHIP.md](../COMMUNITY_MEMBERSHIP.md#how-to-become-a-member). + +## Current Members + + + +| GitHub ID | Name | Company / Organization | +| :-------: | :--: | :--------------------: | + + + +> No Members have been elected yet. To nominate a candidate, follow the +> [Election Process](../COMMUNITY_MEMBERSHIP.md#election-process). + +## Emeritus Members + +Below is the list of emeritus (retired) Members. We thank them for their contributions +to the project. + + + +| GitHub ID | Name | Company / Organization | +| :-------: | :--: | :--------------------: | + + diff --git a/roles/README.md b/roles/README.md new file mode 100644 index 0000000..7135aad --- /dev/null +++ b/roles/README.md @@ -0,0 +1,23 @@ +# Community Roles + +This directory lists the people who hold the various roles within the AReaL community. +For a description of what each role involves — including responsibilities, +qualifications, and privileges — see the [Contributor Ladder](../COMMUNITY_LADDER.md). +For the processes used to join, advance, or step down from a role, see +[Community Membership](../COMMUNITY_MEMBERSHIP.md). + +## Maintainers + +The list of current Maintainers is in [Maintainers.md](Maintainers.md). + +## Approvers + +The list of current Approvers is in [Approvers.md](Approvers.md). + +## Members + +The list of current Members is in [Members.md](Members.md). + +## Security Team + +The list of Security Team members is in [Security-Team.md](Security-Team.md). diff --git a/roles/Security-Team.md b/roles/Security-Team.md new file mode 100644 index 0000000..b43d79c --- /dev/null +++ b/roles/Security-Team.md @@ -0,0 +1,28 @@ +# Security Team + +The AReaL Security Team is responsible for coordinating the response to security +vulnerabilities and maintaining the security posture of the project. + +## Composition + +The Security Team consists of all current active Maintainers as listed in +[Maintainers.md](Maintainers.md). All Maintainers are members of the Security Team by +virtue of their role. + +## Responsibilities + +- Review and respond to security vulnerability reports. +- Coordinate with reporters and the community on security issues. +- Develop and review security patches. +- Manage the security disclosure process. +- Maintain the project's security policy and procedures. + +## Communication + +Security reports and Security Team discussions are kept private to protect users until a +fix is available. See [SECURITY.md](../SECURITY.md) for the disclosure channels. + +## Security Policy + +For the complete security policy and reporting procedures, please refer to +[SECURITY.md](../SECURITY.md).