docs/basics/community.md

 # CiviCRM Developer Community
 
-Developers from around the globe use the following systems to communicate and
-collaborate:
+## Collaboration tools
+
+Developers from around the globe use the following systems to communicate and collaborate:
 
 -   [CiviCRM.org](https://civicrm.org)
     -   [Extensions](https://civicrm.org/extensions) publishing
     -   [Blog posts](https://civicrm.org/blog/) are written by both the CiviCRM core team and other community members, and cover a wide range of topics. Subscribe to the [RSS feed](https://civicrm.org/blog/feed) to make sure you stay up to date.
-    -   [Events](https://civicrm.org/events) -
-        meetups, conferences, camps, sprints, webinars
+    -   [Events](https://civicrm.org/events) - meetups, conferences, camps, sprints, webinars
     -   [Job Board](https://civicrm.org/jobs) - Post and find paid work
--   [Documentation](https://civicrm.org/documentation) including:
-    -   [User Guide](https://docs.civicrm.org/user/en/stable/)
-    -   [Developer Guide](https://docs.civicrm.org/dev/en/master/)
-        *(that you're reading now!)*
--   [Mattermost](https://chat.civicrm.org) offers live discussion in chat rooms and direct messages. It's a great place to go for any technical questions. Here, with a bit of luck, you'll often find an instant answer to your question or a pointer in the right direction. Definitely go here if you feel like you are banging your head against a wall.
--   [StackExchange](http://civicrm.stackexchange.com/) - Question & answer site covering a range of topics relevant to developers and users. It is a great place to find answers to the millions of questions that have already been asked about CiviCRM, and to ask ones that haven't been asked already.
--   [Jira](https://issues.civicrm.org/jira) - Issue tracking
+-   [Documentation](https://docs.civicrm.org)
+-   [Mattermost](https://chat.civicrm.org) offers live discussion in chat rooms and direct messages. It's a great place to go for any technical questions. Here, with a bit of luck, you'll often find an instant answer to your question or a pointer in the right direction. Definitely go here if you feel like you are banging your head against a wall. New developers can check out the [dev-newcomers](https://chat.civicrm.org/civicrm/channels/dev-newcomers) channel for discussion on getting started with developing for CiviCRM.
+-   [Stack Exchange](http://civicrm.stackexchange.com/) - Question & answer site covering a range of topics relevant to developers and users. It is a great place to find answers to the millions of questions that have already been asked about CiviCRM, and to ask ones that haven't been asked already.
+-   [GitLab](https://lab.civicrm.org) - CiviCRM's tool for issue tracking community-based project management.
 -   [GitHub](https://github.com/civicrm) - Hosted git repositories for the entire CiviCRM codebase, as well as many smaller tools focused on developing CiviCRM.
--   [Discussion Mailing Lists](https://lists.civicrm.org/lists/)
--   [Newsletters](https://civicrm.org/civicrm/mailing/subscribe)
--   Falling out of use
-    -   [Wiki] - still used for specs & recipes, *but documentation
-        [is moving][migration] to the guides listed above*
-    -   [IRC](http://irc.civicrm.org/) - #civicrm on irc.freenode.net
-        *but now mostly replaced by Mattermost*
-    -   [Forum](https://forum.civicrm.org/) - *now mostly replaced by
-        StackExchange*
-
-[wiki]: https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Documentation
-[migration]: https://wiki.civicrm.org/confluence/display/CRMDOC/Content+migration+from+wiki+to+Developer+Guide
-
-The developer community is full of friendly people, eager to welcome newcomers.
-Mattermost and in-person events are great starting points if you're looking to
-get involved!
 
+!!! tip "Before you begin"
+
+    Register for the accounts below. *All accounts require e-mail verification.*
+
+    1.  [CiviCRM.org](https://civicrm.org/user/register) - Be prepared to give your name and organizational affiliation, and explain your role in the community.
+        *Account requests must be approved by an administrator before you will be granted access.* This process may take some time.
+
+        The following communities provide a single sign-on once your CiviCRM.org account is approved.
+
+         -   GitLab
+
+    2.  [Mattermost](https://chat.civicrm.org/signup_email) - Create an account and join a team on this open-source version of Slack.
+
+    3.  [Stack Exchange](https://civicrm.stackexchange.com/users/signup?ssrc=head&returnurl=https%3a%2f%2fcivicrm.stackexchange.com%2f) - Read the user guide after joining. Write your own Q&A and vote on others'.
+
+    4.  [GitHub](https://github.com/join?source=header) - Find repositories under CiviCRM's group after confirming your account.
+    
+!!! warning "Don't include a space in your username"
+
+    CiviCRM.org allows spaces in usernames but this won't work with GitLab.  So it's best if you don't use any spaces in your CiviCRM.org username. 
+    
+    If you have already set up an account on CiviCRM.org you can easily log in and change your username.
+
+## Discussion communities
+
+Optional lists you may also want to register for:
+
+-   [Newsletters](https://civicrm.org/civicrm/mailing/subscribe) (after your CiviCRM account is active)
+
+## Falling out of use
+
+-   [CiviCRM Groups](https://lists.civicrm.org/lists/firstpasswd/) - (listservs)   *but now mostly replaced by Mattermost*
+
+## Out of use
+
+-   [IRC](http://irc.civicrm.org/) - #civicrm on irc.freenode.net *No longer officially supported by the CiviCRM organization, and functionally replaced by Mattermost*
+
+-   [Wiki](https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Documentation) - *Archived in November 2017, but still useful for some older documentation. Developer and admin docs have been moved to [MkDocs](https://docs.civicrm.org/). Other documentation should be moved to their respective [Gitlab wiki spaces](https://lab.civicrm.org/explore/groups).*
+
+-   [Forum](https://forum.civicrm.org/) - *Archived on November 25, 2017*
+
+-   [Jira](https://issues.civicrm.org) - *Archived on December 27, 2018. You can still access old (read-only) JIRA issues if you know their issue number and you can also browse the archived issues for a specific project.*
+
+
+The developer community is full of friendly people, eager to welcome newcomers. Mattermost and in-person events are great starting points if you're looking to get involved!

docs/basics/planning.md

@@ -2,110 +2,59 @@
 
 ## Community input
 
-Before you start on any code to extend CiviCRM, it is really important
-to discuss your ideas with the community. Here are a few of the reasons
-why this is a good idea:
-
--   It may have been done already
--   You'll get suggestions and advice on suitable ways to approach the
-    problem
--   Other people will know what you are doing, and be able to contact
-    you if they want to collaborate
-
-A typical pre-development workflow will start with a discussion on
-[Mattermost](https://chat.civicrm.org/) (in the Developer channel) about what
-you want to do. Here you'll receive feedback from other members of the
-community and core team about your ideas. You might be lucky and find
-out that there is a already a way to do what you want using the user
-interface (and that no coding is necessary). Or it might be that someone
-has done something similar already and all that is required is a few
-tweaks to their code.
+Before you start on any code to extend CiviCRM, it is really important to discuss your ideas with the community. Here are a few of the reasons why this is a good idea:
 
+-   It may have been done already.
+-   You'll get suggestions and advice on suitable ways to approach the problem.
+-   Other people will know what you are doing, and be able to contact you if they want to collaborate.
+
+A typical pre-development workflow will start with a discussion on [Mattermost](https://chat.civicrm.org/) (in the Developer channel) about what you want to do. Here you'll receive feedback from other members of the community and core team about your ideas. You might be lucky and find out that there is a already a way to do what you want using the user interface (and that no coding is necessary). Or it might be that someone has done something similar already and all that is required is a few tweaks to their code.
 
 ## Requirements and specifications
 
-If and when you have confirmed that some coding is required, it is good
-practice, even for relatively small projects, to write
-
--   a requirements document which describes in detail what you want the
-    finished code to do
--   a specification that outlines how you are going to meet these
-    requirements with CiviCRM
-
-The requirements are typically written to be understandable to end
-users, and the specification can be thought of as a translation of those
-requirements into the language of CiviCRM. Both requirements and
-specification should go on the
-[wiki](http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Wiki).
-
-Once you've written the requirements and specification document, you
-should go about soliciting feedback.  Get feedback on the requirements
-from your end users and feedback on the requirements and the
-specification from anyone that is willing to comment. To encourage more
-discussion, you can write a post on CiviCRM's
-[blog](https://civicrm.org/blog/), tweet it out with
-the [#civicrm](https://twitter.com/hashtag/civicrm) hashtag, tell similar
-CiviCRM users and organisations and so on.
-The more feedback you can get the better.
+If and when you have confirmed that some coding is required, it is good practice, even for relatively small projects, to write:
+
+-   a requirements document which describes in detail what you want the finished code to do, and
+-   a specification that outlines how you are going to meet these requirements with CiviCRM.
+
+The requirements are typically written to be understandable to end users, and the specification can be thought of as a translation of those requirements into the language of CiviCRM. 
+
+Store your requirements and specifications in a public location such as:
+
+* a markdown file in your project's repository,
+* a google doc, or 
+* the [CiviCRM wiki](http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Wiki).
+
+Once you've written the requirements and specification document, you should go about soliciting feedback.  Get feedback on the requirements from your end users and feedback on the requirements and the specification from anyone that is willing to comment. To encourage more discussion, you can write a post on CiviCRM's [blog](https://civicrm.org/blog/), tweet it out with the [#civicrm](https://twitter.com/hashtag/civicrm) hashtag, tell similar CiviCRM users and organisations and so on. The more feedback you can get the better.
 
 !!!tip
-    If you get stuck writing your requirements and specification, or would
-    like to get more background, have a look at some
-    [existing requirements and specifications](https://wiki.civicrm.org/confluence/display/CRM/Requirements+and+specifications)
-    from CiviCRM developers.
+    If you get stuck writing your requirements and specification, or would like to get more background, have a look at some [existing requirements and specifications](https://wiki.civicrm.org/confluence/display/CRM/Requirements+and+specifications) from CiviCRM developers.
+
+## Bugs
+
+Before starting work on a bug, your first step should be to check the [issue tracking systems](../tools/issue-tracking.md) for any open issues before creating one yourself or working on a pull request.
+
+In order to reproduce the bug you can reproduce the issue in the appropriate [CiviCRM Sandbox](https://civicrm.org/sandboxes). Enabling debugging can help to get more details.
+
+Make sure to check [the contribution guidelines](../core/contributing.md) for more information on how to create a pull request.
 
 ## Recommendations
 
-**Open a free [GitHub](https://github.com/) account** for revision control.
-The official CiviCRM [repositories](https://github.com/civicrm)
-are housed in `git` repositories on GitHub.  If you use GitHub you will find
-it easy to access the latest source-code, to submit pull requests
-for any patches you create and to collaborate with many other
-CiviCRM developers who also use GitHub.
-
-**Install the [buildkit](https://github.com/civicrm/civicrm-buildkit)**,
-ideally as a [vagrant virtual-machine](https://github.com/civicrm/civicrm-buildkit-vagrant)
-or using one of available `docker` images ([1](https://github.com/progressivetech/docker-civicrm-buildkit),
-[2](https://github.com/ErichBSchulz/dcbk)). The buildkit is not an absolute
-requirement but it is definitely the fastest path to a good development
-experience!
-
-**From the outset, [automate testing](https://wiki.civicrm.org/confluence/display/CRMDOC/Testing)**.
-In the current climate of rapid evolution of not just CiviCRM, but
-also it's myriad of dependancies, automated testing of PHP code with `phpunit`
-and javascript with tools like `karma` and `jasmine` is essential. Start all
-your work by considering how you will provide automated testing for it.
-Starting with the buildkit will make this much simpler for you to set up.
-Getting started with unit-testing may seem daunting and onerous when you start,
-but you will soon come to love the freedom it gives you. If you are
-unsure how to proceed with testing ask the [community](/basics/community).
-
-**Create a native [extension](/extensions/basics)**.
-If you have new functionality to add to CiviCRM, it probably belongs in an
-extension. "Native" extensions will install into all CiviCRM sites
-regardless of the  underlying CMS used (Drupal or Wordpress), making it easy to
-share your extension with the CiviCRM community.
-
-**Use the [API](/api/general) and [hooks](/hook)** to access and manage CiviCRM data in any patch,
-native extension, CMS module, or external program that you
-develop. The API will function as expected with every new release
-and backwards compatibility of the API is maintained for several
-versions of CiviCRM.
-
-**Avoid [hacking the core](/core/hacking)** of CiviCRM unless you understand
-the implications.
-
-**Follow the
-[Coding Standards](https://wiki.civicrm.org/confluence/display/CRMDOC/Coding+Standards)**
-for uniform structure that will make everyone's development work easier.
+**Open a free [GitHub](https://github.com/) account** for version control. The official CiviCRM [repositories](https://github.com/civicrm) are housed in `git` repositories on GitHub.  If you use GitHub you will find it easy to access the latest source-code, to submit pull requests for any patches you create and to collaborate with many other CiviCRM developers who also use GitHub.
+
+**Install the [buildkit](https://github.com/civicrm/civicrm-buildkit)**, ideally as a [vagrant virtual-machine](https://github.com/civicrm/civicrm-buildkit-vagrant) or using one of available `docker` images ([progressivetech](https://github.com/progressivetech/docker-civicrm-buildkit) or [EricBSchulz](https://github.com/ErichBSchulz/dcbk)). The buildkit is not an absolute requirement but it is definitely the fastest path to a good development experience!
+
+**From the outset, [automate testing](../testing/index.md)**. In the current climate of rapid evolution of not just CiviCRM, but also it's myriad of dependencies, automated testing of PHP code with `phpunit` and javascript with tools like `karma` and `jasmine` is essential. Start all your work by considering how you will provide automated testing for it. Starting with the buildkit will make this much simpler for you to set up. Getting started with unit-testing may seem daunting and onerous when you start, but you will soon come to love the freedom it gives you. If you are unsure how to proceed with testing ask the [community](community.md).
+
+**Create a native [extension](../extensions/index.md)**. If you have new functionality to add to CiviCRM, it probably belongs in an extension.  "Native" extensions will install into all CiviCRM sites regardless of the  underlying CMS used (Drupal, WordPress, Joomla or Backdrop), making it easy to share your extension with the CiviCRM community.
+
+**Use the [API](../api/index.md) and [hooks](../hooks/index.md)** to access and manage CiviCRM data in any patch, native extension, CMS module, or external program that you develop. The API will function as expected with every new release and backwards compatibility of the API is maintained for several versions of CiviCRM. 
+
+**Avoid [hacking the core](../core/hacking.md)** of CiviCRM unless you understand the implications.
 
+**Follow the [Coding Standards](../standards/index.md)** for uniform structure that will make everyone's development work easier.
 
 ## Make it happen
 
-If you need or would like extra resources for your code improvement, you
-might consider a [Make It Happen](https://civicrm.org/make-it-happen)
-(aka MIH) campaign, which is a crowd-sourcing initiative for CiviCRM.
-The MIH work is carried out by the
-core team or trusted consultants, and has helped build many amazing new
-features into CiviCRM in recent years.
+If you need or would like extra resources for your code improvement, you might consider a [Make It Happen](https://civicrm.org/make-it-happen) (aka MIH) campaign, which is a crowd-sourcing initiative for CiviCRM. The MIH work is carried out by the core team or trusted consultants, and has helped build many amazing new features into CiviCRM in recent years.
 

docs/basics/requirements.md

+# Development requirements
+
+## Languages and Services
+
+* Required
+    - Unix-like environment (Linux, OS X, or a virtual machine)
+    - [PHP v7.2+](http://php.net/) including the following extensions: `bcmath curl gd gettext imap intl imagick json mbstring openssl pdo_mysql phar posix soap zip`
+    - [MySQL v5.7.5+](http://mysql.com/) or [MariaDB 10.0.2+](https://mariadb.org/), including both client and server
+    - [NodeJS v8+](https://nodejs.org/)
+    - [Git](https://git-scm.com/)
+* Recommended (for `civibuild` / `amp`):
+    - Apache HTTPD v2.2 or v2.4 including the `mod_rewrite` module and, on SUSE, possibly `mod_access_compat` (This list may not be exhaustive.)
+
+Please also see [this Installation Guide page](https://docs.civicrm.org/installation/en/latest/general/requirements/) for more details on server configuration requirements to deploy CiviCRM installations using buildkit.
+
+## Command Line
+
+There are many ways to install MySQL, PHP, and other dependencies -- for example, `apt-get` and `yum` can download packages automatically; `php.net` and `mysql.com` provide standalone installers; and MAMP/XAMPP provide bundled installers.
+
+Civi development should work with most packages -- with a priviso: ***the command-line must support standard command names*** (eg `git`, `php`, `node`, `mysql`, `mysqldump`, etc).
+
+Some environments (e.g. most Linux distributions) are configured properly out-of-the-box. Other environments (e.g. MAMP and XAMPP) may require configuring the `PATH`.
+
+<!-- FIXME: There should be a link about diagnosing/fixing paths for third-party binaries. TLDR: `find / -name php -executable` and then update `PATH` via bashrc/bash_profile/whatever -->
+
+## Buildkit
+
+The developer docs reference a large number of developer tools, such as `drush` (the Drupal command line), `civix` (the CiviCRM code-generator), and `karma` (the Javascript tester).
+
+Many of these tools are commonly used by web developers, so you may have already installed a few.  You could install all the tools individually -- but that takes a lot of work.
+
+[civicrm-buildkit](../tools/buildkit.md) provides a script which downloads the full collection.

docs/basics/skills.md

-# Prerequisite skills
+# Useful skills
 
 ## Learn how to *use* CiviCRM
 
-Before diving into CiviCRM development, it's worth mentioning that a solid
-understanding of CiviCRM from the *user's* perspective can really help. You
-pick up the standard user interface patterns that you can re-use in your work,
-and you might even realise that the UI already provides the functionality you
-wish to develop. To that end, please see the
-[User Guide](https://docs.civicrm.org/user/en/stable/).
-
+Before diving into CiviCRM development, it's worth mentioning that a solid understanding of CiviCRM from the *user's* perspective can really help. You pick up the standard user interface patterns that you can re-use in your work, and you might even realise that the UI already provides the functionality you wish to develop. To that end, please see the [User Guide](https://docs.civicrm.org/user/en/stable/).
 
 ## Learn these developer skills
 
-Below we've outlined the major technologies that CiviCRM is built with.
-You don't need to be a pro at everything listed here to get started, but it's
-useful to understand at least of couple of them well, and have a basic
-understanding of how they fit together to create CiviCRM.
+Below we've outlined the major technologies that CiviCRM is built with. You don't need to be a pro at everything listed here to get started, but it's useful to understand at least of couple of them well, and have a basic understanding of how they fit together to create CiviCRM.
 
-Technologies which are contained within the CiviCRM project
-(e.g. civix, buildkit) are covered in detail within this guide, but
-other technologies (such as PHP and Git, which are not CiviCRM-specific) are
-outside its scope. As such, this guide assumes that readers
-arrive with a baseline understanding of these developer skills. This page lists
-these prerequisite skills, along with pointers to usher the reader towards
-appropriate resources for closing skills gaps, wherever necessary.
-Items listed towards the top of this list are, generally-speaking, more
-important skills for CiviCRM development, but the specific skills needed to
-accomplishing a particular development goal, certainly vary.
+Technologies which are contained within the CiviCRM project (e.g. civix, buildkit) are covered in detail within this guide, but
+other technologies (such as PHP and Git, which are not CiviCRM-specific) are outside its scope. As such, this guide assumes that readers arrive with a baseline understanding of these developer skills. This page lists these prerequisite skills, along with pointers to usher the reader towards appropriate resources for closing skills gaps, wherever necessary. Items listed towards the top of this list are, generally-speaking, more important skills for CiviCRM development, but the specific skills needed to accomplishing a particular development goal, certainly vary.
 
--   **PHP** - the main programming language in which CiviCRM is written
+-   **PHP** - the main programming language in which CiviCRM is written.
     -   [Language reference](http://php.net/manual/en/langref.php)
--   **Git** - a version control system for tracking changes to source code
-    -   [Official documentation](https://git-scm.com/documentation)
-    -   [15 minute interactive tutorial](https://try.github.io/levels/1/challenges/1)
--   **Command line / bash** - in general, "the command line" refers to using a
-    text-only interface to run programs such as `civix`, `git`, and many more.
-    Bash is the most common "shell" program used to execute these commands on
-    Unix computers (i.e. Linux and OS X).
+-   **Git, GitHub, and GitLab** - Git is a version control system for tracking changes to source code. GitHub and GitLab are web-based tools which host git repositories and issue-tracking systems.
+    -   See [our recommended external resources](../tools/git.md#resources)
+-   **Command line / bash** - in general, "the command line" refers to using a text-only interface to run programs such as `civix`, `git`, and many more. Bash is the most common "shell" program used to execute these commands on Unix computers (i.e. Linux and OS X).
     -   [Unix command line tutorial](http://www.ee.surrey.ac.uk/Teaching/Unix/)
-    -   *Microsoft Windows has a command line shell which functions very
-        differently from bash. While developing CiviCRM on Windows is possible,
-        it will be a slightly more uphill battle, for this reason and others.*
--   **Javascript** - another programing language used in CiviCRM, especially
-    for any logic that happens within the web browser. *(Note that "javascript"
-    and "java" are entirely different technologies and should not be confused.)*
+    -   *Microsoft Windows has a command line shell which functions very differently from bash. While developing CiviCRM on Windows is possible, it will be a slightly more uphill battle, for this reason and others.*
+-   **Javascript** - another programing language used in CiviCRM, especially for any logic that happens within the web browser. *(Note that "javascript" and "java" are entirely different technologies and should not be confused.)*
     -   [Javascript tutorial](http://www.w3schools.com/js/default.asp)
--   **jQuery** - a javascript library that makes manipulating elements on a web
-    page easy
+-   **jQuery** - a javascript library that makes manipulating elements on a web page easy.
     -   [jQuery documentation](http://api.jquery.com/)
+-   **AngularJS** - a front-end javascript/html library providing a client-side framework for creating one-page MVC (model-view-controller) and MVVM (model-view-viewmodel) apps.
+    -   [angularJS documentation](https://docs.angularjs.org/)
 -   **HTML** - the markup used so transmit page content to a web browser.
     -   [HTML tutorial](http://www.w3schools.com/html/default.asp)
--   **Smarty** - a "template engine" which allows developers to write an HTML
-    file for one web page, while easily including content dynamically generated
-    from PHP
+-   **Smarty** - a "template engine" which allows developers to write an HTML file for one web page, while easily including content dynamically generated from PHP.
     -   [Smarty documentation](http://www.smarty.net/docs/en/)
--   **CSS** - a programming language used to specify consistent visual style to
-    be applied to many different elements within a web page. Different web
-    browsers interpret the CSS code in slightly different ways.
+-   **CSS** - a programming language used to specify consistent visual style to be applied to many different elements within a web page. Different web browsers interpret the CSS code in slightly different ways.
     -   [CSS tutorial](http://www.w3schools.com/css/default.asp)
-    -   [Can I use](http://caniuse.com/) - good for seeing which web browsers
-        have implemented certain CSS features
-    -   [Comparison of layout engines](https://en.wikipedia.org/wiki/Comparison_of_layout_engines_\(Cascading_Style_Sheets\))
-        another helpful comparison of the differences between web browsers
--   **Drupal / Wordpress / Joomla!** - CiviCRM must be installed within one of
-    these content management systems, and learning more about the underlying
-    CMS will aid CiviCRM development. Drupal is favored by most CiviCRM
-    developers and CiviCRM actually borrows many development practices from
-    the project, so learning Drupal is a good place to start if you are unsure.
+    -   [Can I use](http://caniuse.com/) - good for seeing which web browsers have implemented certain CSS features.
+    -   [Comparison of layout engines](https://en.wikipedia.org/wiki/Comparison_of_layout_engines_\(Cascading_Style_Sheets\)) another helpful comparison of the differences between web browsers.
+-   **Drupal / WordPress / Joomla!** - CiviCRM must be installed within one of these content management systems, and learning more about the underlying CMS will aid CiviCRM development. Drupal is favored by most CiviCRM developers and CiviCRM actually borrows many development practices from the project, so learning Drupal is a good place to start if you are unsure. That said, WordPress is the most popular CMS and it has been so for several years now. 
     -   [Drupal documentation](https://www.drupal.org/docs/)
-    -   [Wordpress documentation]()
-    -   [Joomla documentation]()
--   **SQL / MySQL** - "SQL" is a standardized language used by many different
-    kinds of databases to manipulate data in the database. "MySQL" is one kind
-    of database which CiviCRM uses to store all its data. The query syntax
-    that MySQL uses conforms [almost](http://troels.arvin.dk/db/rdbms/)
-    entirely to the SQL standard, so learning SQL is basically synonymous to
-    learning MySQL.
+    -   [WordPress documentation](https://codex.wordpress.org/Main_Page)
+    -   [Joomla documentation](https://docs.joomla.org/)
+-   **SQL / MySQL** - "SQL" is a standardized language used by many different types of database management systems to manipulate data in the database. "MySQL" is one specific database management system which, by default, CiviCRM uses to store all its data. The query syntax that MySQL uses conforms [almost](http://troels.arvin.dk/db/rdbms/) entirely to the SQL standard, so learning SQL is basically synonymous to learning MySQL.
     -   [SQL tutorial](http://www.w3schools.com/sql/default.asp)
     -   [MySQL statement syntax](http://dev.mysql.com/doc/refman/en/sql-syntax.html)
-    -   [MySQL Workbench](http://www.mysql.com/products/workbench/) -
-        an intuitively designed GUI tool for inspecting and interacting with a
-        MySQL database (great for learning more about the CiviCRM data model).
-
-
+    -   [MySQL Workbench](http://www.mysql.com/products/workbench/) - an intuitively designed GUI tool for inspecting and interacting with a MySQL database (great for learning more about the CiviCRM data model).

docs/build.md

-# Building CiviCRM
-
-TODO:
-
--   Nightlies vs gitify vs civibuild
--   gitify
--   civibuild (https://github.com/civicrm/civicrm-buildkit/blob/master/doc/civibuild.md)

docs/core/contributing.md

+# How to contribute
+
+This chapter assumes that you have identified a bug or improvement for CiviCRM where the best resolution is to [write and contribute code to core](hacking.md).
+
+!!! note
+
+    This chapter will refer to a number of resources that are explained in greater depth in the [Developer Community](../basics/community.md) chapter.
+
+
+## Create an issue
+
+Creating a good issue is an important first step and often involves research, discussion, and thoughtful description.  Identify your "use case" and share the budget and/or skills you plan on contributing.
+
+[Following these comprehensive steps](../tools/issue-tracking.md#guidelines) to create your issue.
+
+## Document your change
+
+Your changes might require documentation updates. Read about [when to document](../documentation/index.md#when) and [how to document](../documentation/index.md#contributing) and follow steps as necessary.
+
+## Write tests
+
+Before you write any code you should write tests. You can use your plain-language description of how things should work to create automated tests for the feature.
+  
+CiviCRM comes with a variety of [testing tools](../testing/index.md) that help ensure that changes don't break existing functionality. Since CiviCRM [doesn't release code with failing tests](../tools/jenkins.md), your bug or improvement must not be covered in the existing tests.  Maybe there are incomplete tests, maybe the tests aren't valid measures of the functionality, or maybe your feature lacks test coverage.  Either way, you will need to write them to make sure your work doesn't get undermined by future changes.
+
+Use your documentation to identify tests that can be run, and then write them.  If you are adding functionality, you may not have the code that the test will call, but you can write your tests as if all the pages and functions exist, defining them later.
+
+## Make changes
+
+It's finally time to write the code.  The preparatory steps can seem tedious, but they're essential for working effectively in a worldwide team on software used by thousands of diverse organizations.  Hopefully these steps have made your coding task clearer and helped you be aware of the variety of priorities and use cases.
+
+The key in making changes is legibility: helping others see what you've changed and why.
+
+### Coding style
+
+One element of legibility is literal: make your changes according to the [CiviCRM coding standards](../standards/index.md).  This doesn't just make the code more readable on its own; standards make the `diff` more legible too.
+
+Each pull request is [automatically tested](../tools/jenkins.md) by `PHP_CodeSniffer` according to [the standards](https://github.com/civicrm/coder), and you should save time and test your code yourself.
+
+### Making commits
+
+Follow these steps to [make high-quality commits](../tools/git.md#committing).
+
+Once you've completed the work, revisit your documentation and tests to see if you've missed anything.
+
+## Open a pull request
+
+Read about [creating a pull request](../tools/git.md#pr) which includes information on writing a good subject line and minding the scope of your PR.
+
+Once you submit your pull request, CiviCRM's [Jenkins server](../tools/jenkins.md) will build a copy of CiviCRM and run tests against it, beginning with `PHP_CodeSniffer`.  If tests fail, you will be able to follow a link to view details.
+
+Other developers may comment on your code, raising questions or concerns or marking the changes as approved.  This is fine, but it is important not to hide important discussion.  If substantive discussion occurs in a pull request which has a separate ticket, make note of the discussion in the ticket.  If a pull request is closed in favor of another, explain that in the ticket and mention the old pull request in the new one.
+
+The goal is that the next person working on this feature area shouldn't have to do a lot of archeology to figure out the motivations, concerns, and impact of your changes.
+
+## Maintain your local changes
+
+While your pull request is reviewed, and even after it is merged, you will need to maintain your code on the site that needed the changes.  There are two main techniques for this.
+
+First, you can keep your `civicrm` directory under version control, including your changes there.  If you need to upgrade while your changes are still in review, [rebase](../tools/git.md#rebase) your changes on top of the new version.
+
+Alternatively, you can use a custom PHP or template override directory.  While this is generally discouraged for long-term customizations of your site (extensions are better), it can be an efficient way to track short-term overrides.  Just declare the path to the custom PHP and template folders in the Administer - System Settings - Directories page and copy your changed file(s) there, placing them under the same directory structure as within the `civicrm-core` repository.  Note the issue number and pull request in a comment at the top of each file, and remember to check the directory each time you upgrade.  Once your change is merged, just delete the override.
+
+## Review some other code
+
+CiviCRM works through the generosity of its users and the organizations that employ them.  Now that you have a pull request open (and some experience working with the CiviCRM codebase), why not take some time to [review another pull request](pr-review.md)?  
+
+You'll notice that the time you spend reviewing others' code and interacting with the rest of the community will serve you well: you'll be a better CiviCRM developer, and you'll have a better product.

docs/core/hacking.md

 ## When should I edit core CiviCRM?
 
 !!! danger
-      Most of the time, editing the core codebase directly
-      is not the recommended way for developers to customise and extend CiviCRM.
-      CiviCRM has two version releases per year so direct edits to the core codebase
-      will create upgrade issues for you.
-      There are other recommended ways for the majority of scenarios:
-      extensions, the APIs and hooks.
+      Most of the time, editing the core codebase directly is not the recommended way for developers to customise and extend CiviCRM. CiviCRM has multiple releases per year so direct edits to the core codebase will create upgrade issues for you. There are other recommended ways for the majority of scenarios: extensions, the APIs, and hooks.
 
 To help you decide, here are a couple of principles:
 
-- Bug fixes should always be applied to core. Information on how to submit your
-  bug fix will be added soon. <!--fixme!! -->
-- Some (but not all) enhancements to existing features may be best applied to
-  core, especially if they would be useful to others.
-- New features should generally be packed as Extensions.
-- If you aren't familiar with CiviCRM, by far the best way to get a sense if
-  you should be editing core is by talking with the CiviCRM developer community.
+- Bug fixes should always be applied to core.  See [Contributing to Core](contributing.md) for details.
+- Some (but not all) enhancements to existing features may be best applied to core, especially if they would be useful to others.
+- New features should generally be packed as [Extensions](../extensions/index.md).
+- If you aren't familiar with CiviCRM, by far the best way to get a sense if you should be editing core is by [talking with the CiviCRM developer community](../basics/community.md#collaboration-tools).

docs/core/release-process.md

+# Review/Release Process
+
+Releases are developed on a monthly cycle, with all but urgent bug and security fixes appearing in versions that are released the first Wednesday of each month.  These iterate the second part of the version number.  For example, 5.23.0 was released on Wednesday, March 4, 2020, 5.24.0 was released on Wednesday, April 1, 2020, and 5.25.0 was released on Wednesday, May 6, 2020.
+
+There is no active plan to iterate the first part of the version number.  The 4.7.x series generally followed the same monthly pattern as above except that the third part of the version number was iterated each month.  CiviCRM 5.0.0 followed 4.7.31 in April 2018, and the change was solely for numbering purposes: there is no substantial difference between 5.0.0 and 4.7.31 except for routine changes similar to those introduced every month.  The difference from 4.7.31 to 5.0.0 is comparable to that between 4.7.30 and 4.7.31 or that between 5.0.0 and 5.1.0.
+
+During the month, regressions and security vulnerabilities may be fixed in releases that iterate the third part of the version number.  Generally speaking, security changes will only be released on the first or third Wednesday of the month, and they will be announced through [the CiviCRM website and a security announcement email list](https://civicrm.org/security).  Other point releases may appear at any time.
+
+## Timing
+
+Monthly versions require the participation of a variety of people around the world.  While there is no firm time window, and new versions have been released at all times of day, you can typically expect monthly versions to be releases late in the day in the US/Pacific time zone, which may be early Thursday in many parts of the world.
+
+## Branches
+
+The main branch, termed `master`, is where pull requests are typically merged.  These changes will appear in the version released up to 2 months in the future.
+
+Each monthly release is based upon a branch of the codebase that is number for the first two parts of the upcoming release number.  This is branched off of `master` soon after the prior monthly release and is often termed the "Release Candidate" even though no static, numbered release candidates are generally produced.
+
+After the monthly release, the numbered branch is retained, and any changes that will appear in point releases for that version will be merged there.
+
+Pull requests should typically be made against `master` unless they clearly should appear in the release candidate or a point release.  Situations like this usually involve regressions that newly appear in the release candidate or a very recent version.  In these cases, it's not uncommon for reviewers or release managers to request two or three pull requests in tandem: one for `master`, one for the release candidate, and potentially one for the most recent release.
+
+## Example release cycle
+
+This system is best illustrated by the 5.24.x release cycle.  The `5.24` branch was cut from `master` soon after the 5.23.0 release on March 4, 2020.  A number of late changes, including urgent fixes and intra-release-candidate regressions, were merged during March.  On April 1, 2020, the first Wednesday of the month, 5.24.0 was released based upon the branch as it stood that day.
+
+Soon thereafter, the `5.25` branch was cut from `master`.
+
+Over the next couple of weeks, a number of urgent bug fixes were merged to `5.24`, and point releases 5.24.1 and 5.24.2 were released on the 4th and 9th of the month, respectively.  Security changes were merged to the branch and released on April 15, 2020, the third Wednesday of the month, as 5.24.3.  Further urgent bug fixes were merged to the branch and released as 5.24.4, 5.24.5, and 5.24.6 later in the month.
+
+All of these changes were also merged to `master` and `5.25`.  On May 6, 2020, the first Wednesday of the next month, 5.25.0 was released based upon the `5.25` branch.  No further changes have been merged to `5.24`, and any bugs appearing in the 5.24.x series are to be addressed in later branches and versions.  Meanwhile, the `5.26` branch was cut from `master`, denoting the start of the cycle for the release to appear in June.
+
+## Release impact
+
+Despite having a similar numbering pattern, CiviCRM *does not* use Semantic Versioning.  Each monthly version may contain any number of bug fixes, new features, deprecations, database schema changes, and API changes.  Each may require site administrators to reconfigure features, manually change things prior to or after upgrading, or address problems in past upgrades.
+
+The release notes for each monthly version contain a synopsis to highlight these considerations.  The following items are noted for each version:
+
+- **Fix security vulnerabilities?**  A new monthly release will not typically fix security vulnerabilities.  This is as a courtesy to site administrators so that they won't have the pressure to upgrade for security reasons while potentially facing other changed due to the upgrade.  A security release will more commonly contain only the security-specific changes.
+- **Change the database schema?**  This highlights releases that add or remove database tables, fields, indexes or triggers.  The upgrade process will manage these changes, but site administrators with unusual circumstances or direct-to-database integrations will want to take note of these changes.
+- **Alter the API?** 	The API is intended to be a relatively stable way to integrate other systems or build customizations.  A change to the API, whether through adding or deprecating entities or methods, altering the output of a method, or changing permissions for a method, will often need more attention than other changes to the software.
+- **Require attention to configuration options?**  Changes in the CiviCRM code will often require site administrators to revisit configuration settings that would otherwise be left alone.  One common example is system workflow message templates: when the standard template for a receipt is changed, any site administrator who has edited their site's copy of the template will need to merge their site-specific changes with the changes between versions.  Another is when new permissions are added: a site administrator may need to check that the appropriate users have permission to do a task that may have previously required a different permission.
+- **Fix problems installing or upgrading to a previous version?**  Site administrators encountering a problem installing or upgrading may use a variety of workarounds.  A version that resolves these problems may require the workarounds to be undone.  This is also a useful flag for those who encounter problems and revert the upgrade: they can know that their problems may have been addressed.
+- **Introduce features?**  Most monthly versions introduce new features, which are defined as improvements that go beyond making an existing feature behave the way it purports to.
+- **Fix bugs?**  Practically all monthly versions and point releases fix bugs.
+
+## Getting your changes documented accurately
+
+Clear documentation multiplies the impact of any improvement in code.  If your change is a new feature someone might want to use, you should explain that it's there and how to use it.  If you're fixing a bug, you should make it easy for others experiencing it to know that it is fixed in the new version.  If your changes require a site administrator's attention just to continue using CiviCRM as they had before, it's imperative that you catch their attention.
+
+At the very least, be sure that the intent and impact of your changes are clear for the editors of the release notes.  If you need the attention of site administrators as they upgrade, you should write an upgrade message and/or system check.  Finally, the user, system administrator, and developer documentation allow you to explain in-depth how to make use of your changes.
+
+### Descriptions for release notes
+
+The release notes for each monthly version are built upon a list of all commits since the previous monthly version.  The editors of the release notes will never be able to follow all changes as they are developed, deliberated, and merged.  Instead, they need to be able to understand the effect of each pull request within a minute or two and convey that in the release notes.
+
+In a long ticket, it's sometimes hard to distinguish the initial proposal from what ultimately happened.  For the editors, and for their readers who follow the link to read the details, you can't assume they have followed anything that went on.  Conversations sometimes split between GitLab and a pull request (sometimes a pull request that gets closed), and sometimes key things are resolved on email or Mattermost conversations, or in person at a sprint.
+
+An accurate title goes a long way.  If a pull request fixes a bug, and the title describes the bug concisely, that is completely sufficient.  If the title is "Changes to CiviContribute Component Settings not saved", and in fact the bug is that submitting that form does not save the changes, and the fix makes it so that submitting the form saves the changes, that makes for a perfect description.
+
+If the pull request can't be completely described in the title, it's best to add a modifier indicating what details to look for.  "Changes to CiviContribute Component Settings not saved for some users" or "Changes to certain fields in CiviContribute Component Settings not saved" both point to the sort of detail that the editors--and anyone skimming the release notes--would want to read more about.
+
+The second key thing is to link all related issues and pull requests.  If there's a GitLab issue that the pull request addresses, link to it.  If the pull request follows on an earlier, closed one where there was a lot of discussion, link to it.  If there are corresponding pull requests for other branches, link to them.  The first two provide context for describing the issue or solution.  The latter helps the editors be sure that the change is indeed new in that version or already introduced in an earlier point release.
+
+Finally, especially for larger issues, review the pull request and related issue, if there is one, to make sure it's clear what has actually changed.  You can edit the pull request or issue description to add a couple sentences, or if you lack permission to do that, you can add a final comment.  If the issue is only partially resolved or just has groundwork laid, make it clear what has been done and what has yet to come.  You might also consider whether it's appropriate to have a massive issue that will just be partially complete for the foreseeable future: maybe it's better to split it into several.
+
+### Upgrade messages and system checks
+
+If a site administrator might need to do something following the upgrade, add a post-upgrade message.  (These are in the version-specific file in the `CRM/Upgrade/Incremental/php` folder.)  You may also add a pre-upgrade message, but know that by the time a site administrator sees it, the codebase has already been swapped out.  It's not realistic to expect them to revert at that point, so the effect is similar to the post-upgrade messages.
+
+The person applying upgrades will not necessarily be in a position to make configuration changes.  Whether they lack the organizational authority or simply lack the context, the person reading a post-upgrade message may not understand something you're describing or may not feel confident doing it.  This is separate from something simply being technically confusing: the IT director might run the upgrade but defer to the fundraising officer for managing edits to the online contribution receipt.
+
+Of course, some other site administrators may simply blow past the pre- and post-upgrade messages, and there's no way to go back and view them later.
+
+There are two strategies for addressing these issues.  The first is to make the information easy to find and share.  Add documentation in the user or administrator guide, a helper extension like Doctor When, or simply in a clear explanation on the issue or pull request.  Make the post-upgrade message something straightforward for the person running the upgrade to share with their colleagues.
+
+The second is to assume that many site administrators will ignore the message.  Instead, think through the consequences and make sure that the issue is highlighted later through help text, form validation, or a system check.
+
+System checks are a good way to flag problems on a site.  When an administrator logs in for the first time in a day or visits the system status page, problems will be visible.  You can write a system check that ensures that things are configured properly, and if they are not, administrator users will be reminded.
+
+### User, administrator, or developer documentation
+
+When you add a new feature or resolve a bug in a way that requires some thought on the part of site administrators, writing documentation in the User Guide, System Administrator Guide, or this Developer Guide will help people understand and use it properly.
+
+It's common to open a pull request in a documentation repository and point out that it is dependent upon unmerged changes in the code repository.  Add links in both directions, and reviewers can know to merge them together.