SONAR-10612 Added content

15 files changed, 489 insertions, 1 deletions

diff --git a/server/sonar-docs/src/images/long-lived-branch-concept.png b/server/sonar-docs/src/images/long-lived-branch-concept.png
new file mode 100644
index 00000000000..cc31705e524
--- /dev/null
+++ b/server/sonar-docs/src/images/long-lived-branch-concept.png
diff --git a/server/sonar-docs/src/images/quality-gate-status.jpeg b/server/sonar-docs/src/images/quality-gate-status.jpeg
new file mode 100644
index 00000000000..c57c27b9e64
--- /dev/null
+++ b/server/sonar-docs/src/images/quality-gate-status.jpeg
diff --git a/server/sonar-docs/src/images/recommended-quality-gate.png b/server/sonar-docs/src/images/recommended-quality-gate.png
new file mode 100644
index 00000000000..fc82647ed5c
--- /dev/null
+++ b/server/sonar-docs/src/images/recommended-quality-gate.png
diff --git a/server/sonar-docs/src/images/restore-quality-profile.jpeg b/server/sonar-docs/src/images/restore-quality-profile.jpeg
new file mode 100644
index 00000000000..7a7a2df5d01
--- /dev/null
+++ b/server/sonar-docs/src/images/restore-quality-profile.jpeg
diff --git a/server/sonar-docs/src/images/short-lived-branch-concept.png b/server/sonar-docs/src/images/short-lived-branch-concept.png
new file mode 100644
index 00000000000..24f98a86710
--- /dev/null
+++ b/server/sonar-docs/src/images/short-lived-branch-concept.png
diff --git a/server/sonar-docs/src/pages/branches/branches-faq.md b/server/sonar-docs/src/pages/branches/branches-faq.md
new file mode 100644
index 00000000000..63bc9cab628
--- /dev/null
+++ b/server/sonar-docs/src/pages/branches/branches-faq.md
@@ -0,0 +1,35 @@
+---
+title: Frequently Asked Branches Questions
+---
+
+_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)_
+
+**Q:** How long are branches retained?  
+**A:** Long-lived branches are retained until you delete them manually (**Administration > Branches**).
+Short-lived branches are deleted automatically after 30 days with no analysis.
+This can be updated in **Configuration > General > Number of days before purging inactive short living branches**.
+
+**Q:** Do I need to have my project stored in an SCM such as Git or SVN to use this feature?  
+**A:** No, you don't need to be connected to a SCM. But if you use Git or SVN we can better track the new files on short-lived branches and so better report new issues on the files that really changed during the life of the short-lived branch.
+
+**Q:** If I flag an Issue as "Won't Fix" or "False-Positive", will it be replicated as such when merging my short-lived branch into the Master?  
+**A:** Yes. Each time there is an analysis of a long-lived branch, we look at the issues on the short-lived branches and try to synchronize them with the newly raised issues on the long-lived branch. In case you made some changes on the issues (false-positive, won't fix), these changes will be reported on the long-lived branch.
+
+**Q:** Can I still use `sonar.branch`?  
+**A:** `sonar.branch` is deprecated. You can still use it but it will behave the same way it always has: a separate project will be created. We encourage you to smoothly migrate your users to the new parameter `sonar.branch.name`.
+Please note you cannot use `sonar.branch` together with `sonar.branch.name`.
+
+**Q:** Can I manually delete a branch?  
+**A:** This can be achieved by going into the Administration menu at Project's level, then Branches.
+
+**Q:** How do I control the lifespan of a short-lived branch?  
+**A:** As a global admin, you can set the parameter sonar.dbcleaner.daysBeforeDeletingInactiveShortLivingBranches to control how many days you want to keep an inactive short-lived branch.
+
+**Q:** Does the payload of the Webhook contain extra information related to Branches?  
+**A:** Yes, an extra node called "branch" is added to the payload.
+
+**Q:** When are Webhooks called?  
+**A:** When the computation of the background task is done for a given branch but also when an issue is updated on a short-lived branch.
+
+**Q:** What is the impact on my LOCs consumption vs my license?  
+**A:** LOCs scanned on long-lived or short-lived branches are NOT counted so you can scan as much as you want without impact on your LOCs consumed
diff --git a/server/sonar-docs/src/pages/branches/index.md b/server/sonar-docs/src/pages/branches/index.md
new file mode 100644
index 00000000000..0130365285c
--- /dev/null
+++ b/server/sonar-docs/src/pages/branches/index.md
@@ -0,0 +1,71 @@
+---
+title: Branches
+---
+
+_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)_
+
+Branch analysis allows you to
+
+* analyze long-lived branches
+* analyze short-lived branches
+* notify external systems when the status of a short-lived branch is impacted
+
+## Branch Types
+
+### Short-lived
+
+Short-Lived
+This corresponds to Pull/Merge Requests or Feature Branches. This kind of branch:
+
+* will disappear quickly
+* will be merged rapidly to prevent integration issues
+* is developed for a given version, so the version does not change,
+  and there is no Leak Period concept as such; it's all leak period
+  tracks all the new issues related to the code that changed on it.
+
+![conceptual illustration of short-lived branches.](images/short-lived-branch-concept.png)
+
+For more, see [Short-lived Branches](short-lived-branches)
+
+### Long-lived
+
+This corresponds to "Maintenance" Branches that will house several release versions.
+This kind of branch will:
+
+* last for a long time
+* inevitably diverge more and more from the other branches
+* house several release versions, each of which must pass the quality gate
+  to go to production not be expected to be merged into another branch
+
+![conceptual illustration of long-lived branches.](images/long-lived-branch-concept.png)
+
+For more, see [Long-lived Branches](long-lived-branches)
+
+### Master / Main Branch
+
+This is the default, and typically corresponds to what's being developed for
+your next release. This is usually known within a development team as
+"master" or "head", and is what is analyzed when no specific branch parameters
+are provided. It is labeled "Main Branch" and defaults to the name "master",
+but can be renamed from within the interface. When you are not using Developer Edition, this is the only branch you see.
+
+## Analysis
+
+A branch is created when the `sonar.branch.name` parameter is passed during analysis.
+
+| Parameter Name        | Description                                                                                                                                                                                                                                                             |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `sonar.branch.name`   | Name of the branch (visible in the UI)                                                                                                                                                                                                                                  |
+| `sonar.branch.target` | Name of the branch where you intend to merge your short-lived branch at the end of its life. If left blank, this defaults to the master branch. It can also be used while initializing a long-lived branch to sync the issues from a branch other than the Main Branch. |
+
+### Git History
+
+By default, TravisCI only fetches the last 50 git commits. You must use `git fetch --unshallow` to get the full history. If you don't, new issues may not be assigned to the correct developer.
+
+### Configuring the Branch type
+
+A regular expression is used to determine whether a branch is treated as long-lived or short-lived. By default, branches that have names starting with either "branch" or "release" will be treated as long-lived.
+
+This can be updated globally in **Configuration > General > Detection** of long-lived branches or at project's level in the **Admininstration > Branches**.
+
+Once a branch type has been set, it cannot be changed. Explicitly, you cannot transform a long-lived to short-lived branch, or vice-versa.
diff --git a/server/sonar-docs/src/pages/branches/long-lived-branches.md b/server/sonar-docs/src/pages/branches/long-lived-branches.md
new file mode 100644
index 00000000000..6498ae65888
--- /dev/null
+++ b/server/sonar-docs/src/pages/branches/long-lived-branches.md
@@ -0,0 +1,23 @@
+---
+title: Long-lived Branches
+---
+
+_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)_
+
+## Status vs Quality Gate
+
+The same quality gate that is applied to the project as a whole is automatically applied to long-lived branches as well. This is not editable.
+
+## Issue Creation and Synchronization
+
+During the **first analysis only**, issues (type, severity, status, assignee, change log, comments) are synchronized with the Main Branch. In each synchronized issue, a comment is added to the change log of the issue on the long-lived branch: "The issue has been copied from branch 'master' to branch yyy".
+
+Then, at each subsequent analysis of the long-lived branch, any new issue that comes from a short-lived branch automatically inherits the attributes (type, severity, ...) the issue had in the short-lived branch. A comment is added to the change log of the issue on the long-lived branch: "The issue had been copied from branch 'the short-live branch' to branch yyy".
+
+## Leak Period
+
+Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the Leak Period of a long-lived branch in **Administration > Branches**.
+
+## Settings and Quality Profiles on Branches
+
+Branch settings and quality profiles default to those set for the master branch, and by design, it's not possible to configure other values.
diff --git a/server/sonar-docs/src/pages/branches/short-lived-branches.md b/server/sonar-docs/src/pages/branches/short-lived-branches.md
new file mode 100644
index 00000000000..cdf79fc9c7c
--- /dev/null
+++ b/server/sonar-docs/src/pages/branches/short-lived-branches.md
@@ -0,0 +1,39 @@
+---
+title: Short-lived Branches
+---
+
+_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)_
+
+## Status vs Quality Gate
+
+For short-lived branches, there is a kind of hard-coded quality gate focusing only on new issues. Its status is reflected by the green|red signal associated with each short-lived branch:
+
+* status: green / OK or red / ERROR
+* error conditions:
+
+  * new open bugs > 0
+  * new open vulnerabilities > 0
+  * new open code smells > 0
+
+It is possible to change the status of a short-lived branch from ERROR to OK (red to green), i.e. mergable, by manually confirming the issues. The same is true for the False-Positive and Won't Fix statuses.
+It means the status of a short-lived branch will be red only when there are Open issues in the branch.
+
+## Issue Creation and Synchronization
+
+The issues visible on the short-lived branch are the new issues corresponding to files modified in the branch.
+
+Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.
+
+## Leak Period
+
+The ephemeral nature of short-lived branches means no explicit Leak Period is necessary; it's all new code. Thus, no "new code" data is available for a short-lived branch.
+
+## Settings and Quality Profiles on Branches
+
+Branch settings and quality profiles default to those set for the master branch, and by design, it's not possible to configure other values.
+
+## Known Limitations
+
+* Only the number of bugs, code smells, vulnerabilities and files are computed. As a consequence, you have no way to get a Quality Gate status as such on short-lived branch.
+* You cannot connect SonarLint to a short-lived branch.
+* Analysis of a short-lived branch based on another short-lived branch is not supported.
diff --git a/server/sonar-docs/src/pages/fixing-the-water-leak.md b/server/sonar-docs/src/pages/fixing-the-water-leak.md
new file mode 100644
index 00000000000..d4057c3470e
--- /dev/null
+++ b/server/sonar-docs/src/pages/fixing-the-water-leak.md
@@ -0,0 +1,45 @@
+---
+title: Fixing the Water Leak
+---
+
+## What is the Water Leak
+
+Imagine you come home one day to find a puddle of water on the kitchen floor. As you watch, the puddle slowly gets larger.
+
+Do you reach for the mop? Or do you try to find the source and fix it? The choice is obvious, right? You find the source of the leak!
+
+So why do anything different with code quality? When you analyze an application with SonarQube and realize that it has a lot of technical debt, the knee-jerk reaction is generally to start remediating – either that or put together a remediation plan. This is like mopping the floor once a day while ignoring the source of the water.
+
+Typically in this traditional approach, just before release a periodic code quality audit result in findings the developers should act on before releasing. This approach might work in the short term, especially with strong management backing, but it consistently fails in the mid to long run, because:
+
+* The code review comes too late in the process, and no stakeholder is keen to get the problems fixed; everyone wants the new version to ship.
+
+* Developers typically push back on the recommendations made by an external team that doesn't know the context of the project. And by the way the code under review is obsolete already.
+
+* There is a clear lack of ownership for code quality with this approach. Who owns quality? No one!
+
+* What gets reviewed is the entire application before it goes to production and it is obviously not possible to apply the same criteria to all applications. A negotiation will happen for each project, which will drain all credibility from the process
+
+Instead, why not apply the same simple logic you use at home to the way you manage code quality? Fixing the leak means putting the focus on the “new” code, i.e. the code that was added or changed since the last release. Then things get much easier:
+
+* The [Quality Gate](/quality-gates) can be run every day, and passing it is achievable. There are no surprises at release time.
+
+* It's pretty difficult for developers to push back on problems they introduced the previous day. Instead, they're generally happy to fix the problems while the code is still fresh.
+
+* There is a clear ownership of code quality
+
+* The criteria for go/no-go are consistent across applications, and are shared among teams. Indeed new code is new code, regardless of which application it is done in
+
+* The cost is insignificant because it is part of the development process
+
+As a bonus, the code that gets changed the most has the highest maintainability, and the code that doesn't get changed has the lowest, which makes a lot of sense. Because of the nature of software, and the fact that we keep making changes to it, the debt will naturally be reduced. Where it isn’t is where it doesn't need to be.
+
+## How to do it
+
+SonarQube offers two main tools to help you find your leaks:
+
+* Leak Period metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version`
+
+* New Code is primarily detected based on SCM "blame" data (starting from the first analysis within your Leak Period), with fallback mechanisms when needed. See SCM integration for more details.
+
+* [Quality Gates](/quality-gates) allow you to set boolean thresholds against which your code is measured. Use them with differential metrics to ensure that your code quality moves in the right direction over time.
diff --git a/server/sonar-docs/src/pages/index.md b/server/sonar-docs/src/pages/index.md
new file mode 100644
index 00000000000..df72822ff71
--- /dev/null
+++ b/server/sonar-docs/src/pages/index.md
@@ -0,0 +1,5 @@
+---
+title: Documentation
+---
+
+[SonarQube](http://www.sonarqube.org/)® software (previously called Sonar) is an open source quality management platform, dedicated to continuously analyze and measure technical quality, from project portfolio to method. If you wish to extend the SonarQube platform with open source plugins, have a look at our [plugin library](https://docs.sonarqube.org/display/PLUG/Plugin+Library).
diff --git a/server/sonar-docs/src/pages/quality-gates.md b/server/sonar-docs/src/pages/quality-gates.md
new file mode 100644
index 00000000000..57d4acef57d
--- /dev/null
+++ b/server/sonar-docs/src/pages/quality-gates.md
@@ -0,0 +1,73 @@
+---
+title: Quality Gates
+---
+
+## Overview
+
+A quality gate is the best way to enforce a quality policy in your organization.
+It's there to answer ONE question: can I deliver my project to production today or not?
+
+In order to answer this question, you define a set of Boolean conditions based on measure thresholds against which projects are measured. For example:
+
+* No new blocker issues
+* Code coverage on new code greater than 80%
+* Etc.
+
+Ideally, all projects will be verified against the same quality gate, but that's not always practical. For instance, you may find that:
+
+* Technological implementation differs from one application to another (you might not require the same code coverage on new code for Web or Java applications).
+* You want to ensure stronger requirements on some of your applications (internal frameworks for example).
+* Etc.
+
+Which is why you can define as many quality gates as you wish. Quality Gates are defined and managed in the **Quality Gates** page found in the top menu.
+
+## Use the Best Quality Gate Configuration
+
+The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the Fixing the Water Leak concept. At each SonarQube release, we adjust automatically this default quality gate according to SonarQube's capabilities.
+
+Three metrics allow you to enforce a given Rating of Reliability, Security and Maintainability, not just overall but also on new code. These metrics are recommended and come as part of the default quality gate. We strongly advise you to adjust your own quality gates to use them to make feedback more clear to your developers looking at their quality gate on their project page.
+
+Don't forget also that quality gate conditions must use differential values. There is no point for example to check an absolute value such as : Number of Lines of Code is greater than 1000.
+
+### Recommended Quality Gate
+
+![Recommended Quality Gate](../images/recommended-quality-gate.png)
+
+## Quality Gate Status
+
+The current status is displayed prominently at the top of the Project Page:
+
+![Quality Gate Status](../images/quality-gate-status.jpeg)
+
+## Getting Notified When a Quality Gate Fails
+
+Thanks to the notification mechanism, users can be notified when a quality gate fails. To do so, subscribe to the **New quality gate status** notification either for all projects or a set of projects you're interested in.
+
+## Security
+
+Quality Gates can be accessed by any user (even anonymous users). All users can view every aspect of a quality gate.
+
+To make changes (create, edit or delete) users must be granted the **Administer Quality Profiles and Gates** permission.
+
+A **project administrator** can choose which quality gates his/her project is associated with. See Project Settings for more.
+
+## Defining Quality Gates
+
+To manage quality gates, go to **Quality Gates** (top menu bar).
+
+Each Quality Gate condition is a combination of:
+
+* measure
+* period: **Value** (to date) or **Leak** (differential value over the Leak period)
+* comparison operator
+* warning value (optional)
+* error value (optional)
+
+For instance, a condition might be:
+
+* measure: Blocker issue
+* period: Value
+* comparison operator: >
+* error value: 0
+
+Which can be stated as: No blocker issues.
diff --git a/server/sonar-docs/src/pages/quality-profiles.md b/server/sonar-docs/src/pages/quality-profiles.md
new file mode 100644
index 00000000000..e3f01c0abe4
--- /dev/null
+++ b/server/sonar-docs/src/pages/quality-profiles.md
@@ -0,0 +1,79 @@
+---
+title: Quality Profiles
+---
+
+## Overview
+
+The Quality Profiles service is central to SonarQube, since it is where you define your requirements by defining sets of **rules** (ex: Methods should not have a Cognitive Complexity greater than 15).
+
+Ideally, all projects will be measured with the same profile for any given language, but that's not always practical. For instance, you may find that:
+
+* The technological implementation differs from one application to another (for example, different coding rules may apply when building threaded or non-threaded Java applications).
+* You want to ensure stronger requirements on some of your applications (internal frameworks for example).
+* Etc.
+
+Which is why you can define as many quality profiles as you wish even though it is recommended to have as few Quality Profiles as possible to ensure consistency across the projects in your company. To manage quality profiles, go to **Quality Profiles** (top bar), where you'll find profiles grouped by language.
+
+Each language plugin comes with a predefined, built-in profile (usually called "Sonar way") so that you can get started very quickly with SonarQube analyses. This is why as soon as you install a new language plugin, at least one quality profile will be available for you. Each language must have a default profile (marked with the Default tag). Projects that are not explicitly associated with a specific profile will be analyzed using the language's default profile.
+
+When starting from a new installation, it's tempting to use Sonar way as your default profile because it contains all the rules that are generally applicable to most projects. But as a best practice, you should create a new profile (you can populate it by copying the contents of Sonar way) and use it instead. Why? First because Sonar way profiles aren't editable, so you won't be able to customize it to your needs. Also, that lets you treat Sonar way as a baseline against which you can track your own profile as you make changes to it (and you will). Plus, Sonar way is typically updated with each new version of the plugin to add rules and sometimes adjust rule severities. Any profile that inherits from the built-in Sonar Way will de-facto be automatically updated at the same time.
+
+## How do I...
+
+### Delegate the management of Quality Profiles to someone else?
+
+By default, only users with the "Administer Quality Profiles" permission can edit Quality Profiles. But in large organizations, it may not be desirable to grant permissions to change all the Quality Profiles without distinction. That's why you can also grant users/groups the permission to edit an individual Quality Profile so that, for instance, the management of the Swift profile can be delegated to a group of Swift experts, and the same for COBOL, ...
+
+This delegation of permission can only be performed by someone who already has the "Administer Quality Profiles" permission or individual edit rights on the profile to which additional permissions should be granted. The interface to grant individual permissions is available on the profile detail page.
+
+### Copy the rules from one profile to another?
+
+Many times people want to work from a profile that's based on a built-in profile without actually using the built-in profile. The easiest thing to do in this case is to go to the original profile, we'll call it _Source_, in **Quality Profiles**. From there, click through on the total number of rules in _Source_ to land on the **Rules** page at a pre-narrowed search of _Source_'s rules. Use **Bulk Activate** to turn Source's rules on in your target profile.
+
+### Know what's changed in a profile?
+
+When SonarQube notices that an analysis was performed with a profile that is different in some way from the previous analysis, a Quality Profile event is added to the project's event log. To see the changes in a profile, navigate to the profile (**Quality Profiles > [ Profile Name ]**), and choose **Changelog**. This may help you understand how profile changes impact the issues raised in an analysis.
+
+Additionally, users with Quality Profile administration privileges are notified by email each time a built-in profile (one that is provided directly by an analyzer) is updated. These updates can only be caused by analyzer updates.
+
+### Copy a profile from one SonarQube instance to another?
+
+Use the **Back up** feature on the source instance to export the profile to an XML file. Use the **Restore Profile** feature on the target instance to import the file. Note that some [limitations](https://jira.sonarsource.com/browse/SONAR-5366) on this feature exist.
+
+![Restore Quality Profile](../images/restore-quality-profile.jpeg)
+
+### Apply a core set of rules plus additional rules to a project?
+
+Let's say your company has a minimum set of coding rules that all teams must follow, but you want to add rules that are specific to the in use technology in your project. Those rules are good for your team, but irrelevant or even misleading for others. This situation calls for inheritance. Set up a base profile, we'll call it _Root_ with your core set of rules. Then create a child profile, we'll call it _Sprout_. Once it's created, you can **Change parent** to inherit from _Root_, then add your missing rules.
+
+### Make sure my non-default profile is used on a project?
+
+One profile for each language is marked the default. Barring any other intervention, all projects that use that language will be analyzed with that profile. To have a project analyzed by a non-default profile instead, start from **Quality Profiles**, and click through on your target profile, then use the Projects part of the interface to manage which projects are explicitly assigned to the profile.
+
+### Make sure I've got all the relevant new rules in my profile?
+
+Each time a language plugin update is released, new rules are added, but they won't appear automatically in your profile unless you're using a built-in profile such as _Sonar way_.
+
+If you're not using a built-in profile, you can compare your profile to the built-in profile to see what new on-by-default rules you're missing.
+
+Another option is to go to the **Rules** space, and use the **Available Since** search facet to see what rules have been added to the platform since the day you upgraded the relevant plugin.
+
+And finally, the profile interface itself will help you be aware of rules added in a new plugin version in the **Latest New Rules** section on the right of the interface.
+
+### Compare two profiles?
+
+Starting from the **Quality Profiles** page, click through on one of the profiles you'd like to compare, then use the **Actions > Compare** interface to select the second profile and see the differences.
+
+### Make sure I don't have any deprecated rules in my profile?
+
+The **Deprecated Rules** section of the rules interface itself is your first warning that a profile contains deprecated rules. This pink-background section gives the total number of instances of deprecated rules that are currently active in profiles, and a breakdown of deprecated count per profile. A click-through here takes you to the **Rules** page to edit the profile in question.
+
+Alternately, you can perform a **Rules** search for the rules in a profile (either manually or by clicking-through from **Quality Profiles** page) and use the **Status** rule search facet to narrow the list to the ones that need attention.
+
+## Security
+
+The Quality Profiles service can be accessed by any user (even anonymous users). All users can view every aspect of a profile. That means anyone can see which rules are included in a profile, and which ones have been left out, see how a profile has changed over time, and compare the rules in any two profiles.
+
+To make rule profile changes (create, edit or delete) users must be granted the **Administer Quality Profiles and Gates** permission.
+
+A **project administrator** can choose which profiles his project is associated with. See Project Settings for more.
diff --git a/server/sonar-docs/src/pages/webhooks.md b/server/sonar-docs/src/pages/webhooks.md
new file mode 100644
index 00000000000..2c09225141f
--- /dev/null
+++ b/server/sonar-docs/src/pages/webhooks.md
@@ -0,0 +1,118 @@
+---
+title: Webhooks
+---
+
+Webhooks notify external services when a project analysis is complete. An HTTP POST request including a JSON payload is sent to each URL. URLs may be specified at both the project and global levels. Project-level specification does not replace global-level webhooks. All hooks at both levels are called.
+Plugins
+
+The HTTP(S) call:
+
+* is made regardless of the status of the Background Task
+* includes a JSON document as payload, using the POST method
+* has a content type of "application/json", with UTF-8 encoding
+
+## Configuration
+
+You can configure up to 10 webhooks in in **Administration > Webhooks**.
+
+An additional set of 10 webhooks can be configured at the global level in **Administration > Configuration > Webhooks**.
+
+If configured, all 20 will be executed.
+
+## Delivery and Payload
+
+### Delivery
+
+The Webhook administration console shows the result and timestamp of the most recent delivery of each webhook with the payload available via the list icon. Results and payloads of earlier deliveries are available from the tools menu to the right of each webhook
+
+Response records are purged after 30 days.
+
+The URL must respond within 10 seconds or the delivery is marked as failed.
+
+### Payload
+
+An HTTP header "X-SonarQube-Project" with the project key is sent to allow quick identification of the project involved
+
+The Payload is a JSON document which includes:
+
+* when the analysis was performed: see "analysedAt"
+* the identification of the project analyzed: see "project"
+* each Quality Gate criterion checked and its status: see "qualityGate"
+* the Quality Gate status of the project: see "qualityGate.status"
+* the status and the identifier of the Background Task : see "status" and "taskId"
+* user-specified properties: see "properties"
+
+#### Example
+
+```
+{
+    "analysedAt": "2016-11-18T10:46:28+0100",
+    "project": {
+        "key": "org.sonarqube:example",
+        "name": "Example"
+    },
+    "properties": {
+    },
+    "qualityGate": {
+        "conditions": [
+            {
+                "errorThreshold": "1",
+                "metric": "new_security_rating",
+                "onLeakPeriod": true,
+                "operator": "GREATER_THAN",
+                "status": "OK",
+                "value": "1"
+            },
+            {
+                "errorThreshold": "1",
+                "metric": "new_reliability_rating",
+                "onLeakPeriod": true,
+                "operator": "GREATER_THAN",
+                "status": "OK",
+                "value": "1"
+            },
+            {
+                "errorThreshold": "1",
+                "metric": "new_maintainability_rating",
+                "onLeakPeriod": true,
+                "operator": "GREATER_THAN",
+                "status": "OK",
+                "value": "1"
+            },
+            {
+                "errorThreshold": "80",
+                "metric": "new_coverage",
+                "onLeakPeriod": true,
+                "operator": "LESS_THAN",
+                "status": "NO_VALUE"
+            }
+        ],
+        "name": "SonarQube way",
+        "status": "OK"
+    },
+    "serverUrl": "http://localhost:9000",
+    "status": "SUCCESS",
+    "taskId": "AVh21JS2JepAEhwQ-b3u"
+}
+```
+
+## Additional parameters
+
+A basic authentication mechanism is supported by providing user/password in the URL of the Webhook such as `https://myLogin:myPassword@my_server/foo`.
+
+If you provide additional properties to your SonarQube Scanner using the pattern `sonar.analysis.*`, these properties will be automatically added to the section "properties" of the payload.
+
+For example these additional parameters:
+
+```
+sonar-scanner -Dsonar.analysis.scmRevision=628f5175ada0d685fd7164baa7c6382c1f25cab4 -Dsonar.analysis.buildNumber=12345
+```
+
+Would add this to the payload:
+
+```
+"properties": {
+  "sonar.analysis.scmRevision": "628f5175ada0d685fd7164baa7c6382c1f25cab4",
+  "sonar.analysis.buildNumber": "12345"
+}
+```
diff --git a/server/sonar-docs/src/tooltips/quality-gates/project-homepage-quality-gate.md b/server/sonar-docs/src/tooltips/quality-gates/project-homepage-quality-gate.md
index 115b34f419a..9d60c6363fc 100644
--- a/server/sonar-docs/src/tooltips/quality-gates/project-homepage-quality-gate.md
+++ b/server/sonar-docs/src/tooltips/quality-gates/project-homepage-quality-gate.md
@@ -1 +1 @@
-A Quality Gate is a set of measure-based Boolean conditions. It helps you know immediately whether your project is production-ready. If your current status is not Passed, you'll see which values caused the problem and the value required to pass.
+A Quality Gate is a set of measure-based Boolean conditions. It helps you know immediately whether your project is production-ready. If your current status is not Passed, you'll see which measures caused the problem and the values required to pass.