## Filing a Feature Request
When filing a feature request, please start your issue title with "Feature request:",
-this allows for quick distinguisihing between issues and these requests.
+this allows for quick distinguishing between issues and these requests.
Please be as elaborate as possible when describing the feature you need. Provide
at least the following information (if they are relevant):
information:
* PowerDNS version
-* Where you got the software from (e.g. distribution, compiled youself)
+* Where you got the software from (e.g. distribution, compiled yourself)
* Operating System and version
* Steps to reproduce: How can we reproduce the issue
* Expected behavior: what did you expect what would happen?
-* Observed behavior: what actually happend when following the steps?
+* Observed behavior: what actually happened when following the steps?
* Relevant logs: Please use code blocks (\`\`\`) to format console output, logs, and code as it's very hard to read otherwise.
If you have already looked deeper into the problem, provide what you found as
# Filing a Pull Request
Code contributions are sent as a pull request on [GitHub](https://github.com/PowerDNS/pdns/pulls).
+By submitting a Pull Request you agree to your code become GPLv2 licensed.
## Pull Request Guidelines
A pull request, at the least, should have:
-* A clear and consise title (not e.g. 'Issue #1234')
+* A clear and concise title (not e.g. 'Issue #1234')
* A description of the patch (what issue does it solve or what feature does it add)
* Documentation for the feature or when current behaviour changes
* Regression and/or unit tests
## Commit Guidelines
* Tell why the change does what it does, not how it does it.
-* The first line should be short (preferebly less than 50 characters)
+* The first line should be short (preferably less than 50 characters)
* The rest of the commit body should be wrapped at 72 characters (see [this](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) for more info)
* If this commit fixes an issue, put "Closes #XXXX" in the message
* Do not put whitespace fixes/cleanup and functionality changes in the same commit
# Coding Guidelines
At the moment there is no established coding guideline, but here are some
-general guidleines:
+general guidelines:
* Don't have end-of-line whitespace
* Use spaces instead of tabs
* Stick to the style of the file you're editing
-
+* Functions and classes must have a [docblock](http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html)
projects / thirdparty / pdns.git / blobdiff