Mirrors/asciinema
1
0
Fork 0
mirror of https://github.com/asciinema/asciinema.git synced 2026-08-29 01:58:38 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update contribution guidelines

Browse Source
This commit is contained in:
Marcin Kulik
2026-08-13 19:17:26 +00:00
parent 0c64e7cb70
commit 7749806198
1 changed files with 12 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
CONTRIBUTING.md
View File

@@ -93,8 +93,12 @@ What we look for in a PR:
- Match the style and conventions of the surrounding code, and run the - Match the style and conventions of the surrounding code, and run the
repository's formatter before submitting. repository's formatter before submitting.
- Make sure the test suite passes, and add tests covering new behavior. - Make sure the test suite passes, and add tests covering new behavior.
- Write the description yourself, in your own words: what the change does, - Understand every change you submit. You should be able to explain what it
why, and how you tested it. does, how it interacts with the rest of the project, and answer review
questions yourself.
- Write the description yourself, in your own words: what the change does, why,
and how you tested it. The same goes for discussion threads and review
replies.
We care about the long-term shape of the codebase, so reviews can be picky We care about the long-term shape of the codebase, so reviews can be picky
about naming, structure and consistency, even when a change already works. about naming, structure and consistency, even when a change already works.
@@ -110,20 +114,13 @@ patience is appreciated.
## AI-assisted contributions ## AI-assisted contributions
It's fine to use AI coding tools when working on a contribution. A few If you use AI coding tools, note that in your PR description: which tool, and
expectations keep this working well for everyone: to what extent (e.g. "wrote the first draft, which I then reviewed and
reworked").
- **Disclose AI use in your PR description**: which tool, and to what extent The expectations above apply no matter how a change was produced. Reviewing a
(e.g. "wrote the first draft, which I then reviewed and reworked"). change is often more work than writing it, and you are the one who needs to
- **You must fully understand your changes.** You should be able to explain understand, test and stand behind what you submit.
what the code does, how it interacts with the rest of the project, and
answer review questions yourself.
- **Write in your own voice.** PR descriptions, discussion threads and review
replies should be written by you, not generated.
Reviewing a change is often more work than writing it. These expectations keep
maintainer review time going where it matters: changes that a human has
already understood, tested and stands behind.
## Community ## Community