Add three more dos/donts to CONTRIBUTING.md

I've seen a couple PRs targeting the wrong branch. Many projects have a
workflow where PRs should hit `develop` or `release` or something, but
Metasploit-Framework wants PRs targeted against `master`.

Also, warn against fixing too much in one PR since those kinds of PRs
are a) harder to validate and b) might be all wrong anyway. We don't
want people committing a bunch of work when the fundamental approach
isn't going to fly.
This commit is contained in:
Tod Beardsley 2014-04-05 16:07:10 -05:00
parent 6d72860d58
commit 22ff5e2b0b
1 changed files with 3 additions and 1 deletions

View File

@ -23,6 +23,7 @@ and Metasploit's [Common Coding Mistakes](https://github.com/rapid7/metasploit-f
### Pull Requests
* *Do* target your pull request to the **master branch**. Not staging, not develop, not release.
* **Do** specify a descriptive title to make searching for your pull request easier.
* **Do** include [console output](https://help.github.com/articles/github-flavored-markdown#fenced-code-blocks), especially for witnessable effects in `msfconsole`.
* **Do** list [verification steps](https://help.github.com/articles/writing-on-github#task-lists) so your code is testable.
@ -34,7 +35,7 @@ Pull requests [#2940](https://github.com/rapid7/metasploit-framework/pull/2940)
#### New Modules
* **Do** run `tools/msftidy.rb` against your module and fix any errors or warnings that come up. Even better would be to set up `msftidy.rb` as a [pre-commit hook](https://github.com/rapid7/metasploit-framework/blob/master/tools/dev/pre-commit-hook.rb).
* **Do** use the [API](https://dev.metasploit.com/documents/api/). Wheel improvements are welcome; wheel reinventions, not so much.
* **Do** use the [many module mixin APIs](https://dev.metasploit.com/documents/api/). Wheel improvements are welcome; wheel reinventions, not so much.
* **Don't** include more than one module per pull request.
#### Library Code
@ -42,6 +43,7 @@ Pull requests [#2940](https://github.com/rapid7/metasploit-framework/pull/2940)
* **Do** write [RSpec](http://rspec.info/) tests - even the smallest change in library land can thoroughly screw things up.
* **Do** follow [Better Specs](http://betterspecs.org/) - it's like the style guide for specs.
* **Do** write [YARD](http://yardoc.org/) documentation - this makes it easier for people to use your code.
* *Don't* fix a lot of things in one pull request. Small fixes are easier to validate.
#### Bug Fixes