Permalink
Browse files

Updating README and CONTRIBUTING

  • Loading branch information...
1 parent 468eeb2 commit 7156bd3b558a3b2d0a2590bc6c365db7a68ae5e4 @mikel committed Jan 14, 2012
Showing with 54 additions and 16 deletions.
  1. +45 −0 CONTRIBUTING.md
  2. +9 −16 README.mkd → README.md
View
@@ -0,0 +1,45 @@
+Contributing to Mail
+====================
+
+Hi there, I welcome pull requests! Here are some thoughts on how to get your
+pull request merged quickly:
+
+1. Check the Reference RFCs, they are in the References directory, so no excuses.
+2. Check for a ticket on GitHub, maybe someone else has the problem too
+3. Make a fork of my GitHub repository
+4. Run the specs. We only take pull requests with passing tests, and it's great
+ to know that you have a clean slate: `bundle && bundle exec rake`
+5. Add a spec for your change. Only refactoring and documentation changes
+ require no new specs. If you are adding functionality or fixing a bug, we need
+ a spec!
+6. Test the spec _at_ _least_ against MRI-1.9.2 and MRI-1.8.7
+7. Update the README if needed to reflect your change / addition
+8. With all specs passing push your changes back to your fork
+9. Send me a pull request
+
+Note, specs that break MRI 1.8.7 will not be accepted.
+
+At this point you're waiting on us. We like to at least comment on, if not
+accept, pull requests within three business days (and, typically, one business
+day). We may suggest some changes or improvements or alternatives.
+
+Some things that will increase the chance that your pull request is accepted,
+taken straight from the Ruby on Rails guide:
+
+* Tell me you have tested it against more than one version of Ruby, RVM is great for
+ this. I test against 7 rubies before I push into master.
+* Use good, idiomatic, strcutred and modular code
+* Include tests that fail without your code, and pass with it
+* Update the documentation, the surrounding one, examples elsewhere, guides,
+ whatever is affected by your contribution
+
+Syntax:
+
+* Two spaces, no tabs.
+* No trailing whitespace. Blank lines should not have any space.
+* Prefer &&/|| over and/or.
+* MyClass.my_method(my_arg) not my_method( my_arg ) or my_method my_arg.
+* a = b and not a=b.
+* Follow the conventions you see used in the source already.
+
+And in case we didn't emphasize it enough: we love specs!
@@ -30,11 +30,13 @@ Compatibility
Mail is tested and works on the following platforms:
-* jruby-1.5.2 [ x86\_64-java ]
-* ree-1.8.7-2010.02 [ x86\_64 ]
-* ruby-1.8.6-p399 [ x86\_64 ]
-* ruby-1.8.7-p302 [ x86\_64 ]
-* ruby-1.9.2-p0 [ x86\_64 ]
+* jruby-1.6.5.1 [ x86_64 ]
+* rbx-head-d18 [ x86_64 ]
+* rbx-head-d19 [ x86_64 ]
+* ree-1.8.7-2011.03 [ i686 ]
+* ruby-1.8.7-p357 [ i686 ]
+* ruby-1.9.2-p290 [ x86_64 ]
+* ruby-1.9.3-p0 [ x86_64 ]
Discussion
----------
@@ -137,16 +139,7 @@ I have tried to simplify it some:
Contributing
------------
-Please do! Contributing is easy in Mail:
-
-1. Check the Reference RFCs, they are in the References directory, so no excuses.
-2. Open a ticket on GitHub, maybe someone else has the problem too
-3. Make a fork of my GitHub repository
-4. Make a spec driven change to the code base
-5. Make sure it works and all specs pass, on Ruby versions 1.8.6, 1.8.7 and 1.9
-6. Update the README if needed to reflect your change / addition
-7. With all specs passing push your changes back to your fork
-8. Send me a pull request
+Please do! Contributing is easy in Mail. Please read the CONTRIBUTING.md document for more info
Usage
-----
@@ -635,7 +628,7 @@ License
(The MIT License)
-Copyright (c) 2009, 2010, 2011
+Copyright (c) 2009, 2010, 2011, 2012
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the

0 comments on commit 7156bd3

Please sign in to comment.