chrisryn/requestarr
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

chore: updated the Contributing and Security guides to reflect our current practices (#2579)

Browse Source
This commit is contained in:
Ludovic Ortega
2026-02-27 15:23:42 +01:00
committed by GitHub
parent 10ea21b20f
commit 0d40a42de7
2 changed files with 51 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
CONTRIBUTING.md
View File

@@ -75,7 +75,7 @@ Please be respectful to maintainers and disclose AI assistance.
3. Create a new branch:
```bash
git checkout -b BRANCH_NAME develop
git switch -c BRANCH_NAME develop
```
- It is recommended to give your branch a meaningful name, relevant to the feature or fix you are working on.
@@ -127,11 +127,10 @@ Steps:
### Contributing Code
- If you are taking on an existing bug or feature ticket, please comment on the [issue](/../../issues) to avoid multiple people working on the same thing.
- All commits **must** follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
- Pull requests with titles or commits not following this standard will **not** be merged. PR titles are automatically checked for compliance.
- Pull requests with titles not following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) will **not** be merged. PR titles are automatically checked for compliance.
- Please make meaningful commits, or squash them prior to opening a pull request.
- Do not squash commits once people have begun reviewing your changes.
- Always rebase your commit to the latest `develop` branch. Do **not** merge `develop` into your branch.
- Always rebase your branch to the latest `develop` branch.
- It is your responsibility to keep your branch up-to-date. Your work will **not** be merged unless it is rebased off the latest `develop` branch.
- You can create a "draft" pull request early to get feedback on your work.
- Your code **must** be formatted correctly, or the tests will fail.
@@ -180,10 +179,10 @@ PGPASSWORD=postgres sudo docker exec -it postgres-seerr /usr/bin/psql -h 127.0.0
PGPASSWORD=postgres sudo docker exec -it postgres-seerr /usr/bin/psql -h 127.0.0.1 -U postgres -c "CREATE DATABASE seerr;"
```
3. Checkout the `develop` branch and create the original database for SQLite and PostgreSQL so that TypeORM can automatically generate the migrations:
3. Switch to the `develop` branch and create the original database for SQLite and PostgreSQL so that TypeORM can automatically generate the migrations:
```bash
git checkout develop
git switch develop
pnpm i
rm -r .next dist; pnpm build
pnpm start
@@ -195,7 +194,7 @@ DB_TYPE="postgres" DB_USER=postgres DB_PASS=postgres pnpm start
4. Let TypeORM generate the migrations:
```bash
git checkout -b your-feature-branch
git switch -c your-feature-branch
pnpm i
pnpm migration:generate server/migration/sqlite/YourMigrationName
DB_TYPE="postgres" DB_USER=postgres DB_PASS=postgres pnpm migration:generate server/migration/postgres/YourMigrationName

45
SECURITY.md
View File

@@ -8,6 +8,51 @@ To report a security issue, please use the GitHub Security Advisory ["Report a V
**Please do not report security vulnerabilities through public GitHub issues, discussions, or Discord.**
## AI Assistance Notice
> [!IMPORTANT]
>
> Automated AI-generated contributions without human review are not allowed and will be rejected.
> This is an open-source project maintained by volunteers.
> We do not have the resources to review pull requests that could have been avoided with proper human oversight.
> While we have no issue with contributors using AI tools as an aid, it is your responsibility as a contributor to ensure that all submissions are carefully reviewed and meet our quality standards.
> Submissions that appear to be unreviewed AI output will be considered low-effort and may result in a ban.
>
> If you are using **any kind of AI assistance** to contribute to Seerr,
> it must be disclosed in the pull request.
If you are using any kind of AI assistance while contributing to Seerr,
**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 security advisory responses are being generated by an AI, disclose that as well.
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 security advisory 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 most cases
it's generating slop. 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 maintainers job to review a PR so broken that it requires
significant rework to be acceptable.
Please be respectful to maintainers and disclose AI assistance.
## What to Include in Your Report
To help us better understand and resolve the issue, please include as much of the following information as possible: