Skip to content

Commit bc0b7e5

Browse files
wooway777wooway777
authored
Merge pull request #359 from InfiniTensor/chore/standard-contribution-requirements
chore: add standard contribution requirements
2 parents eed9fe9 + d93ca28 commit bc0b7e5

5 files changed

Lines changed: 910 additions & 0 deletions

File tree

‎.github/PULL_REQUEST_TEMPLATE.md‎

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
<!--
2+
Thanks for contributing to InfiniLM! Please read `CONTRIBUTING.md` before
3+
opening a pull request and fill out every section below. Delete any section
4+
that is genuinely not applicable (and note why), but do not delete the
5+
"Checklist" section — it must be filled in for every PR.
6+
7+
The PR title MUST follow Conventional Commits, e.g.
8+
feat: support Llama 3 models
9+
fix: correct linear attention calculations
10+
See: https://www.conventionalcommits.org/
11+
-->
12+
13+
## Summary
14+
15+
<!--
16+
A concise description of **what** this PR changes. Prefer bullet points over
17+
prose. Reference files with backtick-fenced paths (e.g. `csrc/models/llama/*`).
18+
-->
19+
20+
-
21+
-
22+
23+
## Motivation
24+
25+
<!--
26+
Explain **why** this change is needed. Link to any related issue, bug, or
27+
discussion. If this is a performance change, include before/after numbers
28+
(hardware, shape, dtype, and the measurement methodology).
29+
-->
30+
31+
Closes #
32+
33+
## Type of Change
34+
35+
<!-- Tick one or more. -->
36+
37+
- [ ] `feat` — new feature / new model
38+
- [ ] `fix` — bug fix
39+
- [ ] `perf` — performance improvement (no behavioral change)
40+
- [ ] `refactor` — code restructuring without behavior change
41+
- [ ] `test` — adding or fixing tests only
42+
- [ ] `docs` — documentation only
43+
- [ ] `build` / `ci` — build system or CI configuration
44+
- [ ] `chore` — tooling, formatting, or other non-code changes
45+
- [ ] Breaking change
46+
47+
## Test Results of Involved Models on Supported Platforms (Please attach screenshots)
48+
49+
<!--
50+
For now, provide the screenshots for involved tests performed on platforms supposed to support the changes.
51+
52+
Tests that might be involved:
53+
Single request test: examples/test_infer.py
54+
Offline performance: examples/bench.py
55+
Sanity test: test/bench/test_benchmark.py
56+
Service: python/infinilm/server/inference_server.py + scripts/test_perf.py
57+
58+
Model adaptations may involve all four tests, unless specifying partial support for vastly new structures and confirmed with admin.
59+
60+
Python-level changes may involve less tests depending on which files/features are modified.
61+
62+
Framework-level and Python-level changes may affect different models. Test a few models that might be affected.
63+
-->
64+
65+
## Benchmark / Performance Impact
66+
67+
<!--
68+
Required for `perf` PRs; optional otherwise. Describe the benchmark harness,
69+
shapes, dtypes, hardware, and include baseline vs. new numbers. If the PR is
70+
not performance-sensitive, write "N/A".
71+
-->
72+
73+
## Notes for Reviewers
74+
75+
<!--
76+
Anything reviewers should focus on: subtle invariants, known trade-offs,
77+
follow-up work intentionally left out of scope, etc.
78+
-->
79+
80+
---
81+
82+
## Checklist
83+
84+
> Every contributor **must** verify every item below before requesting
85+
> review. Tick each box only after the check has actually been performed —
86+
> do not tick speculatively. If an item truly does not apply, replace the
87+
> checkbox with `N/A` and briefly explain why in an inline comment.
88+
89+
### Title, Branch, and Commits
90+
91+
- [ ] PR **title** follows [Conventional Commits](https://www.conventionalcommits.org/) (e.g. `feat(nvidia): …`, `fix(cuda/gemm): …`).
92+
- [ ] Branch name follows `<type>/xxx-yyyy-zzzz` where `<type>` matches the PR title's Conventional Commits type and words are joined with hyphens (see `CONTRIBUTING.md` §Branches).
93+
- [ ] Each **commit** message follows Conventional Commits.
94+
- [ ] Small PR is a **single squashable commit**; or, for a large PR, every commit is meaningful, well-formed, and independently reviewable (see `CONTRIBUTING.md` §Pull Requests).
95+
- [ ] No stray merge commits from `main` — the branch is rebased cleanly on top of the current `main`.
96+
- [ ] No `fixup!` / `squash!` / `wip` commits remain.
97+
- [ ] Existing PR/branch/commit that followed the legacy issue format.
98+
99+
### Scope and Design
100+
101+
- [ ] Changes are **minimal** — nothing unrelated to the stated motivation was added (`CONTRIBUTING.md` §Code/General).
102+
- [ ] No dead code, commented-out blocks, debug prints, `printf`/`std::cout`/`print(...)` left behind, or `TODO` without an owner and issue link.
103+
- [ ] No unrelated formatting churn that would obscure the diff.
104+
- [ ] Public API changes (if any) are intentional, documented, and reflected in affected callers/tests.
105+
106+
### General Code Hygiene (applies to all languages)
107+
108+
- [ ] The code is self-explanatory; comments were added **only** where the *why* is non-obvious (`CONTRIBUTING.md` §Code/General).
109+
- [ ] Every modified or added file **ends with a single trailing newline** (`CONTRIBUTING.md` §Code/General).
110+
- [ ] No trailing whitespace, tab/space mixing, or stray BOMs.
111+
- [ ] Identifiers in comments and error messages are wrapped in backticks (e.g. ``the `seqlens_k` tensor``) (`CONTRIBUTING.md` §Code/General).
112+
- [ ] All comments and error messages are in **English** (`CONTRIBUTING.md` §Code/General).
113+
- [ ] Comments and error messages are complete sentences — capitalized first letter, terminal punctuation — **unless** the language/framework convention says otherwise (`CONTRIBUTING.md` §Code/General; §Python).
114+
115+
### C++ Specific (if C++ files changed)
116+
117+
- [ ] Code follows the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) strictly.
118+
- [ ] Error and warning message wording follows the [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html#error-and-warning-messages) (`CONTRIBUTING.md` §C++).
119+
- [ ] Constructor **initializer list order matches member declaration order** (`CONTRIBUTING.md` §C++).
120+
- [ ] No raw `new`/`delete`; RAII / smart pointers / existing allocators are used.
121+
- [ ] Changed files are formatted by `scripts/format.py`.
122+
- [ ] No changes/reference to `csrc/models/llama_legacy/`.
123+
124+
### Python Specific (if Python files changed)
125+
126+
- [ ] Code is [PEP 8](https://peps.python.org/pep-0008/) compliant.
127+
- [ ] Comments are complete English sentences, starting with a capital letter and ending with punctuation; Markdown backticks are used for code references (`CONTRIBUTING.md` §Python).
128+
- [ ] Docstrings (if any) follow [PEP 257](https://peps.python.org/pep-0257/) (`CONTRIBUTING.md` §Python).
129+
- [ ] Changed files are formatted by `scripts/format.py`.
130+
- [ ] No changes/reference to `python/infinilm/auto_config.py`.
131+
132+
### Testing
133+
134+
- [ ] For any platform that could not be tested, an explicit reason is given in the table and a reviewer with access has been tagged.
135+
- [ ] Passed single request test (`examples/test_infer.py`), or specify the reason for skipping.
136+
- [ ] Passed offline performance test (`examples/bench.py`), or specify the reason for skipping.
137+
- [ ] Passed sanity test (`test/bench/test_benchmark.py`), or specify the reason for skipping.
138+
- [ ] Passed service test (`python/infinilm/server/inference_server.py` + `scripts/test_perf.py`), or specify the reason for skipping.
139+
140+
### Build, CI, and Tooling
141+
142+
- [ ] The project builds cleanly from a fresh directory on at least one affected platform.
143+
144+
### Documentation
145+
146+
- [ ] `README.md`, `CONTRIBUTING.md`, or inline docs updated when behavior, build flags, or developer workflow changed.
147+
- [ ] Any user-visible breaking change is called out explicitly under "Motivation" **and** in the commit/PR title with a `!` or `BREAKING CHANGE:` footer.
148+
149+
### Security and Safety
150+
151+
- [ ] No secrets, access tokens, internal URLs, customer data, or personal hardware identifiers have been committed.
152+
- [ ] Third-party code is license-compatible and attributed.
153+
- [ ] No unsafe pointer arithmetic, uninitialized reads, or missing bounds checks were introduced.

‎CONTRIBUTING.md‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Contributing Guide
2+
3+
For development setup, see [Development Guide](#development-guide) below.
4+
5+
## Code
6+
7+
Please review these details before committing, especially for AI-generated code.
8+
9+
### General
10+
11+
1. Keep changes minimal — do not add what is not necessary.
12+
2. Comments are not always better when abundant. Ideally, the code should be self-explanatory.
13+
3. Files must end with a newline.
14+
4. Use Markdown syntax (backtick-fenced) for identifiers in comments and error messages.
15+
5. Comments and error messages must be in English.
16+
6. Comments and error messages should follow the language's conventions first. If the language does not specify, use complete sentences — capitalize the first letter and end with punctuation.
17+
18+
### C++
19+
20+
1. Unless specified in [Adapt New Models](MODELS.md), follow the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) strictly. Use the default `.clang-format`.
21+
2. Error and warning messages follow the [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html#error-and-warning-messages).
22+
3. Initializer list order must match member declaration order.
23+
4. Formatted by `scripts/format.py`
24+
25+
### Python
26+
27+
Unless specified in [Adapt New Models](MODELS.md), follow [PEP 8](https://peps.python.org/pep-0008/) as the primary style guide. For anything PEP 8 does not cover in detail, refer to the [GDScript style guide](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html)—while it targets a different language, its non-syntax conventions are still applicable.
28+
29+
Formatted by `scripts/format.py`
30+
31+
#### Additional Rules
32+
33+
1. **Comments** should be complete English sentences, starting with a capital letter and ending with punctuation. Use Markdown syntax when referencing code within comments.
34+
35+
2. **Docstrings:** Follow [PEP 257](https://peps.python.org/pep-0257/) conventions.
36+
37+
3. Formatted by `scripts/format.py`
38+
39+
## Commits
40+
41+
Commit messages must follow [Conventional Commits](https://www.conventionalcommits.org/).
42+
43+
Existing commit messages may follow the "issue/### - " legacy format with an issue created to describe the case.
44+
45+
## Pull Requests
46+
47+
1. Small PRs should be squashed. Large PRs may keep multiple commits, but each commit must be meaningful and well-formed.
48+
2. PR titles should respect to issue number and case summary.
49+
3. Before merging (or after each stage of changes), build and test on major involved platforms. Include the results in PRs.
50+
51+
## Branches
52+
53+
Branch names use the format `<type>/xxx-yyyy-zzzz`, where `<type>` matches the PR title's Conventional Commits type, and words are joined with hyphens.
54+
55+
Existing branch names may use the legacy format `issue/###`, followed by a suffix when necessary.
56+
57+
---
58+
59+
# Development Guide
60+
61+
Refer to [ReadMe](README.md) and [Adapt New Models](MODELS.md)
62+
63+
## Troubleshooting
64+
65+
1. to be populated

0 commit comments

Comments
 (0)