<commit_before>The Elasticsearch docs are in AsciiDoc format and can be built using the
Elasticsearch documentation build process.

See: https://github.com/elastic/docs

=== Adding API reference pages

When you need to add a reference page for a new API:

* Use the API reference template: 
https://github.com/elastic/docs/blob/master/shared/api-ref-ex.asciidoc[template], 
https://www.elastic.co/guide/en/elasticsearch/reference/master/get-snapshot-repo-api.html[real-life example].
* Create a separate source file for each API. 
* The anchor for the top-level heading should match the heading as closely as possible. 
* Use dashes to separate words in the anchor. (Avoid underscores.) 
* The name of the source file should match the anchor text. 
* Include an abbreviated title that drops the heading's _API_ suffix.
* Start the short description with a verb.
* Include the sections from the reference template as applicable. 
See the template for information about each section. 
* Add a link to the new topic from the appropriate API category page.
These links are typically grouped into sub-categories and listed in logical order. 
For example, the put API is listed before the get and delete APIs.
* Include the new file so the API appears in alphabetical order in the TOC nav.

The template uses https://github.com/elastic/docs/blob/master/shared/attributes.asciidoc[shared attributes] 
for a number of the standard headings so we can tweak them globally if need be. 

Many of the API reference pages also use shared parameter definitions from 
https://github.com/elastic/elasticsearch/blob/master/docs/reference/rest-api/common-parms.asciidoc[elasticsearch/docs/reference/rest-api/common-parms].
You don't have to do that. 

=== Backporting doc fixes

* Doc changes should generally be made against master and backported through to the current version
  (as applicable).  
  
* Changes can also be backported to the maintenance version of the previous major version. 
  This is typically reserved for technical corrections, as it can require resolving more complex
  merge conflicts, fixing test failures, and figuring out where to apply the change.

* Avoid backporting to out-of-maintenance versions. 
  Docs follow the same policy as code and fixes are not ordinarily merged to
  versions that are out of maintenance.
  
* Do not backport doc changes to https://www.elastic.co/support/eol[EOL versions]. 

=== Snippet testing

Snippets marked with `[source,console]` are automatically annotated with
"VIEW IN CONSOLE" and "COPY AS CURL" in the documentation and are automatically
tested by the command `./gradlew -pdocs check`. To test just the docs from a
single page, use e.g. `./gradlew -pdocs integTest --tests "\*rollover*"`.

By default each `[source,console]` snippet runs as its own isolated test. You
can manipulate the test execution in the following ways:

* `// TEST`: Explicitly marks a snippet as a test. Snippets marked this way
are tests even if they don't have `[source,console]` but usually `// TEST` is
used for its modifiers:
  * `// TEST[s/foo/bar/]`: Replace `foo` with `bar` in the generated test. This
  should be used sparingly because it makes the snippet "lie". Sometimes,
  though, you can use it to make the snippet more clear. Keep in mind that
  if there are multiple substitutions then they are applied in the order that
  they are defined.
  * `// TEST[catch:foo]`: Used to expect errors in the requests. Replace `foo`
  with `request` to expect a 400 error, for example. If the snippet contains
  multiple requests then only the last request will expect the error.
  * `// TEST[continued]`: Continue the test started in the last snippet. Between<commit_msg>[DOCS] Update backport policy for known issues (#73489)<commit_after>The Elasticsearch docs are in AsciiDoc format and can be built using the
Elasticsearch documentation build process.

See: https://github.com/elastic/docs

=== Adding API reference pages

When you need to add a reference page for a new API:

* Use the API reference template: 
https://github.com/elastic/docs/blob/master/shared/api-ref-ex.asciidoc[template], 
https://www.elastic.co/guide/en/elasticsearch/reference/master/get-snapshot-repo-api.html[real-life example].
* Create a separate source file for each API. 
* The anchor for the top-level heading should match the heading as closely as possible. 
* Use dashes to separate words in the anchor. (Avoid underscores.) 
* The name of the source file should match the anchor text. 
* Include an abbreviated title that drops the heading's _API_ suffix.
* Start the short description with a verb.
* Include the sections from the reference template as applicable. 
See the template for information about each section. 
* Add a link to the new topic from the appropriate API category page.
These links are typically grouped into sub-categories and listed in logical order. 
For example, the put API is listed before the get and delete APIs.
* Include the new file so the API appears in alphabetical order in the TOC nav.

The template uses https://github.com/elastic/docs/blob/master/shared/attributes.asciidoc[shared attributes] 
for a number of the standard headings so we can tweak them globally if need be. 

Many of the API reference pages also use shared parameter definitions from 
https://github.com/elastic/elasticsearch/blob/master/docs/reference/rest-api/common-parms.asciidoc[elasticsearch/docs/reference/rest-api/common-parms].
You don't have to do that. 

=== Backporting doc fixes

* Doc changes should generally be made against master and backported through to the current version
  (as applicable).  
  
* Changes can also be backported to the maintenance version of the previous major version. 
  This is typically reserved for technical corrections, as it can require resolving more complex
  merge conflicts, fixing test failures, and figuring out where to apply the change.

* Avoid backporting to out-of-maintenance versions. 
  Docs follow the same policy as code and fixes are not ordinarily merged to
  versions that are out of maintenance.
  
* Do not backport doc changes to https://www.elastic.co/support/eol[EOL versions].

* Release notes for known issues are an exception to this policy. Document the 
  known issue in the release notes for any minor version affected by the issue.
  Backport the changes to any branch containing release notes for those
  versions, even if the branch is no longer maintained.

=== Snippet testing

Snippets marked with `[source,console]` are automatically annotated with
"VIEW IN CONSOLE" and "COPY AS CURL" in the documentation and are automatically
tested by the command `./gradlew -pdocs check`. To test just the docs from a
single page, use e.g. `./gradlew -pdocs integTest --tests "\*rollover*"`.

By default each `[source,console]` snippet runs as its own isolated test. You
can manipulate the test execution in the following ways:

* `// TEST`: Explicitly marks a snippet as a test. Snippets marked this way
are tests even if they don't have `[source,console]` but usually `// TEST` is
used for its modifiers:
  * `// TEST[s/foo/bar/]`: Replace `foo` with `bar` in the generated test. This
  should be used sparingly because it makes the snippet "lie". Sometimes,
  though, you can use it to make the snippet more clear. Keep in mind that
  if there are multiple substitutions then they are applied in the order that
  they are defined.
  * `// TEST[catch:foo]`: Used to expect errors in the requests. Replace `foo`
  with `request` to expect a 400 error, for example. If the snippet contains
  multiple requests then only the last request will expect the error.
  * `// TEST[continued]`: Continue the test started in the last snippet. Between
{'fraction_non_alphanumeric': 0.06775277993276442, 'fraction_numerical': 0.0014222911817946729, 'mean_word_length': 4.136122177954848, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 12, 'lorem ipsum': 0, 'www.': 4, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3472604', 'n_tokens_mistral': 2102, 'n_tokens_neox': 1978, 'n_words': 1049}