feat(all): initial commit

.gitignore

@@ -0,0 +1,6 @@
+.idea
+.project
+.classpath
+target
+*.iml
+/bin

CODE_OF_CONDUCT.md

@@ -0,0 +1,72 @@
+### American Express Open Source Community Guidelines
+
+#### Last Modified: January 29, 2016
+
+Welcome to the American Express Open Source Community on GitHub! These American Express Community Guidelines outline our expectations for Github participating members within the American Express community, as well as steps for reporting unacceptable behavior. We are committed to providing a welcoming and inspiring community for all and expect our community Guidelines to be honored.
+
+**IMPORTANT REMINDER:**
+
+When you visit American Express on any third party sites such as GitHub your activity there is subject to that site’s then current terms of use., along with their privacy and data security practices and policies. The Github platform is not affiliated with us and may have practices and policies that are different than are our own.
+Please note, American Express is not responsible for, and does not control, the GitHub site’s terms of use, privacy and data security practices and policies. You should, therefore, always exercise caution when posting, sharing or otherwise taking any action on that site and, of course, on the Internet in general.
+Our open source community strives to:
+- **Be friendly and patient**.
+- **Be welcoming**: We strive to be a community that welcomes and supports people of all
+backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
+- **Be considerate**: Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we're a world-wide community, so you might not be communicating in someone else's primary language.
+- **Be respectful**: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one.
+- **Be careful in the words that we choose**: We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable.
+- **Try to understand why we disagree**: Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Remember that we’re all different people. The strength of our community comes from its diversity, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
+
+### Definitions
+Harassment includes, but is not limited to:
+- Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neuro(a)typicality, physical appearance, body size, race, age, regional discrimination, political or religious affiliation
+- Unwelcome comments regarding a person’s lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment
+- Deliberate misgendering. This includes deadnaming or persistently using a pronoun that does not correctly reflect a person's gender identity. You must address people by the name they give you when not addressing them by their username or handle
+- Physical contact and simulated physical contact (eg, textual descriptions like “hug” or “backrub”) without consent or after a request to stop
+- Threats of violence, both physical and psychological
+- Incitement of violence towards any individual, including encouraging a person to commit suicide
+or to engage in self-harm
+- Deliberate intimidation
+- Stalking or following
+- Harassing photography or recording, including logging online activity for harassment purposes
+- Sustained disruption of discussion
+- Unwelcome sexual attention, including gratuitous or off-topic sexual images or behaviour
+- Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of
+intimacy with others
+- Continued one-on-one communication after requests to cease
+- Deliberate “outing” of any aspect of a person’s identity without their consent except as necessary
+to protect others from intentional abuse
+- Publication of non-harassing private communication
+
+Our open source community prioritizes marginalized people’s safety over privileged people’s comfort. We will not act on complaints regarding:
+- ‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’
+- Reasonable communication of boundaries, such as “leave me alone,” “go away,” or “I’m not
+discussing this with you”
+- Refusal to explain or debate social justice concepts
+- Communicating in a ‘tone’ you don’t find congenial
+- Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptions
+
+### Diversity Statement
+We encourage everyone to participate and are committed to building a community for all. Although we will fail at times, we seek to treat everyone both as fairly and equally as possible. Whenever a participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong.
+
+Although this list cannot be exhaustive, we explicitly honor diversity in age, gender, gender identity or expression, culture, ethnicity, language, national origin, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, and technical ability. We will not tolerate discrimination based on any of the protected characteristics above, including participants with disabilities.
+
+### Reporting Issues
+If you experience or witness unacceptable behavior—or have any other concerns—please report it by contacting us at opensource@aexp.com. All reports will be handled with discretion. In your report please include:
+- Your contact information.
+- Names (real, nicknames, or pseudonyms) of any individuals involved. If there are additional
+witnesses, please include them as well. Your account of what occurred, and if you believe the incident is ongoing. If there is a publicly available record (e.g. a mailing list archive or a public IRC logger), please include a link.
+- Any additional information that may be helpful.
+
+After filing a report, a representative of our community will contact you personally, review the incident, follow up with any additional questions, and make a decision as to how to respond. If the person who is harassing you is part of the response team, they will recuse themselves from handling your incident. If the complaint originates from a member of the response team, it will be handled by a different member of the response team. We will respect confidentiality requests for the purpose of protecting victims of abuse.
+
+### Removal of Posts
+We will not review every comment or post, but we reserve the right to remove any that violates these Guidelines or that, in our sole discretion, we otherwise consider objectionable and we may ban offenders from our community.
+
+### Suspension/Termination/Reporting to Authority
+In certain instances, we may suspend, terminate or ban certain repeat offenders and/or those committing significant violations of these Guidelines. When appropriate, we may also, on our own or as required by the GitHub terms of use, be required to refer and/or work with GitHub and/or the appropriate authorities to review and/or pursue certain violations.
+
+### Attribution & Acknowledgements
+These Guidelines have been adapted from the [Code of Conduct of the TODO group](http://todogroup.org/opencodeofconduct/). They are subject to revision by American Express and may be revised from time to time.
+
+Thank you for your participation!

CONTRIBUTING.md

@@ -0,0 +1,147 @@
+# Contributing
+
+The following guidelines must be followed by all contributors to this repository. Please review them carefully and do not hesitate to ask for help.
+
+### Code of Conduct
+This project adheres to the [American Express Community Guidelines](./CODE_OF_CONDUCT.md). By participating, you are expected to honor these guidelines.
+
+### Submission Guidelines
+
+* Review and test your code before submitting a pull request.
+* Be clear and concise when documenting code; focus on value.
+* Don't commit commented code to the main repo (stash locally, if needed).
+
+### Git Commit Guidelines
+
+We follow precise rules for git commit message formatting. These rules make it easier to review commit logs and improve contextual understanding of code changes. This also allows us to auto-generate the CHANGELOG from commit messages.
+
+Each commit message consists of a **header**, **body** and **footer**.
+
+#### Header
+
+The header is required and must not exceed 70 characters to ensure it is well-formatted in common git tools. It has a special format that includes a *type*, *scope* and *subject*:
+
+Syntax:
+
+```bash
+<type>(<scope>): <subject>
+```
+
+#### Type
+
+The *type* should always be lowercase as shown below.
+
+##### Allowed `<type>` values:
+
+* **feat** (new feature for the user)
+* **fix** (bug fix for the user, not a fix to build scripts)
+* **docs** (changes to documentation)
+* **style** (formatting, missing semi colons, etc; no functional code change)
+* **refactor** (refactoring production code, eg. renaming a variable)
+* **test** (adding missing tests, refactoring tests; no production code change)
+* **chore** (updating build/env/packages, etc; no production code change)
+
+#### Scope
+
+The *scope* describes the affected code. The descriptor may be a route, component, feature, utility, etc. It should be one word or camelCased, if needed:
+
+```bash
+feat(transactions): added column for quantity
+feat(BalanceModule): initial setup
+```
+
+The commit headers above work well if the commit affects many parts of a larger feature. If changes are more specific, it may be too broad. To better clarify specific scopes, you should use a `feature/scope` syntax:
+
+```bash
+fix(transaction/details): missing quantity field
+```
+
+The above syntax helps reduce verbosity in the _subject_. In comparison, consider the following example:
+
+```bash
+fix(transaction): missing quantity field in txn details
+```
+
+Another scenario for scope is using a `route/scope` (or `context/scope`) syntax. This would be useful when a commit only affects a particular instance of code that is used in multiple places.
+
+*Example*: Transactions may be shown in multiple routes/contexts, but a bug affecting transaction actions may only exist under the "home" route, possibly related to other code. In such cases, you could use the following format:
+
+```bash
+fix(home/transactions): txn actions not working
+```
+
+This header makes it clear that the fix is limited in scope to transactions within the home route/context.
+
+#### Subject
+
+Short summary of the commit. Avoid redundancy and simplify wording in ways that do not compromise understanding.
+
+Good:
+
+```bash
+$ git commit -m "fix(nav/link): incorrect URL for Travel"
+```
+
+Bad:
+
+```bash
+$ git commit -m "fix(nav): incorrect URL for Travel nav item :P"
+```
+
+> Note that the _Bad_ example results in a longer commit header. This is partly attributed to the scope not being more specific and personal expression tacked on the end.
+
+**Note regarding subjects for bug fixes:**
+
+Summarize _what is fixed_, rather than stating that it _is_ fixed. The _type_ ("fix") already specifies the state of the issue.
+
+For example, don't do:
+
+```bash
+$ git commit -m "fix(nav): corrected Travel URL"
+```
+
+Instead, do:
+
+```bash
+$ git commit -m "fix(nav): broken URL for Travel"
+```
+
+
+#### Body and Footer (optional)
+
+The body and footer should wrap at 80 characters.
+
+The **body** describes the commit in more detail and should not be more than 1 paragraph (3-5 sentences). Details are important, but too much verbosity can inhibit understanding and productivity -- keep it clear and concise.
+
+The **footer** should only reference Pull Requests or Issues associated with the commit.
+
+For bug fixes that address open issues, the footer should be formatted like so:
+
+```bash
+Closes #17, #26
+```
+and for Pull Requests, use the format:
+
+```bash
+Related #37
+```
+
+If a commit is associated with issues and pull requests, use the following format:
+
+```bash
+Closes #17, #26
+Related #37
+```
+> Issues should always be referenced before pull requests, as shown above.
+
+#### Piecing It All Together
+
+Below is an example of a full commit message that includes a header, body and footer:
+
+```bash
+refactor(nav/item): added prop (isActive)
+
+NavItem now supports an "isActive" property. This property is used to control the styling of active navigation links.
+
+Closes #21
+```