NoSQLBench is an ambitious project. It aims to solve long-standing problems in distributed systems testing. There are *many* ways you can contribute! Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved. ## Code of Conduct This project follows a [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md). Please read through it at least once if you are going to contribute to NoSQLBench. ## Licensing All source code in this repository is licensed exclusively under [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0). ## Jumping Right In Some quick how-to docs have been written for some of the subject-matter areas in NoSQLBench. If you need an onramp that is not listed, here let us know! [I am a developer and I want to contribute a driver.](devdocs/devguide/drivers/README.md) [I am a user and I want to improve the documentation.](devdocs/devguide/nb_docs.md) [I am a user and I want to contribute built-in scenarios.](devdocs/devguide/adding_scenarios.md) [I am a UI developer and I want to improve the NoSQLBench UI (NBUI)](devdocs/devguide/nbui/README.md) ## Contribution Ideas There are lots of ways to contribute to the project. Some ideas on how to get started are described here. ### Feedback - reporting issues - If you find an issue while using NoSQLBench, please let us know! - reproducing issues - For some non-trivial bugs, it helps to have someone reproduce the issue. This can be helpful to help us understand better what conditions cause the issue to occur. If want to help address a non-trivial issue that has been reported, you can follow the steps that the original user reported. Updating issues with such findings is immensely helpful to the maintainers. ### Pull Requests All contributions to this project are made in the form of pull requests, including: - Easy Picks - Any issue labeled `easy pick` is a good first issue for new contributors. These are tagged by the maintainers specifically to provide a gentle on-ramp for those joining our endeavor. - Fixing bugs - Bug fixes are awesome! If you submit a pull request with a bug fix, we will review it and provide feedback if refinements are needed. Otherwise we'll merge it in for the next release. - Testing Improvements - Often, a good test is the best form of documentation. Test coverage can always be improved. Writing tests is also a great way to get familiar with the project up close. - Writing documentation - Our users need good documentation. Good documentation is, however, a community effort. If you have used NoSQLBench and want to improve the journey for others, good documentation with examples is really helpful. - Writing web apps - The doc system that is bunded with NoSQLBench is a web application. This is just the first web app, but we expect there will be more. If you are interested in helping with this part, please reach out to the maintainers or file an issue describing your ideas. - Working on the core - The core machinery of nosqlbench needs maintenance just like any code base. If you want to help implement new core features, manage project dependencies, address technical debt, or help with internal architecture, there is work to be done. This is on the more advanced end of contribution, and requires some study of the codebase. If you take the time to understand the code a bit before submitting pull requests, then the maintainers will take the time to help you make your pull requests better. ### Maintainers We are looking for more community ownership in this project. That means that we will be supportive of new project contributors who wish to build a sense of trust with the maintainers. - Reviewing Pull Requests - If you are a maintainer on this project, then you may be called on to review pull requests. Unless requested directly, pull requests will be allocated to reviewers automatically. - Enforcing Conduct - You may be called up on as a maintainer of this project to enforce the code of conduct as it is written. - Developing Maintainers - It is important that there be a solid core of project maintainers who can depend on one another and whom the project user base can depend on do govern the project fairly and equitably. As a project maintainer, you will be expected to help guide contributors as they learn about the project. You may be responsible for choosing maintainers or voting on maintainer membership. - Documenting APIs - The developer docs are pretty lean right now. We need some examples of building activity types, adapting statement templates and so on. This level of contribution requires an intimate awareness of how the core engine works, but it is also some of the most valuable work that you can do in terms of expanding the nosqlbench ecosystem. Contributions are welcome here! ## Outreach Help us get the word out on NoSQLBench. It is a newly opened project in its current form, and we are eager to get it into the hands of users who need it. - Writing blog posts - A blog post that helps others see the good in NoSQLBench is a service to our community. This is even better when it comes from a new user who has seen the merit of the tooling. We appreciate any help. - Helping other users - Helping new users get to a productive state is a great way to build bridges in the community. The more community advocates we have helping each other the better! - Community Development - The NoSQLBench project endeavors to build a strong, inclusive, and robust support system around users and contributors alike. This takes on many forms. It is essential that we keep looking for ways to connect the NoSQLBench community, doing more of what works and less of what doesn't. If you want to help with community development, please join our [discord server](https://discord.gg/dBHRakusMN) and raise your hand!