Add github folder (#28)

Author: nathanmsmith

.github/CODEOWNERS

@@ -0,0 +1 @@
+*       @nathunsmitty

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at radio.web@media.ucla.edu. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

.github/CONTRIBUTING.md

@@ -0,0 +1,59 @@
+# Contributing Guidelines
+Oh hai! Looks like you're contributing to UCLA Radio code. Here are some things to know that will help you do that!
+
+Here at UCLA Radio, we strive to rapidly produce products without eschewing good coding practices or readability. Code review is one of the best ways to ensure this. Since we use GitHub to host all of our projects, our code review comes in the form of the [pull request](https://help.github.com/articles/about-pull-requests/).
+
+## Git
+GitHub revolves around this amazing piece of software called [git](https://git-scm.com). Git is what's known as a version control system, meaning that it tracks all changes we make to code. If you aren't familiar with git there are a lot of [great](https://try.github.io/levels/1/challenges/1) [resources](https://rogerdudler.github.io/git-guide/) to get you started--check them out, play around with it yourself, and then come back when you're feeling somewhat comfortable.
+
+## Our Workflow
+There a a lot of git workflows out there: [GitHub flow](https://guides.github.com/introduction/flow/), [git flow](http://nvie.com/posts/a-successful-git-branching-model/), the [Gitlab flow](https://about.gitlab.com/2014/09/29/gitlab-flow/), etc. Our workflow takes some common elements of these but adapts it for the practicality of our needs. The basic ideas are as follows:
+1. `master` is our stable branch, and is what is in production.
+2. Any change to `master`--whether that be a new feature, refactor, or bug fix--is done by creating a separate branch off of `master` with the naming scheme `<your first name>/<descriptive-title-for-your-change>`. For example if Nathan were to add a feature making the site font comic sans, he would name it `nathan/comic-sans` or something similar. The goal is for anyone else browsing the branch to immediately know the change the branch is making.
+3. When you think a feature is ready for production and after you've tested and linted it, make a pull request.
+    - **Note:** Create individual pull requests for every feature you make. It helps the people reviewing your code and makes it easier to revert changes back if any bugs are introduced.
+4. After you make any changes requested on that pull request and get the infamous [LGTM](http://www.lgtm.in) from a Web Manager, you can [squash merge](https://git-scm.com/docs/git-merge#git-merge---squash) it into `master`. This should be done via GitHub.
+5. After your branch is merged, you can delete it, both locally and remotely.
+
+## The Workflow in Practice
+Let's be real, there are a lot of git commands. They're complicated and hard to remember. Luckily, [Git Town](http://www.git-town.com) makes our workflow extremely easy with just 4 commands. 
+
+1. `git hack` creates a new branch off of `master`.
+2. `git commit` is the same as it was before. Git Town doesn't change anything.
+3. Instead of pushing commits to the remote copy of your new branch, run `git sync`. This pushes your commits, but also checks the remote for any changes to `master` and updates your branch accordingly.
+4. `git new-pull-request` makes it very easy to make that pull request when you're ready.
+5. Merging should be done via GitHub.
+6. You can also delete the remote copy of your branch via GitHub. To delete your local branch, run the command `git branch -d <your branch name>`.
+
+
+## Commit Guidelines
+
+Writing good commit messages is important for collaborative development and maintainability. It will also help you out in the future when you revisit your code. Please refer to [The seven rules of a great Git commit message](https://chris.beams.io/posts/git-commit/#seven-rules) on the guidelines we strive to follow. That being said, as [Zach Holman puts it](https://zachholman.com/posts/git-commit-history/), our "unit of change" is the pull request; it is much more import that your pull request be well written than your individual commits.
+
+## Reviewing a Pull Request
+
+There will be a point where you will not only have to create a pull request, but review one. When reviewing a pull request, remember that the main purpose of a pull request is to help your teammates learn and improve. Realize that no one, neither reviewer nor reviewee, is perfect and ask questions rather than assume something is immediately wrong. We're all on the same team (literally), so focus on being polite and constructive to your teammates. If you run into any disagreements, defer to your project manager. If you and your project manager disagree, defer to the online editor.
+
+If you are tagged, you **must** look at the code and respond within two days. The reviewee cannot ship your code without your feedback. You are free to peruse and comment on other pull requests if you so wish.
+
+When reviewing code, you should read through all the code changed, added, and deleted, looking for anything that looks out of place or different from how you would do it. You should also pull the branch and run it locally on your machine to make sure everything works for you.
+
+Not sure what to look out for when reviewing code? Originate has a great list of things to look for in their [code review guide](https://www.originate.com/library/code-review-guide):
+> * Is every piece of code in the right place, i.e. model code in a model, controller logic in a controller, app-> specific helper code in a helper, generic helper code in a library?
+> * Do all classes have only one responsibility?
+> * Do all methods do only one thing?
+> * If a method has a side-effect, is that clear from the name, and otherwise documented?
+> * Are all classes/methods/variables named properly so that the code is self-describing?
+> * Is everything as private as possible, i.e. only the intended public interface is public?
+> * Are too many things private? This could be an indication that you should extract a class.
+> * Are all files within a reasonable size (e.g., less than 100 lines of code)?
+> * Are all methods less than 10 lines of code?
+> * No law of demeter violations (providing whole objects to methods when all that’s needed is the value of one attribute of them)?
+> * Is everything tested? Is each thing tested enough? Is it not over-tested?
+> * Are there tests for private methods? This shouldn't happen, it is a code smell.
+> * Every class should have a small comment describing what it represents/does. Public methods should have comments describing what they are for, or when to call them, if this isn’t obvious from the code. Comments shouldn’t describe what the method does (this is visible from looking at the code).
+> * Are there any obvious performance-problems, like making a database query for each loop iteration, rather than using a more optimized query that loads all data at once?
+> * Spacing errors like no empty line between methods, or too many empty lines
+> * There shouldn’t be any commented-out code.
+> * There should be no debug statements like `console.log` or the likes.
+> * There should be no TODO's, as this is often a crutch for being lazy.

.github/issue_template.md

@@ -0,0 +1,32 @@
+<!--- Be sure to add a descriptive title above! -->
+
+## Context
+<!--- How has this issue affected you? What are you trying to accomplish? Providing context helps us come up with a solution that is most useful in the real world. -->
+
+## Expected Behavior
+<!--- If you're describing a bug, tell us what should happen. If you're suggesting a change/improvement, tell us how it should work. -->
+
+## Current Behavior
+<!--- If describing a bug, tell us what happens instead of the expected behavior. If suggesting a change/improvement, explain the difference from current behavior -->
+
+## Possible Solution
+<!--- Not obligatory, but suggest a fix/reason for the bug, or ideas how to implement the addition or change -->
+
+## Screenshot(s)
+<!--- (if applicable--you can delete otherwise) -->
+
+## Steps to Reproduce
+<!--- (for bugs only--you can delete if otherwise) -->
+<!--- Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include code to reproduce, if relevant. -->
+1.
+2.
+3.
+4.
+
+## Your Environment
+<!--- (for bugs only--you can delete if otherwise) -->
+<!--- Include as many relevant details about the environment you experienced the bug in. Put an `x` in the boxes that apply -->
+
+Device:
+iOS Version:
+<!--- If other, please add -->

.github/pull_request_template.md

@@ -0,0 +1,39 @@
+<!--- Be sure to add a descriptive title above! -->
+
+## Types of changes
+<!--- What types of changes does your code introduce to UCLA Radio? Put an `x` in the boxes that apply. -->
+
+- [ ] Bugfix (change which fixes an issue)
+- [ ] New feature (change which adds functionality)
+- [ ] Refactor (change which changes the codebase without affecting its external behavior)
+- [ ] Non-breaking change (fix or feature that would causes existing functionality to work as expected)
+- [ ] Breaking change (fix or feature that would cause existing functionality to __not__ work as expected)
+
+## Purpose
+<!--- Describe the problem or feature. Link to the issue(s) fixed by this pull request if applicable. -->
+
+## Approach
+<!--- How does your change address the problem? -->
+
+## Learning
+<!--- Describe the research stage. Link to any blog posts, video, patterns, libraries, addons, or other resources that helped you to solve this problem. -->
+
+## Screenshot(s) 
+<!--- (if applicable--you can delete otherwise) -->
+<!--- Include a screenshot here if the change you made changes the look of the site in any way! -->
+
+## Checklist
+<!--- Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code. -->
+
+- [ ] My branch follows the branch naming scheme of UCLA Radio, and can merge into `master` without error.
+- [ ] My code follows the code style of this project, and I have linted it to confirm this.
+- [ ] I have added tests that prove my fix is effective or that my feature works.
+- [ ] My change requires a change to the documentation and I have updated the documentation accordingly.
+- [ ] All new and existing tests passed.
+
+## Platform
+<!--- (if applicable--you can delete otherwise) -->
+__Operating System:__ <!--- e.g., iOS 11.1 -->  
+
+## Further Comments
+<!--- Please add anything that you'd like to say that you didn't already get a chance to. You can delete this if you don't have anything to add. -->