If you are willing to contribute, Thank you for making this project better and being a valuable member of our community. Here are a few guidelines to help you along the way.
Truelines have adopted the Contributor Convenant as its Code of Conduct, and we expect project participants to stick to it. Please read the code-of-conduct so that you can understand what actions will and will not be tolerated.
There are many ways to contribute to Truelines, code contribution is one aspect of it. For instance, improving documentation is also important as code contribution.
- Spread the word 🫶: Follow us on Twitter, talk about our projects to other developers and people.
- Give us feedback: In order to build tools that improve developer's experience, we need feedback from you to improve it. Please upvote the issues that you are most interested in getting resolved and join in our community Discussions.
- Help new users: You can answer questions on Stackoverflow.
- Make changes:
- Improve the documentation.
- Report bugs or missing features by creating an issue.
- Review and comment on existing pull requests and issues.
- Help translate the documentation.
- Fix bugs or add features by submitting a pull request.
- Support us financially through OpenCollective: If you use our tools or products in a commercial project and would like to support our continued development by becoming a Sponsor, or in a side or hobby project and would like to be a Backer, you can do so through OpenCollective. All funds donated are managed transparently, and Sponsors receive recognition in the README and on the MUI home page.
Working on your Pull Request? You can learn from this video series from Kent C Dodds.
How to Contribute to an Open Source Project on GitHub.
To help you get your first contribution and get familiar with our contribution process, check issues tagged as "good first issues". This label means that there is already a working solution to the issue in the discussion section. Therefore, it is a great place to get started.
You can also work on any other issue you choose to. The "good first" and "good to take" issues are just issues where we have a clear picture about scope and timeline. Pull requests working on other issues or completely new problems may take a bit longer to review when they don't fit into our current development cycle.
If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you have started to work on it so other people don't accidentally duplicate your effort.
If somebody claims an issue but doesn't follow up for more than a week, it's fine to take it over but you should still leave a comment. If there has been no activity on the issue for 7 to 14 days, it is safe to assume that nobody is working on it.
Please read the commit style guide 📕 to learn how we write commit titles.
The is a community project, so Pull Requests are always welcome, but, before working on a large change, it is best to open an issue first to discuss it with the maintainers.
When in doubt, keep your Pull Requests small. To give a Pull Request the best chance of getting accepted, don't bundle more than one feature or bug fix per Pull Request. It's often best to create two smaller Pull Requests than one big one.
The core team will be monitoring for Pull Requests. We will review your Pull Request and either merge it, request changes to it, or close it with an explanaion.
By contributing code to our open repositories, you agree to license your contribution under the MIT License