Thank you for your interest in contributing to Wren Security. We appreciate all help with finding and fixing bugs, making performance improvements, and other tasks. Every contribution is helpful and we thank you for your effort. To ensure the process of contributing is as smooth as possible, here are a few guidelines for you to follow.

All contributions to Wren Security should be made via GitHub pull requests, which require that the contributions be offered from a fork of the appropriate Wren Security project repository.

For help with forking a repository, refer to GitHubFork a Repo.

Before you start to make changes, make sure that you have a functional build of the project to start from. This can help prevent future misunderstandings that result from starting off of unstable code.

To make sure that the build you have is functional, run the tests included in the project prior to starting work on your new feature. Instructions on how to run the tests should be part of the project's README file.

1. Check out the Latest Changes from themaster Branch

$ git checkout master# Assuming that `wren` is your remote name for Wren's copy of the project$ git pull wren master

2. Create a Feature Branch

$ git checkout -b feature/my-awesome-improvement

3. Make and Commit Changes
   Edit the source and commit the changes you make in logical chunks (seeCommit Guidelines below). All changes – including new features and bug fixes – must include tests that demonstrate that the changes work as expected, unless there is no practical way to test the issue being corrected.
4. Push to Your Fork
   In order to submit a pull request, you must push your local branch to your fork of the repository on GitHub.

$ git push origin feature/my-awesome-improvement

5. Submit a Pull Request
   Submit a pull request from your feature branch onto the target branch of the Wren Security project (See GitHubUsing Pull Requests).
6. Respond to Pull Request Feedback on the Same Branch
   If and when maintainers ask for you to make changes to your work, you should be sure to make the requested changes on thesame feature branch that contains your original changes. Then, unless the maintainers have specifically asked you to do otherwise, push tothe same branch on your remote from which your pull request originates, and donot create a new pull request for the new changes. Your existing pull request should automatically reflected the new changes you pushed.

We encourage many smaller commits over one large commit. Small, focused commits make the review process easier and are more likely to be accepted. It is also important to summarize the changes made with brief commit messages. If a commit fixes a specific issue, it is also good to note that in the commit message.

The commit message should start with a single line that briefly describes the changes. That should be followed by a blank line and then a more detailed explanation. As a good practice, use commands when writing the message (instead of "I added ..." or "Adding ...", use "Add ...").

Before committing. check for unnecessary whitespace withgit diff --check.

Additionally, we ask that you please review the following guides before making your first commit, to encourage maintainability:

• How to Write a Git Commit Message
• Git Commit Best Practices
• A Note About Git Commit Messages
• Git Commit Guidelines

The following guidelines can increase the likelihood that your pull request will get accepted:

• Work on a separate branch for each distinct feature or bug-fix.
• Follow all applicablestyle guides when writing your code.
• Follow theCommit Guidelines when committing your code.
• Keep patches on topic, focused, and atomic.
• Try to avoid unnecessary formatting and clean-up, where reasonable. (For Java code, seesection 8.3 of the Wren Java Style Guide; for JavaScript code, seesection 8.3 of the Wren JavaScript Style Guide).
• Write tests that cover all the code your change affects.

A pull request should contain the following:

• At least one commit (all of which should follow theCommit Guidelines).
• Title that summarizes the issue.
• Description that briefly summarizes the changes.

After submitting a pull request, you should get a response within the next 7 days. If you do not, please do not hesitate to ping us in the Pull Request thread,on Gitter, or inthe Wren Security Google Group.

This set of guidelines was inspired by theContributor Guidelines for CAS by Apereo.