OSS Quepid

.env.example

@@ -0,0 +1,23 @@
+PORT=3000
+
+RACK_ENV=development
+RAILS_ENV=development
+
+MAX_THREADS=2
+WEB_CONCURRENCY=2
+
+FORCE_SSL=false
+
+DB_ADAPTER=mysql2
+DB_HOST=mysql
+DB_USERNAME=root
+DB_PASSWORD=password
+DB_NAME=quepid
+
+REDIS_URL=redis://redis:6379/1
+
+QUEPID_GA=UA-
+QUEPID_DOMAIN=localhost
+
+INTERCOM_APP_ID=
+INTERCOM_API_KEY=

.github/CONTRIBUTING.md

@@ -0,0 +1,127 @@
+# How to contribute
+
+This guide is essential to keeping the contribution process easy and simple for everyone. As the team grows, we need to make sure there are guidelines for what is expected from each contributor. Also, to ensure that the applications we contribute to continue to be maintainable, we need to define what that looks like.
+
+
+## Getting Started
+
+* Make sure you have a [GitHub account](https://github.com/signup/free)
+* Submit a ticket for your issue, assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Use the `ISSUE_TEMPLATE/*` as a guide.
+* Clone the repo.
+
+## Making Changes
+
+* Create a topic branch from where you want to base your work.
+  * This is usually the staging branch.
+  * Only target release branches if you are certain your fix must be on that
+    branch.
+  * Use the type of work (feature, bugfix, enhancement) at the beginning of the branch name if applicable (eg. `feature/123-branch-name`).
+  * Follow the type by the Github ticket number at the beginning of the branch name if applicable (eg. `feature/123-branch-name`).
+  * Use a short but descriptive name of the branch that matches the ticket title or summary (eg. `feature/123-add-csv-import`).
+  * Use dashes in the name as a separator.
+  * To quickly create a topic branch based on staging; `git checkout -b feature/123-add-csv-import staging`. Please avoid working directly on the
+    `master` or the `staging` branch.
+* Make commits of logical units.
+* Check for unnecessary whitespace with `git diff --check` before committing.
+  * Make sure you have setup your editor to trim ending whitespace.
+  * Make sure you have setup your editor to add an empty line at the end of each file.
+  * Make sure you have setup your editor to use spaces instead of tabs, and indentations of 2 spaces.
+* Run `rubocop` before committing to ensure your changes meet our style guidelines.
+  * Even though rubocop allows lines of up to 120 characters, try to keep it under 80.
+  * Set your editor to show a wrap-guide line at 80 characters to help you follow this rule.
+  * You can disable rubocop rules inline when necessary, but try not to make a habit of it.
+  * If you strongly disagree with a rubocop rule, discuss it with the team and we can
+    potentially change the configuration.
+* Make sure your commit messages are in the proper format.
+
+```git
+(#123) Make the example in CONTRIBUTING imperative and concrete
+
+Without this patch applied the example commit message in the CONTRIBUTING
+document is not a concrete example. This is a problem because the
+contributor is left to imagine what the commit message should look like
+based on a description rather than an example. This patch fixes the
+problem by making the example concrete and imperative.
+
+The first line is a real life imperative statement with a ticket number
+from our issue tracker. The body describes the behavior without the patch,
+why this is a problem, and how the patch fixes the problem when applied.
+```
+
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+
+## Writing Translatable Code
+
+Rails has i18n baked in, so we should put all user facing strings in translation files.
+
+When adding user-facing strings to your work, follow these guidelines:
+* Use full sentences. Strings built up out of concatenated bits are hard to translate.
+* Use scopes to organize strings based on where they are used.
+  Example:
+  ```yml
+  en:
+    views:
+      qualified_leads:
+        index:
+          header: Qualified Leads
+  ```
+  or
+  ```yml
+  en:
+    mailers:
+      qualified_leads:
+        notify_admins:
+          subject: New Qualified Lead
+  ```
+* Use a directory structure that mimics the namespacing.
+* Use the name of the class (eg. the AR model, or controller) to group strings.
+* Use the name of the method or action when applicable.
+* Use `success` and `error` under controller actions to differentiate between the happy path and the failure path.
+* Use variables when needed to pass dynamic content to the string.
+  Ex. `t :body, scope: [ :qualified_lead_mailer, :notify_admins ], lead_id: @lead.short_id, name: @name`
+* Use pluralization that is baked into Rails i18n for handling situations where the count matters.
+
+For more info, checkout the [guides](https://guides.rubyonrails.org/i18n.html).
+
+It is the responsibility of contributors and code reviewers to ensure that all user-facing strings are marked in new PRs before merging.
+
+## Making Trivial Changes
+
+### Documentation
+
+For changes of a trivial nature to comments and documentation, it is not
+always necessary to create a new ticket. In this case, it is appropriate to
+start the first line of a commit with the type of change (eg. '(doc)' or '(bugfix)') instead of a ticket number.
+
+```git
+(doc) Add documentation commit example to CONTRIBUTING
+
+There is no example for contributing a documentation commit
+to the repository. This is a problem because the contributor
+is left to assume how a commit of this nature may appear.
+
+The first line is a real life imperative statement with '(doc)' in
+place of what would have been the ticket number in a
+non-documentation related commit. The body describes the nature of
+the new documentation or comments added.
+```
+
+## Submitting Changes
+
+* Push your changes to a topic branch.
+* Submit a pull request to the repository.
+* Try to keep PRs small, focused and self-contained. The goal is to have a high velocity of small changes instead of less frequent, large changes.
+* Assign another developer as the primary reviewer. They should try to review the PR within one business day time.
+* Try to respond to PR feedback within one business day. If a requested change is going to require more time to develop, at least acknowledge the comment and consider applying an "updating per feedback" label to the PR.
+* PRs may not be merged to master until they have been approved by at least one other developer.
+* Use PR labels to flag special cases, like "not ready for review" or "do not deploy"
+* You can mention other developers that might be interested in a comment or description with an `FYI @username` reference.
+
+
+# Additional Resources
+
+* [General GitHub documentation](https://help.github.com/)
+* [GitHub pull request documentation](https://help.github.com/articles/creating-a-pull-request/)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,31 @@
+<!--- Provide a general summary of your changes in the Title above -->
+
+## Description
+<!--- Describe your changes in detail -->
+
+## Motivation and Context
+<!--- Why is this change required? What problem does it solve? -->
+<!--- If it fixes an open issue, please link to the issue here. -->
+
+## How Has This Been Tested?
+<!--- Please describe in detail how you tested your changes. -->
+<!--- Include details of your testing environment, and the tests you ran to -->
+<!--- see how your change affects other areas of the code, etc. -->
+
+## Screenshots or GIFs (if appropriate):
+
+## Types of changes
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+- [] Bug fix (non-breaking change which fixes an issue)
+- [] New feature (non-breaking change which adds functionality)
+- [] Breaking change (fix or feature that would cause existing functionality to change)
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [] My code follows the code style of this project.
+- [] My change requires a change to the documentation.
+- [] I have updated the documentation accordingly.
+- [] I have read the **CONTRIBUTING** document.
+- [] I have added tests to cover my changes.
+- [] All new and existing tests passed.

.gitignore

@@ -0,0 +1,46 @@
+# VIM swp
+*.swp
+
+# Project files
+.idea/
+
+# Mac
+.DS_Store
+
+# Ignore bundler config.
+/.bundle
+
+# Ignore the default SQLite database.
+/db/*.sqlite3
+/db/*.sqlite
+/db/*.sqlite3-journal
+
+# Ignore all logfiles and tempfiles.
+/log/*
+!/log/.keep
+/tmp
+
+# Ignore vagrant artifacts
+.vagrant
+vagrant.rb
+
+# Ignore bower artifacts
+/vendor/assets/bower_components
+
+# Ignore local env file
+/.envrc
+.env
+
+# Ignore node artifacts
+node_modules
+npm-debug.log
+
+# Rails assets
+# Ignore compiled assets
+public/assets
+
+# Test Coverage
+coverage/
+
+# Docker artifacts
+public/srv

.jshintrc

@@ -0,0 +1,42 @@
+{
+  "bitwise": true,
+  "boss": true,
+  "browser": true,
+  "camelcase": false,
+  "curly": true,
+  "eqeqeq": true,
+  "eqnull": true,
+  "esnext": true,
+  "expr": true,
+  "immed": true,
+  "indent": 2,
+  "latedef": true,
+  "newcap": true,
+  "noarg": true,
+  "node": true,
+  "quotmark": "single",
+  "regexp": true,
+  "smarttabs": true,
+  "strict": true,
+  "sub": true,
+  "trailing": true,
+  "undef": true,
+  "unused": true,
+  "globals": {
+    "after": false,
+    "afterEach": false,
+    "angular": false,
+    "before": false,
+    "beforeEach": false,
+    "browser": false,
+    "describe": false,
+    "expect": false,
+    "inject": false,
+    "it": false,
+    "quepidMocks": false,
+    "spyOn": false,
+    "testTry": false,
+    "jQuery": true,
+    "$": true
+  }
+}