Thank you for your interest in contributing to our repository! Whether it's a bug report, new feature, or question, we greatly value feedback and contributions from our community. Read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.
In addition to this document, review our Code of Conduct. For any code of conduct questions or comments, send an email to [email protected].
-
When in doubt, open an issue - For almost any type of contribution, the first step is opening an issue. Even if you think you already know what the solution is, writing down a description of the problem you're trying to solve will help everyone get context when they review your pull request. If it's truly a trivial change (e.g. spelling error), you can skip this step -- but as the subject says, when it doubt, open an issue.
-
Only submit your own work (or work you have sufficient rights to submit) - Please make sure that any code or documentation you submit is your work or you have the rights to submit.
Before contributing, you must sign the Splunk Contributor License Agreement (CLA).
Bugs! Ugh! When there's a mismatch between intended behavior, and the actual results, that's a bug. To help us understand what's happening, we want to make sure you're working on the latest version.
Once you've confirmed that the bug still exists in the latest version, check to make sure its not something we already know about on the Github Issues tab. When you open a bug, please fill out the issue template for a bug report, supplying as much relevant information as you can.
If you've thought of a way that contentctl can be better, we want to hear about it! There's a specific issue type for these requests here that helps us keep track. Please describe the feature you'd want to see, and if possible, a potential implementation idea. If you're not familiar enough with the codebase to describe the implementation, that's fine too
Sometimes, the documentation doesn't match reality. Sometimes, examples might be out of date, or spelling or grammar might make something difficult to read or understand. We welcome updates to our documentation for any of the above reasons, and for any others too!
As with other types of contributions, please open an issue first. This helps to make sure we don't have duplicate people working on the same problem, ensures that the change is solved once, and that we can help you find the right approach before spending a ton of time on a PR. As above, when in doubt, please open an issue.
We're very appreciative of everyone that wants to make a contribution. We will attempt to review them in a timely manner. As a reminder, opening an issue before you spend time on a PR can help make this process smoother. It can also help prevent rejection because someone else was working on it already, or because its incompatible with other in-flight work or long term goals.