Add contributing info for first comers

CONTRIBUTING.md

@@ -5,7 +5,7 @@ In particular, this community seeks the following types of contributions:
 
 * code: contribute your expertise in an area by helping us expand OSEM
 * ideas: participate in an issues thread or start your own to have your voice heard.
-* copy editing: fix typos, clarify language, and generally improve the quality of the content of OSEM
+* code editing: fix typos, clarify language, and generally improve the quality of the content of OSEM
 
 ### Runing OSEM for development
 We are using [Vagrant](https://www.vagrantup.com/) to create our development environments.
@@ -66,6 +66,42 @@ You can access the app [localhost:3000](http://localhost:3000). Whatever you cha
   * If you are already a contributor and you get a positive review, you can merge your pull-request yourself
   * If you are not a contributor already please request a merge via the pull-request comments
 
+### Getting Started
+
+* When you get involved with OSEM for the first time, you can choose issues labeled as [Junior]( https://github.com/openSUSE/osem/issues?q=is%3Aissue+is%3Aopen+label%3AJunior)
+* Leave a comment on the issue that you want to work on it
+  * We expect you to work on it and show progress by either opening a PR or commenting on the issue
+  * If you change  your mind, and do not want to work on the issue any more, please be fair to others and leave a comment to let us know
+  * Do **not** work on issues that are assigned to others. If you are uncertain, ask and wait for a **contributor** to reply
+* Avoid working on issues that have no label
+  * If you have opened a new issue, please wait for a contributor to add relevant labels
+* If an issue is a feature, we should first have a rough idea on how we want to implement it
+  * If there is already such a discussion on the issue, you can go ahead and pick this up
+  * If not, please first leave a comment on how you want to implement it and wait for contributors' feedback
+
+### Pull Requests workflow
+Please open a PR only when you have finished coding, and your changes are ready to be reviewed for merging.
+
+* Title
+  * Include a comprehensive title about what this PR is doing
+  * Referencing the issue number on the PR title is not giving any information about what this PR is about
+* Description
+  * Add a couple of lines about what is the problem you are trying to solve and how you have addressed it
+  * Add bullet points about the new things you are introducing, if applicable
+  * Reference the issue
+* Automated checks
+  * We automatically run the test suite and security checks on every PR
+  * Check back later to see if all checks were successful, if not, address them or leave a comment to ask for help
+* Pushing new changes to your PR
+  * Always add **new** commits; this tremendously helps reviewers
+  * Do not squash commits, unless explicitly requested by the reviewer
+* Take care of your PR
+  * Make sure you check the status of your PR regularly
+  * Address your reviews, make the necessary changes, ask if something is not clear to you
+  * Rebase against newest changes, when needed, we cannot properly review PRs that are not rebased
+
+Reviewing your PR might take some time, as we are all volunteers. Please be responsive and respectful.
+
 ### Coding Style
 We are using [rubocop](https://github.com/bbatsov/rubocop) as a style checker. It is checking code style each time the test suite runs. You can run it locally with