chore: add contributing.md and code of conduct
This commit is contained in:
Hampus Kraft
parent
2cd7aa5863
commit
2ea1c6ba2e
92
CODE_OF_CONDUCT.md
Normal file
92
CODE_OF_CONDUCT.md
Normal file
@ -0,0 +1,92 @@
|
|||||||
|
# Code of Conduct
|
||||||
|
|
||||||
|
## Our Pledge
|
||||||
|
|
||||||
|
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
|
||||||
|
|
||||||
|
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
|
||||||
|
|
||||||
|
## Our Standards
|
||||||
|
|
||||||
|
Examples of behavior that contributes to a positive environment for our community include:
|
||||||
|
|
||||||
|
- demonstrating empathy and kindness toward other people
|
||||||
|
- being respectful of differing opinions, viewpoints, and experiences
|
||||||
|
- giving and gracefully accepting constructive feedback
|
||||||
|
- accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
|
||||||
|
- focusing on what is best not just for us as individuals, but for the overall community
|
||||||
|
|
||||||
|
Examples of unacceptable behavior include:
|
||||||
|
|
||||||
|
- the use of sexualized language or imagery, and sexual attention or advances of any kind
|
||||||
|
- trolling, insulting or derogatory comments, and personal or political attacks
|
||||||
|
- public or private harassment
|
||||||
|
- publishing others' private information, such as a physical or email address, without their explicit permission
|
||||||
|
- other conduct which could reasonably be considered inappropriate in a professional setting
|
||||||
|
|
||||||
|
## Enforcement Responsibilities
|
||||||
|
|
||||||
|
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
|
||||||
|
|
||||||
|
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
||||||
|
|
||||||
|
## Reporting
|
||||||
|
|
||||||
|
If you experience or witness unacceptable behavior, please report it as soon as possible.
|
||||||
|
|
||||||
|
How to report:
|
||||||
|
|
||||||
|
- Email the maintainers at: developers@fluxer.app
|
||||||
|
- If your report involves someone who may have access to that inbox, you can instead contact a maintainer privately on GitHub.
|
||||||
|
|
||||||
|
All complaints will be reviewed and investigated promptly and fairly.
|
||||||
|
|
||||||
|
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
|
||||||
|
|
||||||
|
## Enforcement
|
||||||
|
|
||||||
|
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
|
||||||
|
|
||||||
|
### 1) Correction
|
||||||
|
|
||||||
|
Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
|
||||||
|
|
||||||
|
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
|
||||||
|
|
||||||
|
### 2) Warning
|
||||||
|
|
||||||
|
Community Impact: A violation through a single incident or series of actions.
|
||||||
|
|
||||||
|
Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
|
||||||
|
|
||||||
|
### 3) Temporary Ban
|
||||||
|
|
||||||
|
Community Impact: A serious violation of community standards, including sustained inappropriate behavior.
|
||||||
|
|
||||||
|
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
|
||||||
|
|
||||||
|
### 4) Permanent Ban
|
||||||
|
|
||||||
|
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
|
||||||
|
|
||||||
|
Consequence: A permanent ban from any sort of public interaction within the community.
|
||||||
|
|
||||||
|
## Attribution
|
||||||
|
|
||||||
|
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at:
|
||||||
|
|
||||||
|
- https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
||||||
|
|
||||||
|
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
|
||||||
|
|
||||||
|
For answers to common questions about this code of conduct, see the FAQ:
|
||||||
|
|
||||||
|
- https://www.contributor-covenant.org/faq
|
||||||
|
|
||||||
|
Translations are available at:
|
||||||
|
|
||||||
|
- https://www.contributor-covenant.org/translations
|
||||||
163
CONTRIBUTING.md
Normal file
163
CONTRIBUTING.md
Normal file
@ -0,0 +1,163 @@
|
|||||||
|
# Contributing to fluxerapp/fluxer
|
||||||
|
|
||||||
|
Thanks for contributing. This document explains how we work so your changes can land smoothly, and so nobody wastes time on work we cannot merge.
|
||||||
|
|
||||||
|
## Quick rules (please read)
|
||||||
|
|
||||||
|
### 1) All PRs must target `canary`
|
||||||
|
|
||||||
|
`canary` is our trunk branch. Open all pull requests against `canary`. PRs targeting other branches will be closed or you will be asked to retarget.
|
||||||
|
|
||||||
|
### 2) All PRs must include a short description
|
||||||
|
|
||||||
|
Every PR must include a short description covering:
|
||||||
|
|
||||||
|
- what changed
|
||||||
|
- why it changed
|
||||||
|
- anything reviewers should pay attention to
|
||||||
|
|
||||||
|
A few bullets is perfect.
|
||||||
|
|
||||||
|
### 3) Coordinate before starting larger work
|
||||||
|
|
||||||
|
If you are planning anything beyond a small, obvious fix (new feature, meaningful refactor, new dependency, new API surface, behavior changes), coordinate with the maintainers first.
|
||||||
|
|
||||||
|
This avoids the mutual displeasure of:
|
||||||
|
|
||||||
|
- you investing significant time, and
|
||||||
|
- us having to reject or postpone the change because it does not align with current goals, or because we are not ready to maintain what it introduces
|
||||||
|
|
||||||
|
Ways to coordinate:
|
||||||
|
|
||||||
|
- open an issue describing the problem and your proposed approach
|
||||||
|
- open a draft PR early to confirm direction
|
||||||
|
- discuss with a maintainer in any channel you already share
|
||||||
|
|
||||||
|
If you are unsure whether something counts as "larger work", ask first.
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
1. Fork the repo (or create a branch if you have access).
|
||||||
|
2. Create a feature branch from `canary`.
|
||||||
|
3. Make changes.
|
||||||
|
4. Open a PR into `canary` with a short description.
|
||||||
|
5. Address review feedback and CI results.
|
||||||
|
6. We squash-merge approved PRs into `canary`.
|
||||||
|
|
||||||
|
We strongly prefer small, focused PRs that are easy to review.
|
||||||
|
|
||||||
|
### Commit style and history
|
||||||
|
|
||||||
|
We squash-merge PRs, and the PR title becomes the single commit message on `canary`. For that reason:
|
||||||
|
|
||||||
|
- PR titles must follow Conventional Commits.
|
||||||
|
- Individual commits inside the PR do not need to follow Conventional Commits.
|
||||||
|
|
||||||
|
If you like to commit in small increments, feel free. If you prefer a tidier PR history, force-pushes are welcome (for example, to squash or reorder commits before review). Just avoid rewriting history in a way that makes it hard for reviewers to follow along.
|
||||||
|
|
||||||
|
## Conventional Commits (required for PR titles)
|
||||||
|
|
||||||
|
Because the PR title becomes the squash commit message, we require Conventional Commits for PR titles.
|
||||||
|
|
||||||
|
We prefer type/subject to be mostly lowercase.
|
||||||
|
|
||||||
|
Format:
|
||||||
|
|
||||||
|
- `type(scope optional): short description`
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- `fix: handle empty response from api`
|
||||||
|
- `feat(auth): add passkey login`
|
||||||
|
- `docs: clarify canary workflow`
|
||||||
|
- `refactor: simplify retry logic`
|
||||||
|
- `chore(ci): speed up checks`
|
||||||
|
|
||||||
|
Breaking changes:
|
||||||
|
|
||||||
|
- `feat!: remove legacy auth endpoints`
|
||||||
|
- `refactor(api)!: change pagination shape`
|
||||||
|
|
||||||
|
Common types:
|
||||||
|
`feat`, `fix`, `docs`, `refactor`, `perf`, `test`, `chore`, `ci`, `build`, `revert`
|
||||||
|
|
||||||
|
## Tests (guidance)
|
||||||
|
|
||||||
|
We care about confidence more than ceremony. Add tests when they provide real value.
|
||||||
|
|
||||||
|
### Backend changes
|
||||||
|
|
||||||
|
For backend changes, we suggest adding an integration or unit test.
|
||||||
|
|
||||||
|
- If a unit test would require heavy mocking to be meaningful, either:
|
||||||
|
- restructure the code so it can be tested without excessive mocking, or
|
||||||
|
- prefer an integration test if restructuring is not practical
|
||||||
|
|
||||||
|
- If you are unsure which route is best, discuss it with a maintainer before investing time.
|
||||||
|
|
||||||
|
### Frontend changes
|
||||||
|
|
||||||
|
We generally do not encourage new unit tests for frontend code unless:
|
||||||
|
|
||||||
|
- the area already has unit tests, or
|
||||||
|
- the change is complex or sensitive, and a unit test clearly reduces risk
|
||||||
|
|
||||||
|
In most cases, clear PR notes and practical verification are more valuable.
|
||||||
|
|
||||||
|
## Formatting and linting
|
||||||
|
|
||||||
|
Do not block on formatting or linting before opening a PR. CI enforces required checks and will tell you what needs fixing before merge.
|
||||||
|
|
||||||
|
Open the PR when it is ready for review, then iterate based on CI and feedback.
|
||||||
|
|
||||||
|
## CLA (required)
|
||||||
|
|
||||||
|
We require a Contributor License Agreement (CLA) for this repository.
|
||||||
|
|
||||||
|
Why:
|
||||||
|
|
||||||
|
- The project is available under AGPLv3.
|
||||||
|
- We also offer a commercial license for organizations that cannot (or do not want to) comply with AGPL obligations.
|
||||||
|
- To keep both options possible, we need permission to include contributions in both distributions.
|
||||||
|
|
||||||
|
What it means for you:
|
||||||
|
|
||||||
|
- You keep ownership of your contribution.
|
||||||
|
- You can keep using your contribution in your own work.
|
||||||
|
- You grant us the rights needed to distribute your contribution as part of the project, including under a commercial license.
|
||||||
|
- We may refactor or remove code over time and are not required to include every contribution. However, any distributed version that includes your contribution remains properly licensed under the project license(s) that applied when you contributed.
|
||||||
|
|
||||||
|
How to sign:
|
||||||
|
|
||||||
|
- On your first PR, a bot will comment with a CLA link.
|
||||||
|
- Click it, sign with your GitHub account, and you are done.
|
||||||
|
|
||||||
|
## PR checklist
|
||||||
|
|
||||||
|
Before requesting review:
|
||||||
|
|
||||||
|
- [ ] PR targets `canary`
|
||||||
|
- [ ] PR title follows Conventional Commits (mostly lowercase)
|
||||||
|
- [ ] PR includes a short description of what/why
|
||||||
|
- [ ] Tests added or updated where it makes sense (especially backend changes)
|
||||||
|
- [ ] CI is green (or you are actively addressing failures)
|
||||||
|
- [ ] CLA signed (the bot will guide you)
|
||||||
|
|
||||||
|
Optional but helpful:
|
||||||
|
|
||||||
|
- screenshots or a short recording for UI changes
|
||||||
|
- manual verification steps
|
||||||
|
|
||||||
|
## Code of Conduct
|
||||||
|
|
||||||
|
This project follows a Code of Conduct. By participating, you are expected to uphold it:
|
||||||
|
|
||||||
|
- See [`CODE_OF_CONDUCT.md`](./CODE_OF_CONDUCT.md)
|
||||||
|
|
||||||
|
## Security
|
||||||
|
|
||||||
|
Please do not report security issues via public GitHub issues.
|
||||||
|
|
||||||
|
Use our security policy and reporting instructions here:
|
||||||
|
|
||||||
|
- https://fluxer.app/security
|
||||||
Loading…
x
Reference in New Issue
Block a user