allgood2386 · paoga87 · Dec 17, 2019 · Dec 17, 2019 · Dec 17, 2019 · Dec 17, 2019
diff --git a/CODEOWNERS b/CODEOWNERS
@@ -2,10 +2,8 @@
 # Each line is a file pattern followed by one or more owners.
 # Order is important. The last matching pattern has the most precedence.
 
-# These owners will be the default owners for everything in the repo.
-# * @Bixal/@todo-team
-
 # These will automatically assign PRs that touch files in these directories to their respective teams for review.
-docs/00-engineering/* @Bixal/@todo-team  @Bixal/docs
-docs/01-security/* @Bixal/@todo-team  @Bixal/docs
-docs/02-help-desk/* @Bixal/@todo-team  @Bixal/docs
+# @todo test ownership and mappings
+# docs/00-engineering/* @Bixal/@Development @Bixal/docs
+# docs/01-security/* @Bixal/@Security  @Bixal/docs
+# docs/02-help-desk/* @Bixal/@ITOperations  @Bixal/docs
diff --git a/README.md b/README.md
@@ -4,7 +4,7 @@ This Techbook has been prepared to describe Bixal Soulutions philosophy, working
 
 ## This is not really the README you are looking for.
 
-The main techbook README is located at [docs/README.md](docs/README.md), which gets synced to readthedocs at <https://bixal-techbook.bixal.com/en/latest/README/>
+The main techbook README is located at [docs/README.md](docs/README.md), which gets synced to readthedocs at <https://techbook.bixal.com/en/latest/README/>
 
 ## Bixal Solutions, Inc.
 

diff --git a/docs/00-engineering/JavaScript/npm.md b/docs/00-engineering/JavaScript/npm.md
diff --git a/docs/00-engineering/Php/composer.md b/docs/00-engineering/Php/composer.md
@@ -0,0 +1,7 @@
+# Composer
+
+Composer is the depenency manager of choice for most Php projects at Bixal and in the general Php community. You can find general information on Composer and usage at their [documentation](https://getcomposer.org/doc/) page.
+
+## Composer at Bixal
+
+Most projects at Bixal will include some standardized way to manage php dependencies using composer, and ensuring you are installing the correct version of depenencies. Because projects recieve various levels of support, they may be running php 7.2, 7.3, or 7.4. If you install composer locally this leads to a lot of php shim usage, and version switching. While this is possible, it tends to lead to mistakes. Bixal usually provides some sort of [automated command](https://github.com/Bixal/drupal-project/blob/8.x/Makefile#L54), which uses a reference .env file to ensure all versions installed, or updated are using the correct version of php.
diff --git a/docs/00-engineering/Php/drupal.md b/docs/00-engineering/Php/drupal.md
diff --git a/docs/00-engineering/README.md b/docs/00-engineering/README.md
@@ -4,22 +4,6 @@
 
 ## Biweekly Engineering Call
 
-Every two weeks we hold a one hour meeting for the whole engineering team. We have a [git repository on our self-host GitLab](https://git.civicactions.net/civicactions/engineering-call) for documentation and notes about the calls.
+Every two weeks we hold a one hour meeting for the whole engineering team.
 
-Ordinarily, the facilitator for the meeting is rotated through the list of engineers alphabetically by first name. The tasks of the facilitator is described below:
-
-### Facilitator: Before the Engineering Call
-
-* Set the agenda for the call. Typically we have been doing a [festivus](https://en.wikipedia.org/wiki/Festivus) style agenda, which is simply: 1. One or more Feasts (a discussion, a demo, a presentation), 2. General time of sharing our *Feats of Strength*, and *Airing of Grievances*. Feel free to experiment with a different agenda entirely.
-* Make sure that one or more persons is ready to lead us in a feast, or in some way make use of our time together. This can be done via slack emoji voting.
-* Several minutes before the call, remind the team that the call is about to start.
-
-### Facilitator: During the Engineering Call
-
-Describe the agenda and start the meeting. Keep track of the time and try to either encourage more discussion or wrap things up depending on the time remaining.
-
-### Facilitator: After the Engineering Call
-
-* Inform the next person in the [schedule](https://git.civicactions.net/civicactions/engineering-call/blob/master/schedule.md) that they are responsible to be the facilitator for the next engineering call. If that person is unable to lead the next call, then they are responsible to ask the next person on the list. If that person is not responding (on vacation, etc) then you are responsible to ask the next person on the list.
-* Record the topic in our engineering-call git repository README.md file under "Past Feasts" (ask @daven for help if needed): <https://git.civicactions.net/civicactions/engineering-call>
-* Add any other things to the git repo as you feel is appropriate.
+An agenda is laid out each week along with time to bring up technology related items.
diff --git a/docs/00-engineering/accessibility.md b/docs/00-engineering/accessibility.md
@@ -25,35 +25,35 @@ We implement 508 and WCAG compliant websites so that people with all types of di
 * Form buttons should have descriptive values.
 * Color should not be used as the sole method of conveying content or distinguishing visual elements.
 * Color alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.
-*   The page should be readable and functional when the text size is doubled. We need to use rem font-sizing to make the text scales as expected when the web-page is zoomed-in. Also provides reliable text-resizing in smaller browser widths.
-*   Need to have adequate line spacing (at least 1/2 the height of the text) and paragraph spacing (1.5 times line spacing).
+* The page should be readable and functional when the text size is doubled. We need to use rem font-sizing to make the text scales as expected when the web-page is zoomed-in. Also provides reliable text-resizing in smaller browser widths.
+* Need to have adequate line spacing (at least 1/2 the height of the text) and paragraph spacing (1.5 times line spacing).
 
 ## Making Accessible Links
 
-*   Don't use the word "link" in your links or the term "click here".
-*   Don't capitalize links: Some screenreaders read capitalized text letter by letter.
-*   Avoid ASCII characters. Text alternatives are recommended for ASCII smiley faces. If a link involves dashes (17 - 18 years), it is better to replace the hyphen with "to". Screen-readers do not read ASCII characters.
-*   Avoid using URLs as link text. Screenreaders read URL's letter by letter. Use descriptive link text.
-*   Keep link text concise.
-*   Generally, restrict the number of text links on a page. An exception to this rule is pagination/alphabetized links and these should include further contextual information/link text.
-*   Be aware of pagination and alphabetized links: To make pagination links accessible, add text like "Go to page  1 | 2 | 3 .." before the pagination links. For alphabetized links (eg. glossary links), add a descriptive title before the links. See attached screenshot.
-*   Always alert the user when opening new windows. It is important to alert visually-challenged users that a new window has been opened. The best way to indicate that a link opens in a new window is to add text to the link, such as "(opens in new window)".
-*   Be mindful when using anchor links. Adding descriptive text like Jump to.. or On this page will help indicate that the link is within the same page.
-*   Further reading: <https://www.sitepoint.com/15-rules-making-accessible-links/>
+* Don't use the word "link" in your links or the term "click here".
+* Don't capitalize links: Some screenreaders read capitalized text letter by letter.
+* Avoid ASCII characters. Text alternatives are recommended for ASCII smiley faces. If a link involves dashes (17 - 18 years), it is better to replace the hyphen with "to". Screen-readers do not read ASCII characters.
+* Avoid using URLs as link text. Screenreaders read URL's letter by letter. Use descriptive link text.
+* Keep link text concise.
+* Generally, restrict the number of text links on a page. An exception to this rule is pagination/alphabetized links and these should include further contextual information/link text.
+* Be aware of pagination and alphabetized links: To make pagination links accessible, add text like "Go to page  1 | 2 | 3 .." before the pagination links. For alphabetized links (eg. glossary links), add a descriptive title before the links. See attached screenshot.
+* Always alert the user when opening new windows. It is important to alert visually-challenged users that a new window has been opened. The best way to indicate that a link opens in a new window is to add text to the link, such as "(opens in new window)".
+* Be mindful when using anchor links. Adding descriptive text like Jump to.. or On this page will help indicate that the link is within the same page.
+* Further reading: <https://www.sitepoint.com/15-rules-making-accessible-links/>
 
 ## Accessibility Tools
 
 Extensions for testing accessibility:
 
-*   [WAVE Evaluation Tool](https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh)
-*   [Color Contrast Analyzer](https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll)
-*   [Luminosity ratio analyzer](https://chrome.google.com/webstore/detail/wcag-luminosity-contrast/lllpnmpooomecmbmijbmbikaacgfdagi)
+* [WAVE Evaluation Tool](https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh)
+* [Color Contrast Analyzer](https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll)
+* [Luminosity ratio analyzer](https://chrome.google.com/webstore/detail/wcag-luminosity-contrast/lllpnmpooomecmbmijbmbikaacgfdagi)
 
 ## Resources
 
-*   [Drupal Accessibility Guidelines](https://drupal.org/node/1637990)
-*   [WCAG](http://www.w3.org/WAI/intro/wcag)
-*   [WAVE toolbar](http://wave.webaim.org/toolbar/)
-*   [Color Contrast Analyzer Chrome Extension](https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll)
-*   [Luminosity ratio analyzer Chrome Extension](https://chrome.google.com/webstore/detail/wcag-luminosity-contrast/lllpnmpooomecmbmijbmbikaacgfdagi)
-*   [Comprehensive guide for making Accessible Links](https://www.sitepoint.com/15-rules-making-accessible-links/)
+* [Drupal Accessibility Guidelines](https://drupal.org/node/1637990)
+* [WCAG](http://www.w3.org/WAI/intro/wcag)
+* [WAVE toolbar](http://wave.webaim.org/toolbar/)
+* [Color Contrast Analyzer Chrome Extension](https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll)
+* [Luminosity ratio analyzer Chrome Extension](https://chrome.google.com/webstore/detail/wcag-luminosity-contrast/lllpnmpooomecmbmijbmbikaacgfdagi)
+* [Comprehensive guide for making Accessible Links](https://www.sitepoint.com/15-rules-making-accessible-links/)
diff --git a/docs/00-engineering/application-standards.md b/docs/00-engineering/application-standards.md
@@ -0,0 +1,32 @@
+# Application Standards
+
+## 12 Factor Application
+
+Tldr; An application which can **EASILY** be run in a ephemeral (cattle, not pets) manner.
+
+* Use declarative formats for setup automation, to minimize time and cost for new developers joining the project.
+* Have a clean contract with the underlying operating system, offering maximum portability between execution environments.
+* Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration.
+* Minimize divergence between development and production, enabling continuous deployment for maximum agility.
+* And can scale up without significant changes to tooling, architecture, or development practices.
+
+The entirety of the document can and should be read at [https://12factor.net/](12factor.net)
+
+## Coding Standards
+
+* We follow established best practices so we can easily work with each others code, and contribute back.
+* We don't hard code
+* We stand behind the YAGNI (You ain't gonna need it) philosophy and avoid "gold plating."
+  * When writing code, our code should solve ONLY and EXACTLY the use case that we are trying to support. In many instances we have a desired to make things MORE FLEXIBLE for the FUTURE but that is code we will have to support without knowing whether any of those use cases will ever come up.
+  Another big reason for wanting to be FLEXIBLE is that refactoring is hard, and feels easier to have flexibility at front, but that is why we write automattests, so refactoring will not be as painful.
+
+## Debugging
+
+* When debugging, we double check for false positives. We alway cross check a positive result in case that positive result is the ONLY result, instead of one of many possible results.
+* We validate assumptions, so that we work on the right thing.
+  * Am I assuming this is a browser/presentation issue?
+  * Am I assuming this is a network issue?
+  * Am I assuming this is a Header Iss
+  * Am I assuming this is an issue with a specific module?
+* When we get 400 or 500 responses, we check the logs under Docker Compose logs.
+* We use browser like Chrome dev console or Firebug tools to identify JS and server issues so that we don't miss issues between the browser and Drupal.