Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add clear guidance for contributors

* Add CONTRIBUTING.md file
* Make `rails server` explicit in Procfile
* Move contributing details to CONTRIBUTING.md file
* Remove detailed steps from README.md
  • Loading branch information...
commit 5ed7dd404eeacf372b5db7777a4d599a3b49a9ea 1 parent 06a82a4
Adarsh Pandit authored
Showing with 121 additions and 92 deletions.
  1. +117 −0 CONTRIBUTING.md
  2. +1 −1  Procfile
  3. +3 −91 README.md
View
117 CONTRIBUTING.md
@@ -0,0 +1,117 @@
+Contributing
+============
+
+
+Quick Overview
+--------------
+
+We love pull requests. Here's a quick overview of the process (detail below):
+
+1. Fork the repo.
+
+2. Run the tests. We only take pull requests with passing tests, and it's great
+to know that you have a clean slate.
+
+3. Add a test for your change. Only refactoring and documentation changes
+require no new tests. If you are adding functionality or fixing a bug, we need
+a test!
+
+4. Make the test pass.
+
+5. Push to your fork and submit a pull request.
+
+At this point you're waiting on us. We may suggest some changes or improvements
+or alternatives. Once we approve, we will merge your branch in.
+
+Some things that will increase the chance that your pull request is accepted,
+taken straight from the Ruby on Rails guide:
+
+* Use Rails idioms and helpers
+* 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
+
+
+Requirements
+--------------
+
+This is a Rails 3.2 application running on Ruby 1.9.3 and deployed to Heroku's
+Cedar stack. It has an RSpec and Turnip test suite which should be run before
+committing to the master branch.
+
+Please remember this is open-source, so don't commit any passwords or API keys.
+Those should go in config variables like `ENV['API_KEY']`.
+
+
+Laptop setup
+------------
+
+Fork the repo and clone the app:
+
+ git clone git@github.com:[GIT_USERNAME]/sched.do.git
+
+
+Install Bundler 1.2.0.pre or higher:
+
+ gem install bundler --pre
+
+Set up the app:
+
+ cd sched.do
+ bundle --binstubs
+ rake db:setup
+
+Edit your .env file to store the keys given to you by Yammer:
+
+ cp sample.env .env
+ vi .env
+
+Run the server using [foreman:](https://github.com/ddollar/foreman)
+
+ foreman start -p 3000
+
+We use foreman because it picks up the `.env` file. Also, it will use Thin as
+the app server instead of Webrick, same as Heroku's Cedar stack.
+
+Check it out:
+
+ http://localhost:3000
+
+
+Running tests
+-------------
+
+Run the whole test suite with:
+
+ rake
+
+Run individual specs like:
+
+ rspec spec/models/user_spec.rb
+
+Tab complete to make it even faster!
+
+When a spec file has many specs, you sometimes want to run just what you're
+working on. In that case, specify a line number:
+
+ rspec spec/models/user_spec.rb:8
+
+
+Syntax
+------
+
+* Two spaces, no tabs.
+* No trailing whitespace. Blank lines should not have any spaces.
+* 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 tests!
+
+
+Development process
+-------------------
+
+For details and screenshots of the feature branch code review process,
+read [this blog post](http://robots.thoughtbot.com/post/2831837714/feature-branch-code-reviews).
View
2  Procfile
@@ -1,2 +1,2 @@
-web: bundle exec thin start -p $PORT -e $RACK_ENV
+web: bundle exec rails server thin start -p $PORT -e $RACK_ENV
worker: bundle exec rake jobs:work
View
94 README.md
@@ -7,106 +7,18 @@ everybody.
This app showcases Yammer integration such as adding activity messages,
messaging your friends, messaging groups, and open graph integration.
-Requirements
---------------
-This is a Rails 3.2 app running on Ruby 1.9.3 and deployed to Heroku's Cedar
-stack. It has an RSpec and Turnip test suite which should be run before
-committing to the master branch.
-Please remember this is open-source, so don't commit any passwords or API keys.
-Those should go in config variables like `ENV['API_KEY']`.
-
-
-Laptop setup
+Contributing
------------
-Fork the repo and clone the app:
-
- git clone git@github.com:[GIT_USERNAME]/sched.do.git
-
-
-Install Bundler 1.2.0.pre or higher:
-
- gem install bundler --pre
-
-Set up the app:
-
- cd sched-do
- bundle
- rake db:create
- rake db:migrate
-
-Edit your .env file:
-
- cp sample.env .env
- vi .env #Use the keys given to you by Yammer
-
-Run the server with foreman:
-
- foreman start -p 3000
-
-We use foreman because foreman picks up on the `.env` file.
-
-Go to the server:
-
- http://localhost:3000
-
-Running tests
--------------
-
-Run the whole test suite with:
+To contribute to this project, see the [CONTRIBUTING.md](https://github.com/yammer/sched.do/blob/master/CONTRIBUTING.md) file.
- rake
-
-Run individual specs like:
-
- rspec spec/models/user_spec.rb
-
-Tab complete to make it even faster!
-
-When a spec file has many specs, you sometimes want to run just what you're
-working on. In that case, specify a line number:
-
- rspec spec/models/user_spec.rb:8
-
-Development process
--------------------
-
-To run the app in development mode, use Foreman.
-
- foreman start -p 3000
-
-It will pick up on the Procfile and use Thin as the app server instead of
-Webrick, which will also be used by Heroku's Cedar stack.
-
- gem install git_remote_branch
- git pull --rebase
- grb create feature-branch
- rake
-
-This creates a new branch for your feature. Name it something relevant. Run the
-tests to make sure everything's passing. Then, implement the feature.
-
- rake
- git add -A
- git commit -m "my awesome feature"
- git push -u origin feature-branch
-
-Open up the Github repo, change into your feature-branch branch. Press the "Pull
-request" button. It should automatically choose the commits that are different
-between master and your feature-branch. Create a pull request on your forked
-repository, then set the Head Repo to the original sched.do codebase.
-
-Be sure to submit complete test coverage for your change/new feature and a clear
-description of the issue you're addressing.
-
-For more details and screenshots of the feature branch code review process,
-read [this blog post](http://robots.thoughtbot.com/post/2831837714/feature-branch-code-reviews).
Most importantly
----------------
Have fun!
+
License
-------
sched.do is Copyright © 2012 Yammer, inc. It is free software and may be
Please sign in to comment.
Something went wrong with that request. Please try again.