Want to contribute to Naomi ? Great ! 🎉 We're always happy to have more contributors. Before you start developing, though, we ask that you read through this document in-full. It's full of tips and guidelines--if you skip it, you'll likely miss something important (and your pull request will probably be rejected as a result).
Throughout the process of contributing, there's one thing we'd like you to remember: Naomi is developed (and is maintained) by what might be described as "volunteers". They earn no money for their work here and give their time solely for the advancement of the software and the enjoyment of its users. While they will do their best to get back to you regarding issues and pull requests, your patience is appreciated.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
From Improving documentation, bug triaging, writing tutorials to developing along side the maintainers by submitting bug reports, feature requests, writing code which can be incorporated into Naomi all to help further Naomi.
As of time of writing, we are open to any ideas or contributions anyone may have. Once the idea or contribution is fleshed out, has no standing issues or pull requests that conflict, and add to the scope of Naomi, it will most likely be approved and we look forward to your contribution.
- Ensure code compatibility for every change. We do not want to break everything just for one feature. If in testing your contribution causes issues but in its self works as intended, try to fix the issues that have arised. At the end of the day, we are all working towards a better Naomi.
- Ensure that code that goes into Naomi meets all requirements.
- Create issues for any changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
Due to the nature of the project and at the time of writing, you can look through issues and if there is something that you can aid in, jump right it. Some things might be simple bug fixes that may take only a few lines of code while others may take editing multiple documents and structure already assembled. Those required someone that understands Naomi front to back and has worked on the project for some time. In other words, do not bite off more than you can chew, every little step helps.
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
However, if a maintainer asks you to "rebase" your pull request, they're saying that a lot of code has changed since you started working, and that you need to update your branch so it's easier to merge.
-
Check open issues that are labeled as available to work on. If it is an idea that has no current issue or pull request related to it, create an issue so that the idea can be fleshed out and approved before starting. Do not want you to reinvent the wheel.
-
Create your own fork of the code
-
Do the changes in your fork
-
If you like the change and think the project could use it:
- Be sure you have followed the style of code throughout the project. Make it clean and readable!
- Test the code on a RaspberryPi
- Send a pull request and fillout the template. (All issues and PR have to follow the template or they will not be accepted)
- Once the PR has been submitted a bot will ask you to sign a Contribution License Agreement, CLA. (All contributers to the PR has to accept the CLA in order for the PR to be accepted)
- The maintainer will review your submission and either ask for clarifications or changes, or approve the PR and it will be merged.
Our issues and pull request follow a labeling convention to aid with flow & organization. Please review them so you know what each label means and how they are used.
If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.
Any security issues should be submitted directly to [email protected] In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [email protected] and the lead maintainers will address the issue immediately.
If you have found a bug, please create an issue using the bug report template and fill out as much information as you can.
Note: Again, any issues &/or pull requests that do not follow the template will be asked to resubmit using the template and closed!
If you have an idea that you think will improve upon Naomi, create an issue using the proper template and fill it out to the best of your ability. Once submitted the community will discuss with you about the idea to help flesh it out and give it a base to be built upon. This will allow us to determine whether or not the idea should be implemented, put on hold due to other issues or pull requests that are currently open at that time, or abandoned if it does not fit into the scope of Naomi. Once approved, the idea can either be worked on by either the submittor if they so choose or made available for other developers and maintainers to turn the idea into reality.
If you find yourself wishing for a feature that doesn't exist in Naomi, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that Naomi has today have been added because users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work.
Someone on the core team is active at most times, expect some sort of response within 24 hours, but please be patient. If a maintainer does not have the knowledge needed for said issue or pull request they will direct attention to another that does. This shows the submitter that the issue or PR is being looked at.
Do note: After feedback has been given and required a response from the submitter, we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.
If everything up to this point has been done correctly but your PR has not been approved or merged, here are some things to look out for.
- Double check that everything was done correctly.
- Refernce the status label for the PR, this can give you information that might tell you whats wrong.
- Make sure you have signed the CLA and your code has been reviewed by at least one maintainer.
By all means if none of this applies and everything is in order, please reach out to one of the core team and we will be happy to look into what the issue is.
Naomi is always looking to grow its community whether you are a developer or someone whom has interest in the project. You can join our forum to talk with others as well as spread the work about Naomi. Every small step leads Naomi in the right direction.