Contributing

Contributing to Teambox

If you want to include your code in the general Teambox release, follow these steps:

Getting started

• Get Teambox running locally, following the installation guide
• Get an account at Github and fork the project teambox.
• Checkout the edge branch dev
• Develop your feature or fix, writing tests where necessary.
• Organize your commits and rebase frequently. A good guide about this.

Submit your bugfix/feature upstream

• Rebase your copy to the latest dev branch, make sure it applies cleanly, squash "work-in-progress" commits, and avoid merge, we try to keep our tree linear.
• Run the tests.
• Send a pull request from Github.

Please read this article about contributing to Merb for best practices.

Commits

• Do one commit per change. Don't do two unrelated things in the same commit.
• Put a short, descriptive message on the first line, and then, if necessary, add details in a paragraph after a line break.
• Always explain why you did something, not how.

Branches and features

New feature should be pushed to a branch. If it's associated with a task on the teambox community project, name the branch as 324-description, where 324 would be the Teambox task id.

Tests

We won't accept features without tests. Use Cucumber and RSpec to cover all possible cases, specially those were things go wrong.

Integration testing with cucumber stories.

• Your cukes should test how the application behave, not how it work.
• Avoid non human readable in feature, add sub-step for it instead.

Not so good:

I should see "hello world" in the "div.message-box"

Awesome:

I should see "hello world" in the message box

Unit-testing with rspec.

• Test model and controller behaviour with spec.

Coding style

• Use two spaces for indentation, not tabs.
• Avoid trailing spaces.
• Write tests. Integration testing with cucumber and unit test with rspec.
• Clearness over cleverness. It’s better to write a simple, readable method.
• Avoid long methods. Break them into smaller ones (10 lines max).
• Write fat models, skinny controllers.
• Use ActiveRecord, avoid raw SQL.
  • It ensure compatibility with the supported databases
  • Its usually more readable
• If you write migrations, make sure they are revertible.
• Don't use english words in the code. Write localized strings using Rails i18n.
  • English is the default locale, if you want to provide localized strings in another locale, do it in separate commit.
• Naming convention is important part of making code readable.
  • Name methods and variables according to what they do.
  • Follow ruby/rails conventions
  • Pluralization rules
• Use private methods for things that are not meant to be used by others.