[Short one-line description of the organization or project goes here.]
- About
- Getting Started
- Repository Structure
- Branching Strategy
- Contribution Guidelines
- Code Standards
- Commit Message Convention
- Pull Request Process
- Communication
Kranti Robotics is the robotics-focused identity of Kranti Associates Canada Limited, dedicated to [robotics / automation / embedded systems — fill in as appropriate].
This GitHub organization hosts all source code, documentation, and resources related to our engineering projects.
Follow these steps to get set up as a new member:
- Accept the organization invitation sent to your GitHub email.
- Enable two-factor authentication (2FA) on your GitHub account — this is mandatory for all members.
- Clone the relevant repository:
git clone https://github.com/kranti-robotics/<repo-name>.git cd <repo-name>
- Install dependencies (see the individual repository's
README.mdfor specific instructions). - Set up your local environment using the provided
.env.exampleor configuration files.
⚠️ Never commit secrets, API keys, or credentials to any repository.
| Repository | Description | Status |
|---|---|---|
repo-name-1 |
Description | 🟢 Active |
repo-name-2 |
Description | 🟡 In Progress |
repo-name-3 |
Description | 🔴 Archived |
We follow a simplified Git Flow model:
| Branch | Purpose |
|---|---|
main |
Stable, production-ready code |
develop |
Integration branch for ongoing development |
feature/your-feature |
New features (branch off develop) |
fix/issue-description |
Bug fixes |
hotfix/issue-description |
Urgent production fixes (branch off main) |
Rules:
- Never push directly to
mainordevelop. - All changes must go through a Pull Request (PR).
- Branches should be deleted after merging.
- Check the Issues tab before starting any work — pick up an existing issue or open a new one.
- Assign yourself to the issue before starting.
- Create a branch following the naming convention above.
- Write clean, documented, and tested code.
- Open a Pull Request and request at least one reviewer.
- Address all review comments before merging.
- Follow the style guide relevant to the language (e.g., PEP 8 for Python, Google Style for C++).
- All functions and modules must include docstrings / header comments.
- Avoid commented-out code in commits.
- Keep functions small and single-purpose.
- Write unit tests for all new logic where applicable.
Use the following format for all commit messages:
<type>(<scope>): <short description>
[optional body]
[optional footer]
Types:
| Type | Use When |
|---|---|
feat |
Adding a new feature |
fix |
Fixing a bug |
docs |
Documentation changes only |
refactor |
Code restructuring (no feature or bug change) |
test |
Adding or updating tests |
chore |
Build process, tooling, or config changes |
Example:
feat(arm-controller): add inverse kinematics solver
Implemented a Jacobian-based IK solver for the 6-DOF arm.
Closes #42
- Ensure your branch is up to date with
developbefore opening a PR. - Fill in the PR template completely.
- Link the relevant issue(s) using
Closes #<issue-number>. - All CI checks must pass before a PR can be merged.
- At least one approval is required from a reviewer.
- The author should not merge their own PR unless explicitly authorized.
| Channel | Purpose |
|---|---|
| GitHub Issues | Bug reports, feature requests, task tracking |
| [Slack / Teams / Discord] | Day-to-day team communication |
| [Email / Notion / Confluence] | Documentation and announcements |
This README is a living document. Members are encouraged to suggest improvements via a Pull Request.