Code of Conduct
By participating in this project, you agree to maintain a respectful and inclusive environment. Be kind, patient, and considerate to other contributors.Prerequisites
Before you begin, ensure you have the following installed:- Node.js 20 or higher
- pnpm 8 or higher
- PostgreSQL 15 or higher
- Git for version control
- Docker for testing daemon integration
Making Changes
Branch Naming
Branch names should use descriptive names. Including Linear ticket IDs is recommended but optional: With Linear tickets (recommended):feat/STE-123-add-backup-encryption- New featuresfix/STE-456-console-reconnect-issue- Bug fixesdocs/STE-789-update-api-reference- Documentationrefactor/STE-321-cleanup-auth-middleware- Code improvements
feat/add-backup-encryptionfix/console-reconnect-issuedocs/update-api-referencerefactor/cleanup-auth-middleware
Commit Messages
We use Conventional Commits with optional Linear ticket IDs. Linear tickets are strongly recommended for tracking but not required. Format:| Type | Description |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation changes |
style | Code formatting (no logic change) |
refactor | Code restructuring |
test | Test additions or updates |
chore | Maintenance tasks |
perf | Performance improvements |
ci | CI/CD changes |
build | Build system changes |
Getting Linear Tickets:View tickets at linear.app/stellarstack. Create a new issue for your work before committing (recommended) and reference the ticket ID in your commit message for better tracking.
- Commit type is valid (feat, fix, docs, etc.)
- Description is not empty
Code Style
- TypeScript: Use strict TypeScript with proper types
- Formatting: Code is formatted with Prettier (run automatically on commit)
- Linting: Follow ESLint rules
- Naming: Use camelCase for variables/functions, PascalCase for components/types
Testing Your Changes
Before submitting a PR, run the following checks:Pull Requests
Before Submitting
PR Guidelines
- Title: Use a clear, descriptive title
- Description: Explain what changes you made and why
- Screenshots: Include screenshots for UI changes
- Breaking Changes: Clearly note any breaking changes
PR Checklist
When opening a pull request, ensure you’ve completed:- My code follows the project’s style guidelines
- I have performed a self-review
- I have added comments for hard-to-understand code
- I have updated relevant documentation
- My changes don’t generate new warnings
- I have tested my changes locally
Releases
StellarStack uses automated releases powered by release-please. You don’t need to worry about versioning or changelogs—they’re generated automatically.How It Works
-
Commit with Conventional Format: Your commits following the conventional format drive the release process
feat:commits trigger a minor version bump (0.1.0 → 0.2.0)fix:commits trigger a patch version bump (0.1.0 → 0.1.1)BREAKING CHANGE:in commit body triggers a major version bump (0.1.0 → 1.0.0)
-
Release PR Created: When commits are merged to
master, release-please automatically:- Analyzes commits since last release
- Determines the next version number
- Generates a CHANGELOG.md with categorized changes
- Creates a pull request with these updates
-
Merge to Release: When the release PR is merged:
- A GitHub release is created with the new version tag
- Linear ticket IDs in the changelog are automatically linked
- Docker images are built and pushed to Docker Hub
- The manifest file is updated with the new version
Linear Ticket Links
Release notes automatically link Linear tickets. For example:- Commit:
feat: STE-123 add backup encryption - Changelog:
feat: [STE-123](https://linear.app/stellarstack/issue/STE-123) add backup encryption
Areas for Contribution
Good First Issues
Look for issues labeledgood first issue - these are beginner-friendly tasks.
High Priority Areas
- Documentation: Improving guides and API docs
- Testing: Adding unit and integration tests
- UI/UX: Accessibility improvements
- Performance: Optimizing slow operations
- Security: Identifying and fixing vulnerabilities
Feature Requests
Before starting work on a new feature:- Check if an issue already exists
- Create an issue to discuss the feature
- Wait for maintainer feedback before starting
Reporting Bugs
Before Reporting
- Search existing issues to avoid duplicates
- Try reproducing with the latest version
- Check if it’s a known issue in the README
Bug Report Template
When reporting a bug, include:- Description: Clear description of the bug
- Steps to Reproduce: Numbered list of steps
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Environment: OS, browser, Node.js version, StellarStack version
- Screenshots/Logs: Relevant screenshots or error logs
Security Vulnerabilities
Instead, please email [email protected] with:- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
Questions?
- Discord: Join our Discord server for real-time help
- Discussions: Use GitHub Discussions for questions
- Issues: For bugs and feature requests
License
By contributing to StellarStack, you agree that your contributions will be licensed under the MIT License.Thank you for contributing to StellarStack! Your help makes this project better for everyone.