v# Contributing to Stroppy
Thank you for your interest in contributing to Stroppy! We welcome all contributions, including bug reports, feature requests, documentation improvements, and code contributions.
- Code of Conduct
- How to Contribute
- Development Setup
- Coding Standards
- Commit Message Guidelines
- License
This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code.
Before creating a bug report, please check the existing issues to see if the problem has already been reported.
When creating a bug report, please include:
- A clear and descriptive title
- Steps to reproduce the issue
- Expected vs actual behavior
- Environment details (OS, Go version, etc.)
- Any relevant logs or error messages
We welcome suggestions for new features and improvements. Before submitting a new feature request:
- Check if a similar feature request already exists
- Explain why this enhancement would be useful
- Describe your proposed solution or approach
- Include any relevant examples or documentation
- Fork the repository on GitHub
- Clone your fork locally
- Create a new branch for your changes
- Make your changes following the coding standards
- Run tests and ensure they pass
- Commit your changes following the commit message guidelines
- Push your changes to your fork
- Open a pull request
- Keep pull requests focused on a single feature or bug fix
- Include tests for new functionality
- Update documentation as needed
- Ensure all tests pass
- Follow the project's coding standards
- Reference any related issues in your PR description
- Go 1.24.3 or later
- Protocol Buffers compiler (e.g. protoc, for generating schemes)
- Node.js and npm (for TypeScript SDK generation)
- Make (for building the project)
-
Clone the repository:
git clone https://github.com/picodata/stroppy.git cd stroppy -
Install dependencies:
make .bin_deps go mod tidy
-
Build the project:
make build
Run all tests:
make test- Follow the Effective Go guidelines
- Run
gofmt,make lint, andmake teston your code before committing - Keep functions small and focused on a single responsibility
- Write clear and concise comments for exported functions and types
- Follow the existing code style in the codebase
We follow the Conventional Commits specification. Format your commit messages as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types:
feat: A new featurefix: A bug fixdocs: Documentation only changesstyle: Changes that do not affect the meaning of the coderefactor: A code change that neither fixes a bug nor adds a featureperf: A code change that improves performancetest: Adding missing tests or correcting existing testschore: Changes to the build process or auxiliary tools
Example:
feat(api): add user authentication endpoint
Add new POST /auth endpoint for user authentication with JWT tokens.
Closes #123
By contributing to this project, you agree that your contributions will be licensed under its LICENSE file.