nimblehq.co

Community 🏗

Hero image for Community 🏗

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 a 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?
  • Is the team available to provide quick feedback and code reviews?

The answer will vary depending on 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.

By default, the checks will NOT run for a pull request from a forked branch. It is a security feature. First, review the code and ensure the GitHub Actions workflows are not modified. Then manually run the checks (only repository admins can perform this)

Add the “CONTRIBUTING.md” file

Add a 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 README.md file

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.