Skip to main content

Welcome Contributors!

Thank you for your interest in contributing to Aurora OS. We welcome contributions of all kinds:
  • Code improvements and new features
  • Bug fixes and security patches
  • Documentation updates
  • Test coverage improvements
  • Performance optimizations

Contribution Workflow

1

Fork the Repository

Create your own fork of the Aurora OS repository:
# On GitHub, click "Fork" button
# Then clone your fork
git clone https://github.com/YOUR-USERNAME/aurora-os.git
cd aurora-os
2

Create a Feature Branch

Always create a new branch for your changes:
git checkout -b feature/my-feature
Branch naming conventions:
  • feature/ - New features
  • fix/ - Bug fixes
  • docs/ - Documentation updates
  • refactor/ - Code refactoring
  • test/ - Test improvements
git checkout -b feature/add-networking-stack
3

Make Your Changes

Implement your changes following our coding standards:
  • Follow kernel coding style
  • Use meaningful variable names
  • Add comments for complex logic
  • Keep functions focused and small
// Good: Clear function name and purpose
int allocate_physical_page(uint64_t* phys_addr) {
    // Implementation
}

// Bad: Unclear naming
int alloc(uint64_t* p) {
    // Implementation
}
4

Test Your Changes

Run the full test suite before committing:
# Run all tests
make test

# Test QEMU boot
make run

# Run source validation
for f in tests/source-checks/*.sh; do bash "$f"; done
All tests must pass before your PR can be merged.
5

Commit Your Changes

Use Conventional Commits format:
git commit -m "feat: add TCP/IP networking stack"

Commit Message Format

<type>: <description>

[optional body]

[optional footer]
Types:
  • feat: - New feature
  • fix: - Bug fix
  • docs: - Documentation only
  • refactor: - Code refactoring
  • test: - Adding or updating tests
  • ci: - CI/CD changes
  • chore: - Maintenance tasks
6

Push to Your Fork

git push origin feature/my-feature
7

Open a Pull Request

  1. Go to the original Aurora OS repository on GitHub
  2. Click “New Pull Request”
  3. Select your fork and branch
  4. Fill out the PR template with:
    • Description of changes
    • Related issues
    • Testing performed
    • Screenshots (if applicable)
PR titles should also follow conventional commit format: feat: add networking stack

Code Review Process

1

Automated Checks

Your PR will automatically run:
  • Build verification (all architectures)
  • Unit tests
  • QEMU boot tests
  • Source validation
  • Linting and formatting checks
Fix any failing checks before requesting review.
2

Review Assignment

A maintainer will be automatically assigned to review your PR.
3

Address Feedback

Make requested changes and push updates:
# Make changes based on feedback
git add .
git commit -m "refactor: address review feedback"
git push origin feature/my-feature
The PR will automatically update.
4

Approval and Merge

Once approved, a maintainer will merge your PR.
All PRs require at least one approval before merging.

Branch Protection

The main branch is protected with the following requirements:
  • All CI tests pass
  • Build succeeds for x86_64
  • Unit tests pass
  • QEMU boot test passes
  • No merge conflicts
See docs/branch-protection.md in the repository for detailed configuration.

Development Guidelines

Coding Standards

  • Use C11 standard
  • No standard library dependencies
  • Follow existing code style
  • Add function documentation
  • Keep functions under 100 lines when possible
  • Avoid global variables
/**
 * Allocates a physical page frame.
 *
 * @param phys_addr Output pointer for physical address
 * @return 0 on success, -ENOMEM if no memory available
 */
int allocate_physical_page(uint64_t* phys_addr);
  • Use #![no_std] for kernel code
  • Run cargo fmt and cargo clippy
  • Add /// documentation comments
  • Use unsafe only when necessary
  • Document safety requirements
#![no_std]

/// Kernel capability system.
pub mod caps {
    /// A capability represents a reference to a kernel object
    /// with specific permissions.
    pub struct Capability {
        // ...
    }
}
  • Use GAS syntax (.S files)
  • Add comments explaining register usage
  • Preserve caller-saved registers
  • Document calling conventions
# Context switch: switch from old to new task
# Args: %rdi = old_task, %rsi = new_task
.global context_switch
context_switch:
    # Save old task state
    push %rbp
    push %rbx
    # ... (implementation)

Security Considerations

All security-sensitive code requires extra scrutiny:
  • Memory safety checks
  • Integer overflow protection
  • Capability permission validation
  • Input sanitization
  • Proper error handling
// Bad: No overflow check
void* allocate(size_t count, size_t size) {
    return kmalloc(count * size);
}

// Good: Check for overflow
void* allocate(size_t count, size_t size) {
    if (count > SIZE_MAX / size) {
        return NULL;  // Overflow
    }
    return kmalloc(count * size);
}

Reporting Issues

Bug Reports

When reporting bugs, include:
  1. Description - Clear summary of the issue
  2. Steps to Reproduce - Detailed reproduction steps
  3. Expected Behavior - What should happen
  4. Actual Behavior - What actually happens
  5. Environment - OS, architecture, versions
  6. Logs - Relevant error messages or logs
# Gather version information
uname -a
gcc --version
rustc --version

# Get build logs
make clean
make build 2>&1 | tee build.log

Feature Requests

For feature requests, explain:
  1. Use Case - Why is this feature needed?
  2. Proposed Solution - How should it work?
  3. Alternatives - What alternatives exist?
  4. Implementation Ideas - Any thoughts on implementation?

Code of Conduct

Aurora OS follows a code of conduct to ensure a welcoming community. Key principles:
  • Be respectful and inclusive
  • Focus on constructive feedback
  • Assume good intentions
  • Help newcomers get started
Read the full Code of Conduct at CODE_OF_CONDUCT.md in the repository.

Getting Help

If you need help contributing:

GitHub Discussions

Ask questions and discuss ideas

GitHub Issues

Report bugs and request features

Development Setup

Environment setup guide

Testing Guide

Learn how to test your changes

License

By contributing to Aurora OS, you agree that your contributions will be licensed under the same license as the project.
First-time contributors: Look for issues labeled good-first-issue to get started!

Build docs developers (and LLMs) love