2020-03-16 08:41:22 -05:00
|
|
|
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
|
|
|
|
|
2020-05-01 23:48:09 -05:00
|
|
|
This project follows a [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md).
|
2020-03-16 08:41:22 -05:00
|
|
|
Please read through it at least once if you are going to contribute to our endeavor.
|
|
|
|
|
|
|
|
## Licensing
|
|
|
|
|
|
|
|
All source code in this repository is licensed exclusively under
|
|
|
|
[Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0).
|
|
|
|
|
|
|
|
## Ways to Contribute
|
|
|
|
|
|
|
|
### 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!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|