Reporting Bugs
If something doesn’t work as expected, the best way to help is to open a detailed issue on GitHub so maintainers can reproduce and address the problem.1
Open a GitHub Issue
Navigate to the Bridgex Issues page and click New issue.
2
Describe the bug clearly
Include a short, descriptive title and explain what you expected to happen versus what actually occurred.
3
Provide reproduction steps
List the exact steps needed to reproduce the issue — the more specific, the better. Attach any relevant files or screenshots if applicable.
4
Include your environment details
State your operating system (Windows, macOS, or Linux), Bridgex version (e.g.
v0.2.1), and Rust toolchain version if you are running from source.Suggesting Features
Have an idea that would make Bridgex more useful? Feature requests are tracked on GitHub Issues alongside bug reports.1
Search for existing requests
Before opening a new issue, check whether your idea has already been suggested. You can add a 👍 reaction to show support for existing requests.
2
Open a feature request issue
Create a new issue with a clear title and a description of the feature you have in mind.
3
Explain the benefit
Describe how the feature would benefit users of Bridgex and any relevant context — for example, file formats it would support or workflows it would improve.
Submitting Pull Requests
Code contributions are made through GitHub pull requests. All PRs are reviewed before merging, so please be open to feedback and willing to iterate.1
Fork the repository
Click Fork on the Bridgex GitHub page to create your own copy of the repo.
2
Create a branch from main
Always branch off
main and give your branch a descriptive name:3
Make your changes
Implement your fix or feature. Keep commits focused and atomic — one logical change per commit makes reviewing much easier.
4
Build and test your changes
Run the release build to confirm nothing is broken before submitting:
5
Write clear commit messages
Use concise, descriptive commit messages in the imperative mood (e.g.
Fix encoding error for UTF-8 CSV files). Avoid vague messages like fix stuff or update.6
Reference related issues
In your PR description, reference any related issues using GitHub keywords such as
Closes #42 or Related to #17 so they are linked automatically.7
Open the pull request
Push your branch and open a PR against the
main branch of Dev2Forge/bridgex. Fill in the PR template if one is present.All pull requests are subject to code review. Be open to constructive feedback — maintainers may request changes before a PR is merged.
Development Setup
Bridgex is a native Rust desktop application built with the Freya UI framework. You will need a working Rust toolchain to build and run it locally.Prerequisites
- Rust toolchain (stable channel recommended)
cargo(included with the Rust toolchain)- Git
Cloning and Running Locally
1
Clone the repository
2
Navigate to the Rust source directory
The Rust application lives inside
src/bridgex:3
Run in development mode
Use
cargo run for a fast, unoptimised debug build — ideal when iterating on code:4
Run with Freya devtools (optional)
The
dev feature flag enables the Freya UI devtools panel, which is useful when working on UI components:5
Create a release build
When you are ready to produce an optimised binary, use the release profile:The resulting binary is placed at
target/release/bridgex.6
Install locally (optional)
To install the binary into your Cargo bin directory so you can run it as
bridgex from anywhere on your system:Debug builds (
cargo run) compile faster but are slower at runtime. Release builds (cargo build --release) take longer to compile but produce the optimised binary that end users run.Coding Standards
Bridgex is written entirely in Rust. Please follow these conventions to keep the codebase consistent.Formatting — rustfmt
Formatting — rustfmt
All Rust code must be formatted with The repository follows the standard Rust style as enforced by
rustfmt before submitting a PR. Run it with:rustfmt with default settings. Unformatted code will be flagged during review.Doc comments
Doc comments
Add
/// doc comments to public functions, structs, and modules where the purpose is not immediately obvious from the name alone. Doc comments are particularly important for any types that form part of Bridgex’s internal API.Commit hygiene
Commit hygiene
Keep commits small and focused. Each commit should represent one logical change. Squash work-in-progress commits before opening a PR so the history is clean and reviewable.
UI components — Freya
UI components — Freya
UI code uses the Freya framework. Follow the patterns already established in the codebase for component structure. When working on UI, running with
--features dev enables the Freya devtools overlay for inspecting the element tree.Code of Conduct
Bridgex follows the Contributor Covenant Code of Conduct. All participants — contributors, maintainers, and community members — are expected to uphold these standards in every interaction.Positive behaviour
Demonstrating empathy and kindness, being respectful of differing viewpoints, giving and gracefully accepting constructive feedback, and focusing on what is best for the community.
Unacceptable behaviour
Trolling, insulting or derogatory comments, personal or political attacks, public or private harassment, and publishing others’ private information without permission.