gunghogeoduck/osem-fcy
1
0
Fork 0
mirror of https://github.com/openSUSE/osem.git synced 2026-08-13 19:54:02 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #1351 from differentreality/contributing_guide

Browse source 
Add contributing info for first comers
This commit is contained in:
Ana María Martínez Gómez 2017-03-10 12:48:54 +01:00 • committed by GitHub
commit f7f5ab8b58
1 changed files with 37 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

38
CONTRIBUTING.md
View file

@ -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