Contributing to Base

Thanks for showing an interest in contributing to Base!

Although Base is open source, I try to keep considerable changes to the project limited.

There are two implications behind this decision:

1. I use Base as the starter kit for all recipes on The Meteor Chef, and want to avoid making any changes that will "pull the rug out" from under me.
2. Base is intended as a beginner-friendly starter kit. Some pro's may have implementation or configuration preferences that can fly over the head of people just getting comfortable with Meteor. The more simplistic the project is kept, the better.

This doesn't mean contributions aren't welcome!

Submitting Issues

The #1 way you can help to contribute to Base is to open issues when you bump into an error, think of a better way to implement an existing feature, or come up with a brand new feature that would be cool to add. When submitting issues, make sure to take the following steps:

1. Use a succinct, but descriptive title. For example, if you had an idea for a new feature related to adding oAuth accounts, you might use Add oAuth support.
2. Add a detailed description. The more information you can provide, the better. This applies to features, refactors, and bugs. I don't mind reading if it helps me to understand what's up. Brownie points if you've thought about it enough to add a checklist :)
3. Add the appropriate label. I like to use three labels for issues: feature, refactor, and bug. These correspond to the branching strategy used while writing code (see below). Before you add your issue, make sure to mark the correct label.

Submitting Pull Requests

1. If it doesn't already exist, add an issue for what you'd like to add following the instructions above.
2. Make sure to write your code in JavaScript. Base used to be written in CoffeeScript but was ported to make it more accessible for the community.
3. Try not to add any CSS, save for funky margin/padding snags. If you do need to add CSS, you're welcome to use Sass (scss syntax). If you're adding a bunch of CSS, make sure to break it off into a Sass partial (i.e. _file-name.scss) with a name similar to where it's being applied (e.g. the login template has a _login.scss file).
4. Take a look at Git Extras and try to make use of their feature, refactor, and bug patterns. If you're not feeling it, at the very least, name your branches like so: <type>/descriptive_name_#00. For example, when refactoring some code for the login page you might create a branch called refactor/improve_login_flow_#15.
5. When you're ready create a new pull request. I try to be fairly responsive to PR's, issues, and questions, but sometimes I fall behind. If you're eager to get your PR looked at, send me a tweet with a link to your PR that says "BRO, do you even GitHub?!" I'm not kidding. It's embarrassing on purpose. Do it or be ignored at your own peril! /evillaugh

Asking Questions

Yes! I love questions. If you're not sure about something, really anything, feel free to send an email to help@themeteorchef.com and I'll see what I can do :)