This document is the single source of truth on contributing towards this codebase. Please feel free to browse the open issues and file new ones - all feedback is welcome!
When contributing to this repository, please first discuss the change you wish to make via a GitHub issue, Slack message, email, or via other channels with the owners of this repository.
At the moment, we can only accept pull requests submitted from either:
- Splunk employees or
- Individuals that have signed our contribution agreement
If you wish to be a contributing member of our community, please see the agreement for individuals or for organizations.
Please make sure to read and observe our Code of Conduct. Please follow it in all of your interactions involving the project.
TODO
Help is always welcome! For example, documentation can always use improvement. There's always code that can be clarified, functionality that can be extended, and tests to be added to guarantee behavior. If you see something you think should be fixed, don't be afraid to own it.
Have ideas on improvements? See something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue. Please report any issues or bugs you find through GitHub's issue tracker.
If you are reporting a bug, please include:
- Your operating system name and version
- Any details about your local setup that might be helpful in troubleshooting (ex. Python interpreter version, Ansible version, etc.)
- Detailed steps to reproduce the bug
We'd also like to hear about your propositions and suggestions. Feel free to submit them as issues and:
- Explain in detail how they should work
- Keep the scope as narrow as possible -t his will make it easier to implement
Look through our issue tracker to find problems to fix! Feel free to comment and tag corresponding stakeholders or full-time maintainers of this project with any questions or concerns.
What is a "pull request"? It informs the project's core developers about the changes you want to review and merge. Once you submit a pull request, it enters a stage of code review where you and others can discuss its potential modifications and even add more commits to it later on.
If you want to learn more, please consult this tutorial on how pull requests work in the GitHub Help Center.
Here's an overview of how you can make a pull request against this project:
- Fork the splunk-ansible GitHub repository
- Clone your fork using git and create a branch off develop
$ git clone [email protected]:YOUR_GITHUB_USERNAME/splunk-ansible.git $ cd splunk-ansible # This project uses 'develop' for all development activity, so create your branch off that $ git checkout -b your-bugfix-branch-name develop - Run all the tests to verify your environment
$ cd splunk-ansible $ make test - Make your changes, commit and push once your tests have passed
$ git commit -m "<insert helpful commit message>" $ git push - Submit a pull request through the GitHub website using the changes from your forked codebase
There are two aspects of code review: giving and receiving.
To make it easier for your PR to receive reviews, consider the reviewers will need you to:
- Follow the project coding conventions
- Write good commit messages
- Break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
Reviewers, the people giving the review, are highly encouraged to revisit the Code of Conduct and must go above and beyond to promote a collaborative, respectful community.
When reviewing PRs from others The Gentle Art of Patch Review suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
- Is the idea behind the contribution sound?
- Is the contribution architected correctly?
- Is the contribution polished?
For this project, we require that at least 2 approvals are given and a build from our continuous integration system is successful off of your branch. Please note that any new changes made with your existing pull request during review will automatically unapprove and retrigger another build/round of tests.
Testing is the responsibility of all contributors. In general, we try to adhere to Google's test sizing philosophy when structuring tests.
There are multiple types of tests. The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test.
-
Small: Very fine-grained; exercises low-level logic at the scope of a function or a class; no external resources (except possibly a small data file or two, but preferably no file system dependencies whatsoever); very fast execution on the order of seconds
$ make small-tests -
Medium: Exercises interaction between discrete components; may have file system dependencies or run multiple processes; runs on the order of minutes
$ make medium-tests -
Large: Exercises the entire system, end-to-end; used to identify crucial performance and basic functionality that will be run for every code check-in and commit; may launch or interact with services in a datacenter, preferably with a staging environment to avoid affecting production
$ make large-tests
Continuous integration will run all of these tests either as pre-submits on PRs, post-submits against master/release branches, or both.
We could always use improvements to our documentation! Anyone can contribute to these docs - whether you’re new to the project, you’ve been around a long time, and whether you self-identify as a developer, an end user, or someone who just can’t stand seeing typos. What exactly is needed?
- More complementary documentation. Have you perhaps found something unclear?
- More examples or generic templates that others can use.
- Blog posts, articles and such – they’re all very appreciated.
You can also edit documentation files directly in the GitHub web interface, without creating a local copy. This can be convenient for small typos or grammer fixes.
If you need help, feel free to tag one of the active maintainers of this project in a post or comment. We'll do our best to reach out to you as quickly as we can.
# Active maintainers marked with (*)
(*) Nelson Wang
(*) Tony Lee
(*) Brent Boe
(*) Matthew Rich
(*) Jonathan Vega
(*) Jack Meixensperger
(*) Brian Bingham
(*) Scott Centoni
(*) Mike Dickey