0. Contribution guidelines

Contributing to Atom

Thank you for your interest in contributing to Atom! This guide will help you understand our development workflow and ensure a smooth collaboration process.

Before You Start

While we welcome all contributions (bugfixes, features, refactors), we want to maintain a standard. Contributions are evaluated based on their alignment with the goals of Atom CMS and overall quality. Not all submissions will be merged into the official repository.

Focused Pull Requests

Keep each Pull Request focused on a single concern. A PR should represent one logical change, feature, or fix. This makes reviewing easier, reduces the chance of bugs, and helps maintain a clean git history.

Do

• Create separate PRs for unrelated changes, even if they modify the same files
• Keep refactoring separate from feature additions
• Split large features into smaller, logical chunks that can be reviewed independently

Avoid

• Mixing multiple unrelated changes in one PR
• Combining style changes with functional changes
• Adding extra "while I'm here" improvements

For example, if you find a bug while working on a new feature, create a separate PR for the bug fix rather than combining both changes. Similarly, if you want to refactor code and add functionality, these should be two different PRs.

Remember: Small, focused PRs get reviewed faster and are more likely to be merged smoothly.

Branch Management

⚠️ Important
Always branch from dev. Never branch from custom feature branches

Creating New Branches

1. Checkout the dev branch
2. Pull the latest changes
3. Create your new branch

ℹ️ Branch Naming Convention
Format: type/description

Examples:

• feature/force-two-factor-auth-for-staff
• bugfix/user-settings-not-able-to-save
• refactor/user-settings-into-service-pattern

Commit Guidelines

📝 Conventional Commits
We follow the Conventional Commits specification for commit messages. This helps maintain a clear and standardized commit history.

Format: type(scope): description

Examples:

• feat(auth): implement two-factor authentication
• fix(settings): resolve user settings save issue
• refactor(user): migrate to service pattern

Read more about Conventional Commits

Pull Request Process

When your contribution is ready for review, create a pull request. The pull request will be reviewed as soon as possible and may:

• Merge it directly if everything looks good
• Provide feedback or suggestions for improvement
• Ask questions about implementation details

Feedback Process

Comments on your pull request are meant to:

1. Improve code quality
2. Clarify implementation decisions
3. Share knowledge between team members

💌 Feedback Culture
Please don't view feedback negatively. If you disagree with suggestions, feel free to explain your reasoning. We value open and respectful discussion.