So, you want to learn how to program? Contributing to Operation Code is a great place to get started. This document will help you march from zero to deploying code in no time!

1. Technologies Used
2. Quickstart
3. Setting Up Your Environment
4. Finding an Issue
5. Working on Your Issue
6. Submitting Your Changes
7. Code of Conduct

The Operation Code site is comprised of a Rails API backend, and a React frontend.

When you visit our website you're interacting with two systems, a frontend application and a backend application. The frontend application is responsible for displaying images, text and data on our web pages.

Frontend applications are usually written using a combination of HTML, CSS, and Javascript and utilize one or more frameworks such as Angular, Backbone, Vue, and React.

https://operationcode.org uses React and can be viewed at https://github.com/OperationCode/operationcode_frontend.

The backend (where you are now) is responsible for:

• exchanging data with the frontend via custom API endpoints
• running various background jobs like inviting new users to Slack, or signing them up for our newsletter
• interacting with third party services like SendGrid, GitHub and ID.me
• validating the integrity of our data
• authentication and security protocols
• and more

As a contributor to the https://operationcode.org backend, you will have the opportunity to work with the following technologies, services, and popular gems:

• Ruby
• Ruby on Rails
• Redis
• PostgreSQL
• Docker
• GitHub
• Travis CI
• Code Climate
• Apiary.io
• Devise
• Geocoder
• ActsAsTaggableOn
• JWT
• HTTParty

1. Setting Up Your Environment
2. Find an Issue To Work On
3. Submit Your Pull Request

In order to work on the backend of the Operation Code site, you will need to install a few things.

There are three options for local setup:

• Docker (recommended)
• Native (coming soon)
• AWS Virtual Machine

• Now you have everything setup, you will need to find issues to work on. Operation Code uses Github's built in issue tracker. A listing of all our issues can be found here.

• Familiarize yourself with the issue types below, and browse for an issue that you want to work on. Don't be afraid to ask for clarification or help.

• Once you have found an issue, leave a comment stating that you plan to work on the issue. Once assigned to you, your mission is a go!

Issue types are managed through labels. The below labels help us easily identify and manage issues with different workflows.

Bugs are errors in code that produce unintended or unexpected results. In addition to the bug label, there may also be a tag indicating what the bug affects. For example issue#124 was a bug that affected the testing environment.

Features either add new functionality or improve existing functionality.

These items are hand picked as being great candidates as your first issue to work on.

High level overview of upcoming Operation Code goals. This is the source of upcoming issues.

• Please first read Operation Code's guidelines for working an issue

• From the forked and cloned repository on your environment, you can now create a feature branch. It is a good idea to name your branch after the issue it is attached to.

  git checkout -b <feature-branch-name>

• You can check the branch your are currently working on by using the branch command.

  git branch

• Once you have finished your work, head over to Operation Code's main GitHub page, and make a pull request. More information about pull requests can be found in the next section.

• To return to your main master branch, type the following in the terminal:

  git checkout master

We use Apiary for our API documentation, API mocking server, etc.

The API blueprint file is located at /operationcode_backend/apiary.apib, and our live API documentation itself is located at http://docs.operationcodeapi.apiary.io/

Please ensure that any PRs that change the behavior of the API are updated in the documentation as well. To do so:

• Create a free account at apiary.io
• Make your additions in the repository's apiary.apib file in your text editor
• Cut & paste the whole file into the apiary editor to confirm that all of these changes do not create any semantic issues
• Repeat until there are no semantic errors
• Commit the apiary.apib file as part of a normal commit in your pull request
• The API endpoints are alphabetized, so all additions will need to be placed accordingly

• When you have completed work on your feature branch, you are ready to submit a pull request.

• Each pull request should:

  • Be tied to a single issue
  • Be named after the issue with the designated issue # as the name of the branch
  • Be fully tested
  • Have its own tests
  • Not break existing tests

• Once your pull request has been submitted, it will be reviewed by a core team member. This process helps to familiarize more people with the codebase, and provides a second set of eyes and perspective to your new feature.

• If your code is accepted, it will be merged into the master branch. If all the tests pass, it will be automatically deployed to operationcode.org immediately.

• Congratulations! You have made your first contribution!

Each pull request is inspected by the following bots:

• CodeClimate - Checks for style validation errors, insecure and problematic code on pull requests.

• Travis - Runs the test suite on each check in, and deploys each change that gets merged.

Please read through and adhere to our code of conduct at all times.

Adhere to the Ruby Style Guide

Adhere to the Google JS Style Guide

By contributing your code, you agree to license your contribution under the MIT License.

By contributing to the code base, you agree to license your contribution under the Creative Commons Attribution 3.0 Unported License.