RFC: Centralized community files and automated OWNERS sync

.github/repo-file-sync.yml

@@ -0,0 +1,28 @@
+# Static community files synced to all active repos.
+# OWNERS files are handled separately by the workflow (per-repo content).
+# https://github.com/BetaHuhn/repo-file-sync-action
+
+group:
+  - files:
+      - source: LICENSE
+        dest: LICENSE
+      - source: CODE_OF_CONDUCT.md
+        dest: CODE_OF_CONDUCT.md
+      - source: SECURITY.md
+        dest: SECURITY.md
+    repos:
+      - Project-HAMi/HAMi
+      - Project-HAMi/HAMi-core
+      - Project-HAMi/volcano-vgpu-device-plugin
+      - Project-HAMi/dcu-vgpu-device-plugin
+      - Project-HAMi/dcu-exporter
+      - Project-HAMi/dcu-dcgm
+      - Project-HAMi/ascend-device-plugin
+      - Project-HAMi/HAMi-WebUI
+      - Project-HAMi/k8s-dra-driver
+      - Project-HAMi/HAMi-DRA
+      - Project-HAMi/hami-vnpu-core
+      - Project-HAMi/biren-device-plugin
+      - Project-HAMi/mock-device-plugin
+      - Project-HAMi/ai-benchmark
+      - Project-HAMi/KAI-resource-isolator

.github/workflows/sync-community.yml

@@ -0,0 +1,60 @@
+name: Sync Community Files
+
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  sync-static:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+      - uses: BetaHuhn/repo-file-sync-action@8b92be3375cf1d1b0cd579af488a9255572e4619 # v1
+        with:
+          GH_PAT: ${{ secrets.ORG_PAT }}
+          CONFIG_PATH: .github/repo-file-sync.yml
+
+  sync-generated:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+      - run: pip install pyyaml
+      - run: python3 sync-owners.py
+      - name: Push OWNERS and CONTRIBUTING.md to repos
+        env:
+          GH_TOKEN: ${{ secrets.ORG_PAT }}
+        run: |
+          for dir in generated/*/; do
+            repo=$(basename "$dir")
+            for file in OWNERS CONTRIBUTING.md; do
+              sha=$(gh api "repos/Project-HAMi/$repo/contents/$file" --jq .sha 2>/dev/null) || true
+              echo "=== $repo / $file ==="
+              if [ -n "$sha" ]; then
+                gh api "repos/Project-HAMi/$repo/contents/$file" \
+                  -X PUT \
+                  -f message="sync: update $file from .project" \
+                  -f content="$(base64 -w0 "$dir/$file")" \
+                  -f sha="$sha" \
+                  -f branch=main
+              else
+                gh api "repos/Project-HAMi/$repo/contents/$file" \
+                  -X PUT \
+                  -f message="sync: create $file from .project" \
+                  -f content="$(base64 -w0 "$dir/$file")" \
+                  -f branch=main
+              fi
+            done
+          done

.gitignore

@@ -5,3 +5,4 @@ Thumbs.db
 .vscode/
 *~
 *.swp
+generated/

CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+# HAMi Community Code of Conduct
+
+Please refer to our [HAMi Community Code of Conduct](https://github.com/Project-HAMi/community/blob/main/CODE-OF-CONDUCT.md).

CONTRIBUTING.md

@@ -0,0 +1,157 @@
+# Contributing
+
+Welcome to HAMi!
+
+- [Contributing](#contributing)
+- [Before you get started](#before-you-get-started)
+  - [Code of Conduct](#code-of-conduct)
+  - [Community Expectations](#community-expectations)
+  - [AI Assistance Notice](#ai-assistance-notice)
+- [Getting started](#getting-started)
+- [Your First Contribution](#your-first-contribution)
+  - [Find something to work on](#find-something-to-work-on)
+    - [Find a good first topic](#find-a-good-first-topic)
+      - [Work on an issue](#work-on-an-issue)
+    - [File an Issue](#file-an-issue)
+- [Contributor Workflow](#contributor-workflow)
+  - [Creating Pull Requests](#creating-pull-requests)
+  - [Code Review](#code-review)
+
+# Before you get started
+
+## Code of Conduct
+
+Please make sure to read and observe our [Code of Conduct](/CODE_OF_CONDUCT.md).
+
+## Community Expectations
+
+HAMi is a community project driven by its community which strives to promote a healthy, friendly and productive environment.
+
+## AI Assistance Notice
+
+> [!IMPORTANT]
+>
+> If you are using **any kind of AI assistance** to contribute to HAMi,
+> it must be disclosed in the pull request.
+
+If you are using any kind of AI assistance while contributing to HAMi,
+**this must be disclosed in the pull request**, along with the extent to
+which AI assistance was used (e.g. docs only vs. code generation).
+If PR responses are being generated by an AI, you must still disclose
+it. This requires special care: you must fully understand the reviewer's
+point and critically review any AI-generated text to ensure it is accurate
+and directly addresses the feedback. Never paste AI output verbatim.
+Failure to engage thoughtfully with reviews may result in your PR being
+closed. As a small exception, trivial tab-completion doesn't need to be
+disclosed, so long as it is limited to single keywords or short phrases.
+
+An example disclosure:
+
+> This PR was written primarily by Claude Code.
+
+Or a more detailed disclosure:
+
+> I consulted ChatGPT to understand the codebase but the solution
+> was fully authored manually by myself.
+
+Failure to disclose this is first and foremost rude to the human operators
+on the other end of the pull request, but it also makes it difficult to
+determine how much scrutiny to apply to the contribution.
+
+In a perfect world, AI assistance would produce equal or higher quality
+work than any human. That isn't the world we live in today, and in many cases
+AI-generated code can contain subtle bugs or not adhere to project-specific
+best practices. I say this despite being a fan of and using them successfully
+myself (with heavy supervision)!
+
+When using AI assistance, we expect contributors to understand the code
+that is produced and be able to answer critical questions about it. It
+isn't a maintainer's job to review a PR so broken that it requires
+significant rework to be acceptable.
+
+Please be respectful to maintainers and disclose AI assistance.
+
+# Getting started
+
+- Fork the repository on GitHub
+- Make your changes in your forked repository
+- Submit a Pull Request (PR)
+
+# Your First Contribution
+
+We will help you contribute in different areas such as filing issues, developing features, fixing critical bugs and
+getting your work reviewed and merged.
+
+If you have questions about the development process,
+feel free to [file an issue](https://github.com/Project-HAMi/.project/issues/new/choose).
+
+## Find something to work on
+
+We are always in need of help, whether it's fixing documentation, reporting bugs, or writing code.
+Look for places where best coding practices aren't followed, code refactoring is needed, or tests are missing.
+Here's how you can get started.
+
+### Find a good first topic
+
+There are [multiple repositories](https://github.com/Project-HAMi/) within the HAMi organization.
+Each repository has beginner-friendly issues marked as "good first issues".
+For example, [Project-HAMi/.project](https://github.com/Project-HAMi/.project) has
+[help wanted](https://github.com/Project-HAMi/.project/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) and
+[good first issue](https://github.com/Project-HAMi/.project/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
+labels for issues that should not require deep knowledge of the system.
+We can help new contributors who wish to work on such issues.
+
+Another good way to contribute is to find documentation improvements, such as fixing missing or broken links.
+Please see [Contributing](#contributing) below for the workflow.
+
+#### Work on an issue
+
+When you are willing to take on an issue, simply reply to the issue and a maintainer will assign it to you.
+
+### File an Issue
+
+While we encourage everyone to contribute code, we also appreciate when someone reports an issue.
+Issues should be filed under the appropriate HAMi sub-repository.
+
+*Example:* A HAMi issue should be opened in [Project-HAMi/.project](https://github.com/Project-HAMi/.project/issues).
+
+Please follow the provided submission guidelines when opening an issue.
+
+# Contributor Workflow
+
+Please never hesitate to ask questions or submit a pull request.
+
+This is a rough outline of what a contributor's workflow looks like:
+
+- Create a topic branch from where you want to base the contribution (usually master)
+- Make commits of logical units
+- Push changes in your topic branch to your personal fork of the repository
+- Submit a pull request to [Project-HAMi/.project](https://github.com/Project-HAMi/.project)
+
+## Creating Pull Requests
+
+Pull requests are often called simply "PRs".
+HAMi generally follows the standard [GitHub pull request](https://help.github.com/articles/about-pull-requests/) process.
+To submit a proposed change, please develop the code/fix and add new test cases.
+Before submitting a pull request, run these local verifications to predict whether continuous integration will pass or fail:
+
+* Run and pass `make verify`
+
+## Issue and PR Lifecycle
+
+To keep the project manageable, we apply the following policy to all open issues and pull requests:
+
+- If a maintainer or contributor leaves a comment or review requesting a response, the author has **two weeks** to reply.
+- If there is no response within two weeks, the issue or PR will be closed.
+- Closing is not permanent. If the issue is still relevant or the PR is still needed, it can be reopened or submitted again at any time.
+
+This policy helps us keep the backlog focused and avoids letting stale work block active contributors.
+
+## Code Review
+
+To make it easier for your PR to receive reviews, consider that reviewers will need you to:
+
+* Follow [good coding guidelines](https://github.com/golang/go/wiki/CodeReviewComments)
+* Write [good commit messages](https://chris.beams.io/posts/git-commit/)
+* Break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
+* Separate cosmetics from functional changes. Cosmetic changes (reindentation, whitespace, comment wording, style fixes) must not be mixed with logic changes in the same commit — split them into their own commit. If the cosmetics are unrelated to the PR's purpose, they belong in a separate PR entirely. This keeps diffs reviewable: reviewers should not have to filter out formatting noise to find what actually changed.