Recruiting & Collaboration

Project Philosophy

SDF does not follow a rigid commercial roadmap or a fixed production objective. Instead, the framework is intentionally developed as an open and evolving engineering environment where contributors can actively influence technical direction, implementation strategy, validation, and future research capabilities.

The project emphasizes curiosity, experimentation, architectural transparency, scientific consistency, and learning through practical engineering work. Contributors are encouraged to ask questions, challenge assumptions, propose ideas, discuss concepts, and participate in architectural evolution.

Contribution is intentionally understood in a broad sense. Participating does not necessarily mean writing large amounts of production code. Valuable contributions can also include:

• Discussing architecture decisions
• Proposing simulation ideas or mission concepts
• Reviewing mathematical and physical models
• Validating simulation behavior
• Reviewing telemetry or UI concepts
• Suggesting numerical or mathematical improvements
• Providing aerospace engineering feedback
• Creating diagrams or technical documentation
• Experimenting with isolated features
• Exploring future research directions

The framework is intentionally structured around modular subsystem boundaries so contributors can engage with isolated areas of interest without needing to understand the entire codebase immediately.

Collaboration & Contribution

Contributions are not limited to predefined tasks. Participants are encouraged to bring their own ideas, technical questions, engineering experience, and research perspectives into the project.

Areas of collaboration currently include:

• 6DoF spacecraft dynamics and physical modeling
• Guidance, navigation, and control
• RCS and propulsion modeling
• Attitude-control systems
• Simulation backend architecture
• Frontend UI and telemetry visualization
• ROS2 and interface abstraction
• Optimization and numerical integration
• Telemetry and research-data workflows
• Documentation and engineering diagrams
• Simulation verification and validation

Issue-Based Development

SDF follows an issue-based development process. Every implementation, validation task, bugfix, architectural change, or major documentation activity should be associated with a GitHub Issue before development begins.

This keeps technical decisions traceable, makes the development roadmap transparent, and allows contributors to understand why a change exists before examining the implementation itself.

Open development tasks and discussions can be found directly in the project's GitHub Issue tracker:

Contributors interested in getting started should particularly look for issues labeled Help Wanted or Good First Issue.

• Help Wanted: Tasks where technical discussion, implementation support, testing, review, or engineering expertise is actively welcome.
• Good First Issue: Smaller or well-isolated tasks suitable for learning the codebase and contribution workflow.

Understanding SDF Issue IDs

SDF uses a lightweight issue-key convention to make the purpose of development tasks immediately visible. An issue identifier consists of a category letter followed by a sequential number.

For example, an issue named D23 - Basic RCS Modelidentifies the task as a developer-oriented implementation issue. The same identifier is then reused in branches and commit messages.

• D — Developer Task: Implementation work, code changes, or smaller technical features
• M — Mathematical Model: Equations, physics models, guidance laws, controller formulations, or optimization models
• A — Architecture: Interfaces, subsystem boundaries, structural changes, or major refactoring
• W — Website / Documentation: Technical documentation, diagrams, mathematical documentation, or website work
• P — Project Management: Milestones, roadmap, repository organization, or planning activities
• F — Feature Proposal: Larger functional extensions or new framework capabilities
• B — Bugfix: Incorrect behavior, defects, or runtime errors
• R — Refactoring: Internal restructuring without an intended functional change
• T — Tests / Validation: Verification, validation, analytical comparison, or simulation testing

The identifier remains visible throughout the development history. A typical development flow may therefore look like:

• Issue: D23 - Basic RCS Model
• Branch: feature/D23-Basic-RCS-Model
• Commit: D23 - Implement RCS actuator dynamics

Development should take place on an issue-specific branch and the resulting Pull Request should reference the corresponding issue. This keeps implementation, discussion, review, and project history connected.

Contribution Workflow

The typical contribution workflow is intentionally lightweight:

1. Find an existing GitHub Issue or create a new one.
2. Discuss the intended change where appropriate.
3. Fork or clone the repository.
4. Create an issue-specific feature branch.
5. Implement and document the change.
6. Commit using the corresponding issue identifier.
7. Submit a Pull Request referencing the issue.

Practical collaboration therefore assumes basic familiarity with Git and GitHub workflows. Contributors do not need to be experts, and support with repository setup, architecture orientation, or the contribution process is welcome.

The complete engineering and contribution guidelines are maintained in the repository documentation.

Current Development Direction

SDF is currently in active pre-release development around its first major technical milestone: M1 - 6DoF Core Simulation.

The complete translational and rotational rigid-body dynamics pipeline has been implemented. Current work focuses on systematic physical and numerical verification, cockpit integration of the rotational state, and extension of the RCS architecture toward dedicated attitude control.

Further development will expand telemetry analysis, numerical methods, control capabilities, environmental models, and external interfaces while preserving the modular architecture of the simulation core.

Engineering Standards

Contributions should preserve the core design principles of the framework. In particular, SDF favors modular and interface-driven implementations, explicit physical assumptions, clear subsystem boundaries, and reproducible simulation behavior.

• Physical quantities should use SI units.
• Public APIs and important functions should include Doxygen documentation.
• Mathematical models should document equations, variables, assumptions, and limitations.
• Frontend components should not depend directly on backend implementation details.
• Simulation data exposed externally should use explicit telemetry structures.
• Architecture and mathematical documentation should be updated when major models or interfaces change.

Scientific consistency and maintainability should take priority over implementation convenience.

Expectations

SDF is not a pressure-driven production project. There are no strict deadlines or mandatory contribution quotas. What matters most is constructive collaboration, curiosity, technical interest, and the motivation to explore engineering concepts together.

Small contributions, isolated experiments, technical discussions, documentation improvements, validation work, and gradual involvement are completely welcome.

Who is this for?

The project is suitable for students, engineers, software developers, researchers, and technically curious contributors interested in simulation, spacecraft dynamics, control systems, telemetry workflows, numerical methods, aerospace software engineering, or modular system architecture.

Formal aerospace experience is not a prerequisite. Motivation, curiosity, technical rigor, and openness to learning are valued more than a specific professional background.