From a26c1e82bfcda4833d5395415a89d1a82c96fa4d Mon Sep 17 00:00:00 2001 From: Attila Kovacs Date: Tue, 3 Sep 2024 11:02:56 +0200 Subject: [PATCH] Add CONTRIBUTING.md --- CONTRIBUTING.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..492330a --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,43 @@ +# Contributing to RedisX + + +The _RedisX_ library is for everyone. And, it is developers like you who can make it better. Whether there is a +nagging issue you would like to fix, or a new feature you'd like to see, you can make a difference yourself. Make this +project a little bit your own, by submitting pull requests with fixes and enhancement. When you are ready, here are +the typical steps for contributing to the project: + +1. Old or new __Issue__? Whether you just found a bug, or you are missing a much needed feature, start by checking +open (and closed) [Issues](https://github.com/Smithsonian/redisx/issues). If an existing issue seems like a +good match to yours, feel free to speak up, comment, or to offer help in resolving it. If you find no issues that +match, go ahead and create a new one. + +2. __Fork__. Is it something you'd like to help resolve? Great! You should start by creating your own fork of the +repository so you can work freely on your solution. I recommend that you place your work on a branch of your fork, +which is named either after the issue number, e.g. `issue-192`, or some other descriptive name, such as +`sentinel-support`. + +3. __Develop__. Experiment on your fork/branch freely. If you run into a dead-end, you can always abandon it (which is +why branches are great) and start anew. You can run `make all` to ensure that all components of the package and its +API documentation are also in order. Remember to synchronize your `main` branch by fetching changes from upstream +every once in a while, and merging them into your development branch. Don't forget to: + + - Add __doxygen__ markup your new code. You can keep it sweet and simple, but make sure it properly explains your + globally exposed functions, their arguments and return values. You should also cross-reference other functions / + constants that are similar, related, or relevant to what you just added. + +4. __Pull Request__. Once you feel your work can be integrated, create a pull request from your fork/branch. You can +do that easily from the github page of your fork/branch directly. In the pull request, provide a concise description +of what you added or changed. Your pull request will be reviewed. You may get some feedback at this point, and maybe +there will be discussions about possible improvements or regressions etc. It's a good thing too, and your changes will +likely end up with added polish as a result. You can be all the more proud of it in the end! + +5. If all goes well, your pull-request will get merged, and will be included in the upcoming release of _RedisX_. +Congratulations for your excellent work, and many thanks for dedicating some of your time for making this library a +little bit better. There will be many who will appreciate it. :-) + + +If at any point you have questions, or need feedback, don't be afraid to ask. You can put your questions into the +issue you found or created, or your pull-request, or as a Q&A in +[Discussions](https://github.com/Smithsonian/redisx/discussions). + +