Added the basic open source fils back

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 [email protected]. 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/

CONTRIBUTING.md

@@ -0,0 +1,83 @@
+# Contributing
+
+The easiest way to keep Argot running smoothly is to maintain a rapid development environment.  Contributions should be easy and clear to understand, whether it is in between branches, or during code review.
+
+## Branches
+The following is an overview of all of the branches used within the project.  Below is an example flow.  **Note: There are some naming changes**
+
+![Example Flow](http://nvie.com/img/[email protected])
+
+### feature
+The feature branch(s) are individual branches with different modular features.
+*Naming Convention:* `feature-$featureName$`
+Feature branches will merge into master.
+
+### master
+The master branch houses the most recent changes.  **MAY NOT PASS INTEGRATION TESTS**
+
+### release
+The release branch is used for testing incremental builds of the platform. Once changes are deemed stable enough from Master, and are moved into staging. **MUST PASS INTEGRATION TESTS**.  Once in release, a new instance is automatically spun up in production data for internal testing.
+
+### hotfix
+The hotfix branch(s) are individual branches used to quickly integrate patches and fixes ASAP.
+*Naming Convention:* `hotfix-$hotfixName*`
+Hotfix branches merge directly into production
+
+### stable
+The stable branch is pretty self explanatory... Its the code currentlyin the latest stable build.
+
+## Pushing Code
+Commits should be made during and after incremental changes on its corresponding feature branch. Commit messages should be clear and descriptive, and should not be like any of the following at the link: [bad but funny examples](https://www.facebook.com/steventhanna/media_set?set=a.313618052177148.100005450594604&type=3).
+
+One submitting a pull request, the PR's commits will be squashed before being merged (all commits pushed into one).
+
+## Issues
+The issues tool is used for bug tracking, feature request, and milestone tracking.
+
+### Bug's
+Bugs generated from user submissions will not automatically be inputed into Github Issues.  Eventually this will change as the quality of our internal tools increases, but for now it must be done manually.
+
+That being said, issues should have clear and relatively short titles, with heavily documented descriptions. The description should include any steps to reproduced the problem (if it is a bug), or use cases and example software flow (for feature requests).  The more information the better.  Select the appropriate label(s) for the issue, as well as possible signees.
+
+### Feature request's
+Features are integral to the Ritmico Platform. All feature requests should include a clear title, and well documented description as to the nature of the feature, the flow in the software that it should take, and any implications on the current system or infrastructure.
+
+Features currently being worked on with be assigned to a specific person or persons, and will receive the `In Progress` label. The assignee(s) of that feature are responsible for that feature, both in development and during deployment should any bugs arise.
+
+## Pull Requests
+Pull Request will be Argot's major form of code review.  When merging between feature and master branches, Pull Requests must pass all integration tests and other styling tests. Pull Requests must pass both the integration tests, and actual manual testing done by contributors.
+
+Pull Requests should include a descriptive title in regards to the feature being modified, as well as a well documented description touching on what has been changed, any difficulties in the code (bugs we should keep an eye on), methods used, and any possible conflicts.  After a code review by other Argot developers, the feature branch will be merged into master.
+
+When the feature branch is merged into master, it is the feature's assignee(s) job to ensure its behavior in the master branch and beyond.  This means maintaining  proper testing in master, and adapting the feature as demand changes.
+
+
+## Adding New Languages
+Language support is paramount to the success of Argot as a documentation system, and new languages will always be suggested.  Adding new languages in Argot takes only a few lines of code, and knowing Java is not critical.
+
+1. Add a new case to the switch statement in the file `ArgotFile` under the function `delegateLanguages`. The case should be the extension of the file of your language you want to add.
+1. Fill in the following:
+
+```java
+lang = new Language(contents, [...]);
+```
+
+The `Language` constructor has been overloaded to accept multiple types of comment configurations.  For a complete description, check out the documentation [here](https://github.com/steventhanna/Argot/wiki/Language#language-1). In brief:
+
+- Single comment style [docs](https://github.com/steventhanna/Argot/wiki/Language#language-1)
+```java
+// Python
+lang = new Language(contents, "#");
+```
+- Differing Begin and End Multi-line Style (Normal for Multi-line comments) [docs](https://github.com/steventhanna/Argot/wiki/Language#language-2)
+```java
+// Java
+lang = new Language(contents, "*", "/**", "*/");
+```
+## Adding new Argot Types
+An Argot Type is what comes after `@type :: `. In order to add a type:
+
+- New file named `YourtypeComment.java`
+- Must implement `TypeComment`
+- Must fill out all methods required from `TypeComment`
+- In `Language.java` add your type to the switch statement in `delegateComments`