Merge pull request #1400 from serverless/v1.0-alpha1-austen

Contributor Improvements

.github/CONTRIBUTING.md

@@ -0,0 +1,50 @@
+# Contributing Guidelines
+
+Welcome, and thanks in advance for your help!  Please follow these simple guidelines :)
+
+## Pull Requests
+Please follow these Pull Request guidelines when creating Pull Requests:
+* If an Issue exists, mention in there that you are working on a solution.
+* If an Issue does not exist, create a new Issue, detail your changes.  We recommend waiting until we accept it, so you don't waste your precious time.
+* Follow our **Testing** and **Code Style** guidelines below.
+* Squash multiple commits into a single commit via `git rebase -i`.
+* Start commit messages with a lowercase verb such as "add", "fix", "refactor", "remove".
+* Submit your PR and make sure the Travis-CI builds don't fail.
+* Reference the issue in your PR.
+
+## Issues
+Please follow these Issue guidelines for opening Issues:
+* Make sure your Issue is not a duplicate.
+* Make sure your Issue is for a *feature request*, *bug report*, or *a discussion about a relevant topic*.  For everything else, please use StackOverflow with the `serverless` tag.
+* Add the relevant Issue Label(s) and together we will keep them updated.
+
+### Code Style
+We aim for clean, consistent code style.  We're using ESlint to check for codestyle issues using the Airbnb preset. 
+
+Please follow these Code Style guidelines when writing your unit tests:
+* In the root of our repo, use this command to check for styling issues: `./node_modules/eslint/bin/eslint.js filename.js`
+* There are likely ESlint plugins for your favorite code editor that will make this easier too!
+
+### Testing
+We aim for 100% test coverage, so make sure your tests cover as much of your code as possible.  For test coverage, we use Istanbul locally and Coveralls on our repo.  During development, you can easily check coverage by running `npm test`, then opening the `index.html` file inside the `coverage` directory.
+
+Please follow these Testing guidelines when writing your unit tests:
+*  Include a top-level `describe('ClassName')` block, with the name of the class you are testing.
+*  Inside that top-level `describe()` block, create another `describe('#methodOne()')` block for each class method you might create or modify.
+*  For each method, include an `it('should do something')` test case for each logical edge case in your changes.
+*  As you write tests, check the code coverage and make sure all lines of code are covered.  If not, just add more test cases until everything is covered.
+*  For reference and inspiration, please check our `tests` directory.
+
+## Providing Support
+The easiest thing you can do to help us move forward and make an impact on our progress is to simply provide support to other people having difficulties with their Serverless project. You can do that by replying to issues on Github, or simply chatting with other community members on Gitter. Your very presence is enough to make us happy.
+
+## Improving Documentation
+Maintaining and updating the docs on a regular basis is a hard task. The more eyeballs on the docs the higher quality it'll get and the less chances there will be for typos and confusion. We keep our docs in the `docs` folder in our main repo. If you see any issues with our docs, simply open an issue or a PR.
+
+## Our Code of Conduct
+Finally, to make sure you have a pleasant experience while being in our welcoming community, please read our [code of conduct](code_of_conduct.md). It outlines our core values and believes and will make working together a happier experience.
+
+Thanks again for being a contributor to the Serverless Community!
+
+Cheers,
+The [Serverless](http://www.serverless.com) Team

.github/ISSUE_TEMPLATE.md

@@ -1,22 +1,35 @@
+* Check if an Issue already exists for this
+* Add the relevant label(s)
+* Be kind :)
 
-- Before you open an issue, please check if a similar issue already exists or has been closed before.
-- If you're more interested in a real-time conversation with our community, join us in [our offical Gitter room](https://gitter.im/serverless/serverless)
-- Make note of the labels that we add to your issue, these labels could represent the status of the issue (ie. in progress, resolved, released...etc)
+Bug Report Template -----------------------------------------------
 
-### When reporting a bug, please be sure to include the following:
-- [ ] A descriptive title
-- [ ] What version of Serverless you're using, and the platform(s) you're running it on
-- [ ] What packages or other dependencies you're using
-- [ ] The behavior you expect to see, and the actual behavior
-- [ ] If you're facing Errors, make sure to provide the full Error stack
+##### Serverless Framework Version: 
 
-### When requesting a new feature or enhancement, please be sure to include the following:
-- [ ] The reason why you think this new feature will help you and help other users as well
-- [ ] The reason why you think this new feature is relavent to the Serverless Framework (within scope)
-- [ ] If you're familiar with our codebase, I'd be really helpful to share some design ideas on how to implement it, or better yet, open a PR!
+##### Operating System: 
 
-### When you want to start a discussion, please note the following:
-- [ ] Discussion issues are genearlly low priority for the core team, but we still love to be involved.
-- [ ] Please Make sure there's no similar issue discussing the same matter.
-- [ ] Please keep the discussion light and ego free. Share all your thoughts but be friendly. We're all here to learn from each other :)
-- [ ] If you want to ask a direct how-to question, please make sure you checked the docs carefully and didn't find the answer there.
+##### Expected Behavior:
+
+##### Actual Behavior:
+
+##### Stack-Trace (Optional):
+
+Feature Request Template ------------------------------------------
+
+##### Feature Request:
+
+##### Benefits:
+
+* Benefit one...
+
+##### Drawbacks:
+
+* Drawback one...
+
+##### Additional Details:
+
+Discussion template  ----------------------------------------------
+
+##### TLDR:
+
+##### Discussion:

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,12 @@
+Pull Request Template ------------------------
+* Check out our Pull Request Guidelines here: https://github.com/serverless/serverless/blob/v1.0/CONTRIBUTING.md
 
-Before submitting a PR, please:
+##### Status:
 
-- [ ] Check if there's an issue opened for this fix/feature to ensure it's something we intend to support and maintain (issues are not required for minor fixes)
-- [ ] Test your changes thoroughly
-- [ ] If there are some side effects to your changes (positive or negative), please mention them in your PR
+Ready/In Development/Hold
 
-Above all, we thank you for your contribution! :)
+##### Description:
+
+##### Todos:
+
+- [ ] Write tests

CONTRIBUTING.md

@@ -1,47 +0,0 @@
-We'd like to thank you in advance for your contributions to Serverless. This project wouldn't have been possible without awesome people like you. To get the best out of this community, please follow the following guidlines whenever you make a contribution:
-
-## Pull Requests
-Before you open a PR, please make sure you open an issue for it to discuss your changes first. This is just to ensure that your changes are within our roadmap and that your PR will be accepted and your efforts won't be wasted.
-
-If your PR solves a specific open bug on our issue tracker or a feature request that we've decided to support, in that case opening a new issue is unnecessary. We just want to make sure we're aware of any work you'll be doing in advance so that we can help you along the way. Regardless of what you do, we appreciate you for just being in our community.
-
-Once you start working on a PR, please follow our Testing and Code Style guidelines below. We can't accept your PR if it fails in any of these two critical areas. Whenever you make or update a PR, 3 checks fire on this PR from Travis-CI and Coveralls. If the builds fail, we can't accept your PR.
-
-### Testing Guidelines
-We're crazy about testing! we test everything and we aim for 100% test coverage. For test coverage, we use Istanbul locally, and coveralls on our main repo.
-
-During development, please make sure your tests cover every single piece of code you write, you can easily check this coverage by opening the `index.html` file inside the `coverage` directory after you run the tests with `npm test`.
-
-When you write unit tests, please follow our naming conventions for unit tests. Please include a top level `describe('ClassName')` block with the name of the class you're testing. Inside that `describe()` block, create another `describe('#methodOne()')` block for each method you have in your class.
-
-For each method include a separate `it('should do something')` test case for each logical edge case in your new changes. After you write couple of tests, run the tests, check the code coverage and make sure all lines of code are covered, if not, just add more test cases that covers it. For reference and inspiration, please check our `tests` directory.
-
-Make sure the description of the blocks matches the format you see here.
-
-### Code Style Guidelines
-Internally, we're using ESlint to check for codestyle issues using the airbnb preset. To stay consistent, please make sure you follow this codestyle carefully and that your changes doesn't have any styling issues. We can't accept your PR if your changes are not consistent with our code style.
-
-You can check for styling issues in a file using ESlint using the following command: (in the root of our repo)
-
-```
-./node_modules/eslint/bin/eslint.js filename.js
-```
-You'll probably find ESlint plugins for your favorite code editor that will make this easier.
-
-## Opening Issues
-Before you open an issue, please make sure it's not a duplicate of an existing open (or closed) issue. A Github issue could be a feature request, a bug report, or simply a discussion about related topics. For support questions, please use StackOverflow with the `serverless` tag instead.
-
-When you open an issue, we'll add relevant labels to that issue asap to reflect category, area of code, status and priority of the issue. We'll keep those labels updated to keep you updated on our progress. 
-
-If your issue is a bug report, please make sure you include an accurate/detailed description of the issue you're facing and how to reproduce it. Make sure you mention your Serverless version, as well as your environment (node/npm version, OS...etc)
-
-## Providing Support
-This simplest thing you can do to help us move forward and make an impact on our progress is to simply provide support to other people having some difficulties with their Serverless project. You can do that by replying to issues on Github, or simply chatting with other community members on Gitter. Your very presence is enough to make us happy.
-
-## Improving Documentation
-Maintaining and updating the docs on a regular basis is a hard task. The more eyeballs on the docs the higher quality it'll get and the less chances there will be for typos and confusion. We keep our docs in the `docs` folder in our main repo. If you see any issues with our docs, simply open an issue or a PR.
-
-## Our Code of Conduct
-Finally, to make sure you have a pleasant experience while being in our welcoming community, please read our [code of conduct](code_of_conduct.md). It outlines our core values and believes and will make working together a happier experience.
-
-Thank you for being a part of our loving community!