Contributing - makerforgetech/modular-biped GitHub Wiki

Contributing to the project

We encourage active participation, contributions, and discussions from the Modular Biped Robot community. If you have any questions, ideas, suggestions, or would like to share your experiences, you can join our GitHub Discussions section dedicated to the project. It's a great place to engage with other community members, exchange knowledge, and collaborate on the development of biped robotics.

Read more here: Community

You can also join our active Discord Community to post your questions, share your progress, and connect with other makers.

Building an Idea

If you have an idea for a new feature, improvement, or bug fix, you can contribute to the project by creating a new idea in the GitHub discussion group. This will allow you to discuss your idea with the community and get feedback before you start working on it.

There may be others who would like to contribute or use your idea, and it's also a great place to store the documentation so that it isn't lost and forgotten about when the PR is merged.

Pull Request (PR) Guidelines

Thank you for contributing to the project! To keep our codebase clean, stable, and easy to maintain, we ask that you follow these guidelines before submitting a pull request (PR). This will help us review and merge your changes faster.

Checklist for Creating a Pull Request

[ ] Create an idea in the github discussion group and add your documentation there.

[ ] Fork the project

[ ] Create a new branch

[ ] Make your changes

[ ] Test your changes

[ ] Update the documentation

[ ] Submit a PR

The PR template will help you create a description, but here are some pointers to help you get started:

1. Scope & Size

Keep it focused: Each PR should address one well-defined issue or feature. Avoid bundling unrelated changes into a single PR.

Consider whether this change is appropriate for all users, or something specific to your variation only, in which case it can remain part of your own fork and referenced by the community.

Limit the size: PRs over 300-400 lines are harder to review. If your change is over 1000 lines, consider breaking it into smaller, logical PRs.

2. Descriptive Title

Use a clear and concise title that describes the purpose of the change.

Good: Add PID controller for motor module

Bad: Fix stuff

3. Detailed Description

Your PR description should answer these questions:

  • What is this change? Is it a new module, a change to a module, a core improvement, or something else?
  • What does this change do? Explain the feature, bug fix, or improvement.
  • Where is the documentation? Provide a link to the new or updated documentation.
  • Why is this change needed? Describe the motivation or problem it solves.
  • How was it implemented? Summarize the approach and key decisions.
  • Has it been tested using the latest release of the project? If not, it will need to be tested before it is reviewed.
  • Any breaking changes? Mention if this change affects backward compatibility.
  • Related issues: Link to any relevant GitHub issues (e.g., Closes #123).

Example:

What is this change?

A new module: PID controller for motor speed regulation.

What does this change do?

Adds a PID controller implementation for motor speed regulation. [Include as much information as needed to understand the change.]

Where is the documentation?

[link to the new documentation in the discussion group]

Why is this needed?

Without a feedback loop, the motor speed varies significantly under load.

How was it implemented?

  • Added a PIDController class with configurable gains.
  • Integrated it into the motor module.
  • Added unit tests for the new class.

How has it been tested?

  • Manually tested with the latest release of the project.
  • Unit tests added and passing.

Breaking changes

None.

Related issues

Closes #42.

4. Code Quality

Follow project style: Stick to the code style and conventions of the repo.

Keep it clean: Remove unnecessary comments, debug code, and unused variables.

Organize commits: Use clear commit messages and group related changes logically.

Tests: Add or update tests for your code where appropriate. Run python3 -m unittest discover -s tests to ensure all tests pass locally before opening PR.

Docs: Update documentation if your change affects how something works.

5. Review Readiness

Build & tests pass: Ensure your code runs successfully, tests pass, and it is manually tested on the latest release and does not impact other functionality.

Self-review: Read your own diff and check for typos, clarity, and consistency.

Request specific feedback: If there’s an area you’re unsure about, call it out in the description.

6. Collaboration

Stay responsive: Be available to answer questions and make changes during the review.

Be open to feedback: Reviews help improve code quality. Discuss suggestions thoughtfully.

Thank you for helping make the project better! Let’s build something awesome!