Excited about Gloo and want to help make it better?
At Solo we strive to make the world of microservices, serverless and service mesh available to everyone. If you want to help but don’t know where to start, let us know, and we’ll find something for you.
If you haven’t already, make sure you sign up for the Solo Slack.
Here are some of the ways you can contribute:
If you encounter a bug, please file an issue on GitHub. If an issue you have is already reported, please add additional information or add a 👍 reaction to indicate your agreement.
Improving the documentation
Improving the documentation, adding examples or use cases can be the easiest way to contribute to Gloo. If you see a piece of content that can be better, open a PR with an improvement, it doesn’t matter how small!
Small bug fixes
If your bug fix is small (around 20 lines of code) just open a pull request. We will try to merge it as soon as possible, just make sure that you include a test that verifies the bug you are fixing.
- Big bug fixes
- New features
For significant changes to the repository, it’s important to settle on a design before starting on the implementation. Reaching out to us early will help minimize the amount of possible wasted effort and will ensure that major improvements are given enough attention.
- Open an issue. Open an issue about your bug in this repo.
- Message us on Slack. Reach out to us to discuss your proposed changes.
- Agree on implementation plan. Write a plan for how this feature or bug fix should be implemented. Should this be one pull request or multiple incremental improvements? Who is going to do each part?
- Submit a work-in-progress PR It’s important to get feedback as early as possible to ensure that any big improvements end up being merged. Submit a pull request and label it
wipto start getting feedback.
- Review. At least one Solo team member should sign off on the change before it’s merged. Look at the “code review” section below to learn about what we’re looking for.
- A Solo team member will merge and release!
Code review guidelines
It’s important that every piece of code in Gloo is reviewed by at least one Solo team member familiar with that codebase.
- Changelog Every PR in Gloo needs a changelog entry. For more information about changelogs, see the readme.
- CI check A Solo team member needs to kick off the CI process by commenting
/teston your PR.
- Testing Please write tests for your changes. Bias towards fast / unit testing.
- Comments The code reviewer may leave comments to discuss changes. Minor preferences are often called out with
Testing with coverage:
To see coverage, run your tests in the package like so
ginkgo -cover && go tool cover -html *.coverprofile