Nimble ❤️ open source and does its part in sharing its work with the community! The engineering team maintains and contributes to many open source projects. As these projects are open for external contributions, here are some guidelines and conventions to make this collaboration more effective.
As an external contributor
Before making a contribution, ensure it is aligned with the direction of the project. For that, create a GitHub issue (Feature/Bug/Chore) to describe the reason(s) why this contribution is needed, and what will be changed or added. The team in charge of the repository will provide feedback as soon as they are available. This enables any blockers or concerns to be identified before spending time on the implementation. The feedback time might take longer than the contributor’s expectation, or the team may not support those proposed changes. In such cases, the contributor is encouraged to implement the changes in their forked repository to help the community grow around the project.
External contributors can also read the code conventions for the related tech stack. This would highly reduce the time needed to review the Pull Requests and the work needed for the implementation.
Once approved, fork the project, start the implementation and submit a pull request against the
develop branch of the original repository.
Follow the Branches and Commits conventions to increase the speed to process the Pull Request.
Consider opening a draft pull request soon so the repository owners can provide guidance.
If an issue is considered to not fit in the project goal, the team in charge of the repository will either close the issue or request changes. No activity/response on an issue can lead to its closure too.
As public repository owner/reviewer
As a code owner (i.e. team member), ensure to answer issues as early as possible. The role of answering is not limited to the Team Lead of a project. When needed, refer to this page while supporting the contribution — e.g. fix the issue formatting and explain why it has been fixed. If an issue needs to be discussed with the project team, kindly inform them about it and the concerns that need to be discussed. For example, if an external contributor created an issue about an unexpected feature, a response could be:
Thanks for submitting this issue! Give us some time to review it and ensure there won't be any concern about it. We will raise any concerns within the week. Meanwhile, feel free to read about our [contribution guidelines](https://nimblehq.co/compass/development/community).
Internally, consider using GitHub Discussions for opening polls and Slack to notify and involve as many team members as possible.
Here are some things to consider:
- Why is the feature desirable/useful to Nimble?
- Why is the feature NOT desirable to Nimble?
- What are the risks of implementing it?
- Can this feature open the accessibility of the project to more users and contributors in the future?
- Are we available to provide quick feedback and code reviews?
Answer according to the context. Be transparent if the issue is unwanted OR the team is busy and review time might be affected.
Last but not least, do not forget to run all the tests on GitHub.
Add the “CONTRIBUTING.md” file
CONTRIBUTING.md file to guide external contributors toward this page.
Find all our contributing guidelines in the [Community section of our Handbook](https://nimblehq.co/compass/development/community).
This file can be customized with the specificities of each project.
Add the “License” and “About” parts in the
To be consistent across the public repositories and to promote the Nimble brand in the open source community, refer to the Git template to add these two sections at the end of the
README.md file of Nimble public repositories.