[RT-391] add adr documentation (#12)

* [RT-391] add adr documentation

* imp

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @sequra/risk-tech

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,49 +1,57 @@
-✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
 ✂✂✂  REMOVE FROM THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
-✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
 
 Here are some friendly reminders before submitting your pull request:
 
 - There should be an issue describing the motivation for this change.
 - Everything should be well tested.
-- Check that you are not making any intensive/slow queries
+- Check that you are not making any intensive/slow queries (provide db explain if necessary).
+- Migrations should be safe https://sequra.atlassian.net/wiki/display/EN/Safe+Operations+For+High+Volume+PostgreSQL
 
 YOU CAN REMOVE THE PARTS OF THE TEMPLATE THAT DO NOT APPLY TO YOUR PULL REQUEST
 
-✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
 ✂✂✂  REMOVE UP TO THIS PART BEFORE SUBMITTING YOUR PULL REQUEST ✂✂✂
-✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
+✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂✂
 
- ### What is the goal?
+### What is the goal?
 
 _Provide a description of the overall goal (you can usually use the one from the issue)_
 
- ### References
-* **Issue:** _issue goes here, if suggesting a new feature or change, please discuss it in an issue first_
+### References
+* **Issue:** _jira issue goes here, if suggesting a new feature or change, please discuss it in an issue first_
 * **Related pull-requests:** _list of related pull-requests (comma-separated): #1, #2_
 * **Honeybadger errors:** _list of links to Honeybadger errors (comma-separated): link1, link2_
+* **Any other references (AppSignal, Prometheus, ...):** _list of links to other references (comma-separated): link1, link2_
 
- ### Definition of done
-
-1. [ ] _Point 1_
-1. [ ] _Point 2_
-
- ### How is it being implemented?
+### How is it being implemented?
 
 _Provide a description of the implementation_
 
- ### Opportunistic refactorings
+### Opportunistic refactorings
 
 _Have you improved the code/app in anyway? Explain what you did._
 
- ### Caveats
+### Caveats
 
 _If you find any, please describe all the special conditions._
 
- ### How is it tested?
+### Does it affect (changes or update) any sensitive data?
+
+_Check [Sensitive data list documentation](../blob/master/docs/sensitive_data/README.md) and [Sensitive data list](../blob/master/docs/sensitive_data/sensitive-data.yml)
+
+### How is it tested?
 
 _Automatic tests? Manual tests?_
 
 _If it cannot be tested explain why._
 
 _Add use cases if specs are incomplete or missing._
+
+### How is it going to be deployed?
+
+_If it does not require anything special, just write "Standard deployment". Otherwise, put the required steps._
+
+- [ ] _Step 1_
+- [ ] _Step 2_

README.md

@@ -1,7 +1,16 @@
 # Factiva-api-client
 
+## 📖 Overview 📖
+
 This gem integrates your ruby app with [Dow Jones Risk & Compliance API](https://developer.dowjones.com/site/docs/risk_and_compliance_apis/risk_and_compliance_2_0/index.gsp)
 
+### 🔌 System dependencies 🔌
+
+* `docker`
+* `docker-compose`
+
+## 👩‍💻 Development environment instructions 👩‍💻
+
 ## Installation
 
 Add this line to your application's Gemfile:
@@ -49,8 +58,9 @@ Search the Dow Jones RiskCenter database for risk entities.
 The response will return an array of json formatted `RiskEntities`.
 
 Method parameters:
+
 | parameter   | type    | required |
-| ----------- | ------- | -------- |
+|-------------|---------|----------|
 | first_name  | string  | true     |
 | last_name   | string  | true     |
 | birth_date  | Date    | false    |
@@ -119,13 +129,21 @@ Factiva::Request.profile("11266381")
 => {"data"=>{"attributes"=>{"basic"=>{"type"=>"Person", "name_details"=>{"primary_...
 ```
 
+## 🚧 How to run the test suite 🚧
+
+You can start the development environment with:
+```
+docker-compose run dev sh
+```
+And run specs with:
+```
+docker-compose run dev bundle exec rspec
+```
 
 ## Contributing
 
 All contributions are welcome, feel free to create a Pull request.
 
-You can start the development environment with `docker-compose run dev sh` and run specs with `docker-compose run dev bundle exec rspec`
-
 In case you want to use the gem in our of our application from your local code, you can do the following:
 
 * Add a new volume in the Rails application's docker-compose with `~/${PATH_TO_THE_GEM}:/app/vendor/gems/factiva-api-client`

docs/decisions/README.md

@@ -0,0 +1,4 @@
+# Architectural design records
+The idea is to provide a basic integrated ADR generation for Factiva API client
+- You can see an [index of ADRs here](./index.md)
+- You can see the [base template here](./template.md)

docs/decisions/index.md

@@ -0,0 +1,5 @@
+# Architectural Decision Log
+
+This log lists the architectural decisions for Factiva API client.
+
+For new ADRs, please use [template.md](template.md) as basis.

docs/decisions/template.md

@@ -0,0 +1,102 @@
+✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
+# ⚠️ Should this be an ADR?
+Are you in doubt if this document you or your team propose needs to be an Architectural Decision Record?
+
+Let's check it through several questions 😊
+
+Starting with a `stop question`:
+
+* ❓ Is this ADR related to a change in this specific application or service?
+  ✋ **If** the answer **is "no"**, which means that this ADR affects this application and others, **end this document here** and start writing a general Decision Record [here](https://sequra.atlassian.net/wiki/spaces/EN/pages/3771039771/Tech+Decision+Records#List-of-Tech-Decision-Records)
+  👇 **If** the previous **answer is a "yes"**
+
+Let's **continue** with these other questions:
+
+* ❓ Will this ADR provoke a breaking changes or sensible modifications inside this application or services' engine, interfaces, APIs or [seams](https://archive.org/details/working-effectively-with-legacy-code/page/n51/mode/2up) `(look into chapter 4 of this book for the reference)` between domains?
+* ❓ Will this ADR introduce new architectural or software design patterns in the project (f.ex: big refactors which provide that an old feature can work in a new way, introducing a new technology/gem/package/etc ...)
+* ❓ Will this ADR impact other teams’ roadmaps or velocities meaningfully?
+* ❓ Does this ADR imply different approaches/options for which you want/need the opinion of the rest of the team?
+* ❓ Does this ADR modify/impact another existing or very similar ADR (superseeding or refining it)?
+
+Then, evaluate your answers:
+
+* 👉  If you checked any of those boxes, this topic does need an ADR.
+* 👉  If you didn’t check any of those boxes, doing an ADR is optional.
+
+**❗  Depending on your decision, either delete this section or delete this document!**
+
+✂✂✂✂✂< REMOVE FROM THIS PART BEFORE SUBMITTING YOUR ADR ✂✂✂✂✂
+
+# [short title of solved problem and solution]
+
+---
+* **Status:** [🚧🌱 wip | 💡 proposed | 🚫 rejected | ✅ accepted | 🕸 deprecated | … | ⬆️🌱 superseded by [ADR-0005](0005-example.md)] <!-- optional -->
+* **Deciders:** [list everyone involved in the decision] <!-- optional -->
+* **Proposal date:** [YYYY-MM-DD when the decision was proposed] <!-- optional -->
+* **Due date:** [YYYY-MM-DD when the decision is finally made] <!-- optional -->
+* **Technical Story:** [description | ticket/issue URL] <!-- optional -->
+---
+## Context and Problem Statement
+
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+
+## Decision Drivers <!-- optional -->
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3]
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+
+### Positive Consequences <!-- optional -->
+
+* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
+* …
+
+### Negative Consequences <!-- optional -->
+
+* [e.g., compromising quality attribute, follow-up decisions required, …]
+* …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### [option 1]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 2]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->