Added Contributing.md file

Signed-off-by: Lalit Umbarkar <[email protected]>

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# Introduction
+
+Thanks for your interest in Contributing to Open Source! 
+
+As this repository is for beginners, who are new to making Contributions, we'll 
+break down the guide as much as possible. This guide is a must read before you 
+start contributing for this repository. 
+
+In general, we try to follow [the Elm guidelines](https://twitter.com/czaplic/status/928359033844539393)
+and ask that you try to as well:
+
+  - Be kind.
+  - Learn from everyone.
+  - Collaboration requires communication.
+  - Not every problem should be solved with code.
+  - Communication _is_ contribution.
+  - Understand the problem.
+  - Explore all possible solutions.
+  - Pick one.
+  - Simplicity is not just for beginners.
+  - It's better to do it _right_ than to do it _right now_.
+  - It's not done until the docs are great.
+  - Take responsibility for user experiences.
+  - Make impossible states impossible.
+  - There are worse things than being explicit...
+
+We have created some issues in every project as a starting point for Beginners.
+There are two major types of contribution:
+  - Work on Existing Issues.
+  - Create a new Issue and submit its changes related to it.
+
+### Working on Existing Issues  
+
+Check out the [issues](https://github.com/vardhanapoorv/Open-Source-Contribution-Made-Easy/issues) 
+page and pick a issue you are interested in and add a comment mentioning the changes.
+As this repository is for beginners, we do not have any restrictions on how the specifics
+of implementation on how are fixing it, but we would want you to mention what are the 
+changes you are proposing. Any proposal you made you be accepted anyway (unless there is 
+a conflict with someone else's contribution).
+
+There are some issues with tag `minimal-work`, these issues are meant for those who are
+first timers, as there is no scope for making mistakes in this. Make sure that you do not 
+create PRs with just `minimal-work` issues. We recommend that you have other issues that 
+do not have `minimal-work` tag with the same PR.
+
+### Creating new Issue 
+
+A [new issue](https://github.com/vardhanapoorv/Open-Source-Contribution-Made-Easy/issues/new) 
+could e created if you think more improvement could be done in existing application OR 
+we are also open to new ideas for projects/languages to be included in this repository. 
+We could discuss how it would make others contributing easier.
+
+# Contributing changes
+
+If you _are_ interested in contributing changes to `Open-Source-Contribution-Made-Easy`, 
+please first select a issue or create a issue that you want to work on and 
+comment in it mentioning that you have these proposed changes, then fork this
+repository, make a new branch in your fork, commit your changes to that branch
+and then make a pull request from that branch. Mention the issue As part of 
+your pull request, make sure that you add yourself to the 
+[Contributors list](https://github.com/vardhanapoorv/Open-Source-Contribution-Made-Easy/issues/10).
+
+## Writing code
+
+As we have multiple languages in this repository, when writing your code, try 
+to follow existing code style as much as possible -
+in particular, this means:
+
+  - Wrap code (mostly) to 80 columns (type annotations and string literals can
+    be longer if you want).
+  - Use spaces instead of intends
+  - Make sure to use meaningful names for variables.
+
+Don't worry too much about writing documentation - small fixes for things like
+typos and formatting are certainly welcome. In a major project repo documentation 
+if important but you will get used to writing docs by contributing.
+
+## Testing
+
+In any other project, this would be of major importance for maintainers, as it 
+is easier for them to verify changes. But we have kept this as optional in this 
+repository.  If tests are exist for a given project, make sure that they pass 
+before creating PR. If they don't exist and you want to create tests for it, 
+create a new issue, explain your tests and create the PR. We would be happy to 
+help. 
+
+## Committing
+
+Git commits should generally be as small and focused as possible, so that they
+can be reviewed individually. Commit messages should follow [the seven rules of
+a great Git commit message](https://chris.beams.io/posts/git-commit/#seven-rules):
+
+  - Separate subject from body with a blank line
+  - Limit the subject line to 50 characters
+  - Capitalize the subject line
+  - Do not end the subject line with a period
+  - Use the imperative mood in the subject line
+  - Wrap the body at 72 characters
+  - Use the body to explain what and why vs. how
+