Thank you for your interest in contributing! Following these guidelines ensures high-quality contributions and smooth collaboration.
- Bug Reports: Include clear reproduction steps, logs, and environment details.
- Feature Requests: Open an issue with a concise description and suggested use case.
- Pull Requests: Focus on a single topic and reference related issues.
- Fork the repository and branch from
main. - Follow project coding style.
- Update or add documentation.
- Include tests when applicable.
- Submit your PR with a clear summary.
- Use descriptive names for variables and functions.
- Keep configuration files modular and readable.
- Comment non-obvious code.
- Use
Metrics.function(value)for spacing, margin, radius, and duration (except timers). See Metrics docs. - Prefer module loaders for modules with enable/disable config values to prevent crashes and reduce RAM usage.
We follow the Conventional Commits specification.
Format:
type(scope): short description
Example:
feat(launcher): add fuzzy search
fix(settings): resolve crash when opening panel
refactor(renderer): simplify pipeline logic
| Type | Description |
|---|---|
| feat | New feature |
| fix | Bug fix |
| refactor | Code change without altering behavior |
| docs | Documentation changes |
| style | Formatting / linting changes |
| perf | Performance improvements |
| test | Adding or updating tests |
| build | Build system or dependency changes |
| ci | CI configuration changes |
| chore | Maintenance tasks |
- Use present tense ("add feature", not "added feature").
- Keep the summary under ~72 characters.
- Add a scope when applicable (e.g.,
launcher,settings,renderer).
This section is related to how team/project members work in the repository
Note
All the team/project members are listed in the readme
- All team/project members can commit directly to main.
- They can also maintain all issues, but not suggested to review or merge PRs unless asked by the PR's OP.
This section is related about how maintainers work in the repository
- All maintainers can directly push to main.
- They can also merge PRs and maintain issues.
Caution
Direct pushes to main are prohibited. All work must be done in feature branches.
Format:
collaborator/<username>/<type>/<short-description>
| Segment | Description | Example |
|---|---|---|
collaborator |
Always present | collaborator |
<username> |
GitHub username | alice |
<type> |
Type of work | feat, chore, improvement, fix |
<short-description> |
1–2 word summary of changes | settings-ui, typo-fix |
Examples:
collaborator/alice/feat/settings-ui
collaborator/bob/fix/sidebar-color
collaborator/john/improvement/color-gen
git clone git@github.com:xZepyx/nucleus-shell.git
cd nucleus-shell
git checkout main
git pull origin maingit checkout -b collaborator/<username>/<type>/<short-description>Example:
git checkout -b collaborator/alice/feat/settings-uigit add .
git commit -m "feat: add UI for settings panel"git push origin collaborator/<username>/<type>/<short-description>Example:
git push origin collaborator/alice/feat/settings-ui- Go to GitHub and click Compare & pull request.
- Ensure the base branch is
main. - Submit for review.
❌ Do not merge your own PR.
After your PR is merged:
git checkout main
git pull origin main
git branch -d collaborator/<username>/<type>/<short-description>
git fetch --pruneGitHub may auto-delete the remote branch if enabled.
git checkout collaborator/<username>/<type>/<short-description>
git fetch origin
git merge origin/mainResolve conflicts and push updates before modifying the PR.
- Branch from
main. - Follow naming convention.
- Work locally, commit, and push.
- Open PR to
main. - Delete branch after merge.
- Keep
mainclean and protected.
- Be professional and respectful.
- See the Code of Conduct.
Thank you for contributing!