First off, thank you for considering contributing to Opa Gradle Plugin. It's people like you that make this code such a great plugin.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Opa Gradle Plugin is an open source project, and we love to receive contributions from our community — you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into Opa Gradle Plugin itself.
Responsibilities
- Ensure cross-platform compatibility for every change that's accepted. Windows, Mac, Debian & Ubuntu Linux.
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Code of Conduct.
As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
- Spelling / grammar fixes
- Typo correction, white space and formatting changes
- Comment clean up
- Bug fixes that change default return values or error codes stored in constants
- Adding logging messages or debugging output
- Changes to ‘metadata’ files like .gitignore, build scripts, etc.
- Moving source files from one directory or package to another
For something that is bigger than a few line fix:
- Create your own fork of the code
- Do the changes in your fork
- If you like the change and think the project could use it
- Be sure you have followed the code style for the project.
- Note the Code of Conduct.
- Send a pull request.
If you find a security vulnerability, do NOT open an issue. Email maintainers instead.
Any security issues should be submitted directly to maintainers In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us.
When filing an issue, make sure to answer these five questions:
- What version of OPA/Java/Gradle are you using?
- What operating system and processor architecture are you using?
- What did you do?
- What did you expect to see?
- What did you see instead?
If you find yourself wishing for a feature that doesn't exist in Opa Gradle Plugin, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that Opa Gradle Plugin has today have been added because our users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work.
The core team looks at Pull Requests as fast as possible. If there is a need, we can arrange a meeting and elaborate on implementation details. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.
Please do not provide nondeterministic messages to commits like: "fix vol2", "another fix". From maintainers point of view, there should be one commit for one Pull Request. Perhaps the best idea is to squash commits before merge.