Merge pull request #5412 from NathanLovato/gdquest/backport-docs-reorganization-and-rewrites

Backport docs reorganization and section rewrites to 3.4 branch

about/docs_changelog.rst

@@ -50,7 +50,7 @@ Shading
 ^^^^^^^
 
 - Your First Shader Series:
-    - :ref:`doc_what_are_shaders`
+    - :ref:`doc_introduction_to_shaders`
     - :ref:`doc_your_first_canvasitem_shader`
     - :ref:`doc_your_first_spatial_shader`
     - :ref:`doc_your_second_spatial_shader`
@@ -107,7 +107,7 @@ Step by step
 ^^^^^^^^^^^^
 
 - :ref:`doc_signals`
-- :ref:`doc_exporting`
+- :ref:`doc_exporting_basics`
 
 Scripting
 ^^^^^^^^^
@@ -169,13 +169,12 @@ Viewports
 Shading
 ^^^^^^^
 
-- :ref:`doc_intro_to_shaders_water_workshop`
-- :ref:`doc_migrating_to_godot_shader_language`
+- :ref:`doc_converting_glsl_to_godot_shaders`
 - :ref:`doc_advanced_postprocessing`
 
 Shading Reference:
 
-- :ref:`doc_shaders`
+- :ref:`doc_introduction_to_shaders`
 - :ref:`doc_shading_language`
 - :ref:`doc_spatial_shader`
 - :ref:`doc_canvas_item_shader`

about/faq.rst

@@ -409,6 +409,8 @@ This custom UI toolkit :ref:`can't be used as a library <doc_faq_use_godot_as_li
 but you can still
 :ref:`use Godot to create non-game applications by using the editor <doc_faq_non_game_applications>`.
 
+.. _doc_faq_why_not_stl:
+
 Why does Godot not use STL (Standard Template Library)?
 -------------------------------------------------------
 

about/index.rst

@@ -11,6 +11,7 @@ About
    list_of_features
    docs_changelog
    release_policy
+   complying_with_licenses
 
 .. history
 .. authors

classes/class_arraymesh.rst

@@ -45,7 +45,7 @@ See also :ref:`ImmediateGeometry<class_ImmediateGeometry>`, :ref:`MeshDataTool<c
 Tutorials
 ---------
 
-- :doc:`../tutorials/content/procedural_geometry/arraymesh`
+- :doc:`../tutorials/3d/procedural_geometry/arraymesh`
 
 Properties
 ----------

classes/class_charfxtransform.rst

@@ -21,7 +21,7 @@ By setting various properties on this object, you can control how individual cha
 Tutorials
 ---------
 
-- :doc:`../tutorials/gui/bbcode_in_richtextlabel`
+- :doc:`../tutorials/ui/bbcode_in_richtextlabel`
 
 - `https://github.com/Eoin-ONeill-Yokai/Godot-Rich-Text-Effect-Test-Project <https://github.com/Eoin-ONeill-Yokai/Godot-Rich-Text-Effect-Test-Project>`__
 

classes/class_control.rst

@@ -37,11 +37,11 @@ Sets :ref:`mouse_filter<class_Control_property_mouse_filter>` to :ref:`MOUSE_FIL
 Tutorials
 ---------
 
-- :doc:`../tutorials/gui/index`
+- :doc:`../tutorials/ui/index`
 
 - :doc:`../tutorials/2d/custom_drawing_in_2d`
 
-- :doc:`../tutorials/gui/control_node_gallery`
+- :doc:`../tutorials/ui/control_node_gallery`
 
 - `All GUI Demos <https://github.com/godotengine/godot-demo-projects/tree/master/gui>`__
 

classes/class_csharpscript.rst

@@ -23,7 +23,7 @@ See also :ref:`GodotSharp<class_GodotSharp>`.
 Tutorials
 ---------
 
-- :doc:`../getting_started/scripting/c_sharp/index`
+- :doc:`../tutorials/scripting/c_sharp/index`
 
 Methods
 -------

classes/class_dictionary.rst

@@ -115,7 +115,7 @@ You need to first calculate the dictionary's hash with :ref:`hash<class_Dictiona
 Tutorials
 ---------
 
-- `#dictionary <../getting_started/scripting/gdscript/gdscript_basics.html#dictionary>`_ in :doc:`../getting_started/scripting/gdscript/gdscript_basics`
+- `#dictionary <../tutorials/scripting/gdscript/gdscript_basics.html#dictionary>`_ in :doc:`../tutorials/scripting/gdscript/gdscript_basics`
 
 - `3D Voxel Demo <https://godotengine.org/asset-library/asset/676>`__
 

classes/class_directory.rst

@@ -43,7 +43,7 @@ Here is an example on how to iterate through the files of a directory:
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/filesystem`
+- :doc:`../tutorials/scripting/filesystem`
 
 Methods
 -------

classes/class_editorscenepostimport.rst

@@ -42,7 +42,7 @@ The :ref:`post_import<class_EditorScenePostImport_method_post_import>` callback
 Tutorials
 ---------
 
-- `#custom-script <../getting_started/workflow/assets/importing_scenes.html#custom-script>`_ in :doc:`../getting_started/workflow/assets/importing_scenes`
+- `#custom-script <../tutorials/assets_pipeline/importing_scenes.html#custom-script>`_ in :doc:`../tutorials/assets_pipeline/importing_scenes`
 
 Methods
 -------

classes/class_file.rst

@@ -44,7 +44,7 @@ In the example above, the file will be saved in the user data folder as specifie
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/filesystem`
+- :doc:`../tutorials/scripting/filesystem`
 
 - `3D Voxel Demo <https://godotengine.org/asset-library/asset/676>`__
 

classes/class_gdnativelibrary.rst

@@ -21,9 +21,9 @@ A GDNative library can implement :ref:`NativeScript<class_NativeScript>`\ s, glo
 Tutorials
 ---------
 
-- :doc:`../tutorials/plugins/gdnative/gdnative-c-example`
+_ :doc:`../tutorials/scripting/gdnative/gdnative_c_example`
 
-- :doc:`../tutorials/plugins/gdnative/gdnative-cpp-example`
+_ :doc:`../tutorials/scripting/gdnative/gdnative_cpp_example`
 
 Properties
 ----------

classes/class_gdscript.rst

@@ -23,7 +23,7 @@ A script implemented in the GDScript programming language. The script extends th
 Tutorials
 ---------
 
-- :doc:`../getting_started/scripting/gdscript/index`
+- :doc:`../tutorials/scripting/gdscript/index`
 
 Methods
 -------

classes/class_image.rst

@@ -25,7 +25,7 @@ An ``Image`` cannot be assigned to a ``texture`` property of an object directly
 Tutorials
 ---------
 
-- :doc:`../getting_started/workflow/assets/importing_images`
+- :doc:`../tutorials/assets_pipeline/importing_images`
 
 Properties
 ----------

classes/class_imagetexture.rst

@@ -51,7 +51,7 @@ An ``ImageTexture`` is not meant to be operated from within the editor interface
 Tutorials
 ---------
 
-- :doc:`../getting_started/workflow/assets/importing_images`
+- :doc:`../tutorials/assets_pipeline/importing_images`
 
 Properties
 ----------

classes/class_javascript.rst

@@ -23,7 +23,7 @@ The JavaScript singleton is implemented only in the HTML5 export. It's used to a
 Tutorials
 ---------
 
-- `#calling-javascript-from-script <../getting_started/workflow/export/exporting_for_web.html#calling-javascript-from-script>`_ in :doc:`../getting_started/workflow/export/exporting_for_web`
+- `#calling-javascript-from-script <../tutorials/export/exporting_for_web.html#calling-javascript-from-script>`_ in :doc:`../tutorials/export/exporting_for_web`
 
 Methods
 -------

classes/class_jnisingleton.rst

@@ -21,7 +21,7 @@ The JNISingleton is implemented only in the Android export. It's used to call me
 Tutorials
 ---------
 
-- :doc:`../tutorials/plugins/android/android_plugin`
+- :doc:`../tutorials/platform/android/android_plugin`
 
 .. |virtual| replace:: :abbr:`virtual (This method should typically be overridden by the user to have any effect.)`
 .. |const| replace:: :abbr:`const (This method has no side effects. It doesn't modify any of the instance's member variables.)`

classes/class_multimesh.rst

@@ -27,9 +27,9 @@ Since instances may have any behavior, the AABB used for visibility must be prov
 Tutorials
 ---------
 
-- :doc:`../tutorials/3d/vertex_animation/animating_thousands_of_fish`
+- :doc:`../tutorials/performance/vertex_animation/animating_thousands_of_fish`
 
-- :doc:`../tutorials/optimization/using_multimesh`
+- :doc:`../tutorials/performance/using_multimesh`
 
 Properties
 ----------

classes/class_multimeshinstance.rst

@@ -23,11 +23,11 @@ This is useful to optimize the rendering of a high amount of instances of a give
 Tutorials
 ---------
 
-- :doc:`../tutorials/3d/vertex_animation/animating_thousands_of_fish`
+- :doc:`../tutorials/performance/vertex_animation/animating_thousands_of_fish`
 
 - :doc:`../tutorials/3d/using_multi_mesh_instance`
 
-- :doc:`../tutorials/optimization/using_multimesh`
+- :doc:`../tutorials/performance/using_multimesh`
 
 Properties
 ----------

classes/class_mutex.rst

@@ -21,7 +21,7 @@ A synchronization mutex (mutual exclusion). This is used to synchronize multiple
 Tutorials
 ---------
 
-- :doc:`../tutorials/threads/using_multiple_threads`
+- :doc:`../tutorials/performance/threads/using_multiple_threads`
 
 Methods
 -------

classes/class_node.rst

@@ -43,7 +43,7 @@ Finally, when a node is freed with :ref:`Object.free<class_Object_method_free>`
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/scenes_and_nodes`
+- :doc:`../getting_started/step_by_step/nodes_and_scenes`
 
 - `All Demos <https://github.com/godotengine/godot-demo-projects/>`__
 

classes/class_object.rst

@@ -45,9 +45,9 @@ Objects also receive notifications. Notifications are a simple way to notify the
 Tutorials
 ---------
 
-- :doc:`../getting_started/workflow/best_practices/node_alternatives`
+- :doc:`../tutorials/best_practices/node_alternatives`
 
-- `#advanced-exports <../getting_started/scripting/gdscript/gdscript_exports.html#advanced-exports>`_ in :doc:`../getting_started/scripting/gdscript/gdscript_exports`
+- `#advanced-exports <../tutorials/scripting/gdscript/gdscript_exports.html#advanced-exports>`_ in :doc:`../tutorials/scripting/gdscript/gdscript_exports`
 
 Methods
 -------

classes/class_os.rst

@@ -1686,7 +1686,7 @@ Returns ``true`` if the environment variable with the name ``variable`` exists.
 
 - :ref:`bool<class_bool>` **has_feature** **(** :ref:`String<class_String>` tag_name **)** |const|
 
-Returns ``true`` if the feature for the given feature tag is supported in the currently running instance, depending on the platform, build etc. Can be used to check whether you're currently running a debug build, on a certain platform or arch, etc. Refer to the `Feature Tags <https://docs.godotengine.org/en/3.4/getting_started/workflow/export/feature_tags.html>`__ documentation for more details.
+Returns ``true`` if the feature for the given feature tag is supported in the currently running instance, depending on platform, build etc. Can be used to check whether you're currently running a debug build, on a certain platform or arch, etc. Refer to the `Feature Tags <https://docs.godotengine.org/en/latest/tutorials/export/feature_tags.html>`_ documentation for more details.
 
 **Note:** Tag names are case-sensitive.
 

classes/class_particles.rst

@@ -27,7 +27,7 @@ Use the ``process_material`` property to add a :ref:`ParticlesMaterial<class_Par
 Tutorials
 ---------
 
-- :doc:`../tutorials/3d/vertex_animation/controlling_thousands_of_fish`
+- :doc:`../tutorials/performance/vertex_animation/controlling_thousands_of_fish`
 
 - `Third Person Shooter Demo <https://godotengine.org/asset-library/asset/678>`__
 

classes/class_reference.rst

@@ -29,7 +29,7 @@ In the vast majority of use cases, instantiating and using ``Reference``-derived
 Tutorials
 ---------
 
-- :doc:`../getting_started/workflow/best_practices/node_alternatives`
+- :doc:`../tutorials/best_practices/node_alternatives`
 
 Methods
 -------

classes/class_resource.rst

@@ -25,9 +25,9 @@ Resource is the base class for all Godot-specific resource types, serving primar
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/resources`
+- :doc:`../tutorials/scripting/resources`
 
-- :doc:`../getting_started/workflow/best_practices/node_alternatives`
+- :doc:`../tutorials/best_practices/node_alternatives`
 
 Properties
 ----------

classes/class_richtexteffect.rst

@@ -30,7 +30,7 @@ A custom effect for use with :ref:`RichTextLabel<class_RichTextLabel>`.
 Tutorials
 ---------
 
-- :doc:`../tutorials/gui/bbcode_in_richtextlabel`
+- :doc:`../tutorials/ui/bbcode_in_richtextlabel`
 
 - `https://github.com/Eoin-ONeill-Yokai/Godot-Rich-Text-Effect-Test-Project <https://github.com/Eoin-ONeill-Yokai/Godot-Rich-Text-Effect-Test-Project>`__
 

classes/class_richtextlabel.rst

@@ -31,7 +31,7 @@ Rich text can contain custom text, fonts, images and some basic formatting. The
 Tutorials
 ---------
 
-- :doc:`../tutorials/gui/bbcode_in_richtextlabel`
+- :doc:`../tutorials/ui/bbcode_in_richtextlabel`
 
 - `GUI Rich Text/BBcode Demo <https://godotengine.org/asset-library/asset/132>`__
 

classes/class_scenetree.rst

@@ -25,9 +25,9 @@ You can also use the ``SceneTree`` to organize your nodes into groups: every nod
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/scene_tree`
+- :doc:`../tutorials/scripting/scene_tree`
 
-- :doc:`../tutorials/viewports/multiple_resolutions`
+- :doc:`../tutorials/rendering/multiple_resolutions`
 
 Properties
 ----------

classes/class_script.rst

@@ -25,7 +25,7 @@ The ``new`` method of a script subclass creates a new instance. :ref:`Object.set
 Tutorials
 ---------
 
-- :doc:`../getting_started/step_by_step/scripting`
+- :doc:`../getting_started/step_by_step/scripting_first_script`
 
 Properties
 ----------

classes/class_semaphore.rst

@@ -21,7 +21,7 @@ A synchronization semaphore which can be used to synchronize multiple :ref:`Thre
 Tutorials
 ---------
 
-- :doc:`../tutorials/threads/using_multiple_threads`
+- :doc:`../tutorials/performance/threads/using_multiple_threads`
 
 Methods
 -------

classes/class_shader.rst

@@ -23,9 +23,9 @@ This class allows you to define a custom shader program that can be used by a :r
 Tutorials
 ---------
 
-- :doc:`../tutorials/shading/index`
+- :doc:`../tutorials/shaders/index`
 
-- :doc:`../tutorials/shading/your_first_shader/what_are_shaders`
+- :ref:`doc_introduction_to_shaders`
 
 Properties
 ----------

classes/class_shadermaterial.rst

@@ -23,7 +23,7 @@ A material that uses a custom :ref:`Shader<class_Shader>` program to render eith
 Tutorials
 ---------
 
-- :doc:`../tutorials/shading/index`
+- :doc:`../tutorials/shaders/index`
 
 Properties
 ----------

classes/class_string.rst

@@ -19,7 +19,7 @@ This is the built-in string class (and the one used by GDScript). It supports Un
 Tutorials
 ---------
 
-- :doc:`../getting_started/scripting/gdscript/gdscript_format_string`
+- :doc:`../tutorials/scripting/gdscript/gdscript_format_string`
 
 Methods
 -------

classes/class_theme.rst

@@ -23,7 +23,7 @@ Theme resources can alternatively be loaded by writing them in a ``.theme`` file
 Tutorials
 ---------
 
-- :doc:`../tutorials/gui/gui_skinning`
+- :doc:`../tutorials/ui/gui_skinning`
 
 Properties
 ----------

classes/class_thread.rst

@@ -23,9 +23,9 @@ A unit of execution in a process. Can run methods on :ref:`Object<class_Object>`
 Tutorials
 ---------
 
-- :doc:`../tutorials/threads/using_multiple_threads`
+- :doc:`../tutorials/performance/threads/using_multiple_threads`
 
-- :doc:`../tutorials/threads/thread_safe_apis`
+- :doc:`../tutorials/performance/threads/thread_safe_apis`
 
 - `3D Voxel Demo <https://godotengine.org/asset-library/asset/676>`__
 

classes/class_viewport.rst

@@ -33,7 +33,7 @@ Tutorials
 
 - :doc:`../tutorials/2d/2d_transforms`
 
-- :doc:`../tutorials/viewports/index`
+- :doc:`../tutorials/rendering/viewports`
 
 - `GUI in 3D Demo <https://godotengine.org/asset-library/asset/127>`__
 

classes/class_visualscript.rst

@@ -25,7 +25,7 @@ You are most likely to use this class via the Visual Script editor or when writi
 Tutorials
 ---------
 
-- :doc:`../getting_started/scripting/visual_script/index`
+- :doc:`../tutorials/scripting/visual_script/index`
 
 Methods
 -------

classes/class_visualserver.rst

@@ -37,7 +37,7 @@ In 2D, all visible objects are some form of canvas item. In order to be visible,
 Tutorials
 ---------
 
-- :doc:`../tutorials/optimization/using_servers`
+- :doc:`../tutorials/performance/using_servers`
 
 Properties
 ----------

classes/class_visualshadernode.rst

@@ -23,7 +23,7 @@ Visual shader graphs consist of various nodes. Each node in the graph is a separ
 Tutorials
 ---------
 
-- :doc:`../tutorials/shading/visual_shaders`
+- :doc:`../tutorials/shaders/visual_shaders`
 
 Properties
 ----------

classes/class_visualshadernodeinput.rst

@@ -21,7 +21,7 @@ Gives access to input variables (built-ins) available for the shader. See the sh
 Tutorials
 ---------
 
-- :doc:`../tutorials/shading/shading_reference/index`
+- :doc:`../tutorials/shaders/shader_reference/index`
 
 Properties
 ----------

community/asset_library/index.rst

@@ -7,4 +7,5 @@ Asset Library
 
    what_is_assetlib
    using_assetlib
+   submitting_to_assetlib
    uploading_to_assetlib

community/asset_library/submitting_to_assetlib.rst

@@ -0,0 +1,210 @@
+.. _doc_submitting_to_assetlib:
+
+Submitting to the Asset Library
+===============================
+
+Introduction
+------------
+
+This tutorial aims to serve as a guide on how you can submit your own assets
+to the Godot Asset Library and share them with the Godot community.
+
+As mentioned in the :ref:`doc_using_assetlib` document, in order to be able to
+submit assets to the AssetLib, you need to have a registered account, and be
+logged in.
+
+Submission guidelines
+---------------------
+
+Before submitting your asset, please ensure it follows all of the
+requirements, and also consider following the recommendations.
+
+Requirements
+~~~~~~~~~~~~
+
+Generally speaking, most assets people submit to the asset library
+are accepted. However, in order for your asset to be accepted, there
+are a few requirements your asset needs to meet to be approved.
+
+* The asset must **work**. If the asset doesn't run or otherwise doesn't
+  work in the specified Godot version, then it will be rejected.
+
+* The asset must have a proper **.gitignore** file. It's important to
+  keep redundant data out of the repository.
+  `Here's a template. <https://raw.githubusercontent.com/aaronfranke/gitignore/godot/Godot.gitignore>`_
+
+* No **submodules**, or any submodules must be non-essential. GitHub
+  does not include submodules in the downloaded ZIP file, so if the
+  asset needs the contents of the submodule, your asset won't work.
+
+* The **license** needs to be correct. The license listed on the asset
+  library must match the license in the repository. The repo MUST
+  have a license file, called either "LICENSE" or "LICENSE.md".
+  This file must contain the license text itself and a copyright
+  statement that includes the year(s) and copyright holder.
+
+* Use proper **English** for the name and description of your asset.
+  This includes using correct capitalization, and using full
+  sentences in the description. You can also include other languages,
+  but there should at least be an English version.
+
+* The icon link must be a **direct link**. For icons hosted on GitHub, the
+  link must start with "raw.githubusercontent.com", not "github.com".
+
+Recommendations
+~~~~~~~~~~~~~~~
+
+These things are not required for your asset to be approved, but
+if you follow these recommendations, you can help make the asset
+library a better place for all users.
+
+* Fix or suppress all script **warnings**. The warning system is there to
+  help identify issues with your code, but people using your asset
+  don't need to see them.
+
+* Make your code conform to the official **style guides**. Having a
+  consistent style helps other people read your code, and it also helps
+  if other people wish to contribute to your asset. See: the
+  :ref:`doc_gdscript_styleguide` or the :ref:`doc_c_sharp_styleguide`.
+
+* If you have screenshots in your repo, place them in their own subfolder
+  and add an empty **.gdignore** file in the same folder (note: **gd**, not **git**).
+  This prevents Godot from importing your screenshots.
+  On Windows, open a command prompt in the project folder and run
+  ``type nul > .gdignore`` to create a file whose name starts with a period.
+
+* If your asset is a library for working with other files,
+  consider including **example files** in the asset.
+
+* Consider adding a **.gitattributes** file to your repo. This file allows
+  giving extra instructions to Git, such as specifying line endings and listing
+  files not required for your asset to function with the ``export-ignore``
+  directive. This directive removes such files from the resulting ZIP file
+  and prevents them from being downloaded by the asset library users.
+  For a typical plugin **.gitattributes** may look like this:
+
+  .. code-block:: none
+
+    # Normalize EOL for all files that Git considers text files.
+    * text=auto eol=lf
+
+    # Ignore some files when exporting to a ZIP.
+    /.gitattributes     export-ignore
+    /.gitignore         export-ignore
+    /LICENSE            export-ignore
+    /LICENSE.md         export-ignore
+    /README.md          export-ignore
+    /project.godot      export-ignore
+    /icon.png           export-ignore
+    /icon.svg           export-ignore
+
+  Other types of assets may require a different configuration (e.g.
+  a project template requires **project.godot**).
+
+* If you are submitting a plugin, add a **copy** of your license and readme
+  to the plugin folder itself. This is the folder that users are guaranteed to
+  keep with their project, so a copy ensures they always have those files handy
+  (and helps them fulfill your licensing terms).
+
+* The **icon** should be a square, its aspect ratio should be 1:1. It should
+  also ideally have a minimum resolution of 64x64 pixels.
+
+* While the asset library allows more than just GitHub, consider
+  hosting your asset's source code on **GitHub**. Other services may not
+  work reliably, and a lack of familiarity can be a barrier to contributors.
+
+Submitting
+----------
+
+Once you are logged in, you will be able to head over to the "Submit Assets" page
+of the AssetLib, which will look like this:
+
+|image0|
+
+While it may look like a lot (and there is more as you scroll down), each field is
+described in terms of what you should put in. We will nonetheless go over what
+is required in the submission form here as well.
+
+* **Asset Name**:
+    The name of your asset. Should be a unique, descriptive title of
+    what your asset is.
+* **Category**:
+    The category that your asset belongs to, and will be shown in
+    search results. The category is split into **Addons** and **Projects**.
+    In-editor, assets of the Project type (Templates, Demos, Projects) only show
+    up when viewing the AssetLib from the Project Manager, while assets of the
+    Addon type will only be visible from inside a project.
+* **Godot version**:
+    The version of the engine that the asset works with.
+    Currently, it's not possible to have a single asset entry contain downloads for
+    multiple engine versions, so you may need to re-submit the asset multiple times,
+    with an entry for each Godot version it supports. This is particularly important
+    when dealing with major versions of the engine, such as Godot 2.x and Godot 3.x.
+* **Version**:
+    The version number of the asset. While you are free to choose
+    and use any versioning scheme that you like, you may want to look into
+    something such as `SemVer <https://semver.org>`_ if you want your asset's
+    versioning scheme to be clear and consistent. Note that there is also an
+    internal version number, incremented every time the asset download URL is
+    changed or updated.
+* **Repository host**:
+    Assets uploaded to the AssetLib are not hosted on it
+    directly. Instead, they point to repositories hosted on third-party Git providers,
+    such as GitHub, GitLab or Bitbucket. This is where you choose which provider
+    your asset uses, so the site can compute the final download link.
+* **Repository URL**:
+    The URL to your asset's files/webpage. This will vary
+    based on your choice of provider, but it should look similar to `https://github.com/<user>/<project>`.
+* **Issues URL**:
+    The URL to your asset's issue tracker. Again, this will differ
+    from repository host to repository host, but will likely look similar to
+    `https://github.com/<user>/<project>/issues`. You may leave this field empty
+    if you use your provider's issue tracker, and it's part of the same repository.
+* **Download Commit**:
+    The commit of the asset. For example,
+    `b1d3172f89b86e52465a74f63a74ac84c491d3e1`. The site computes
+    the actual download URL from this.
+* **Icon URL**:
+    The URL to your asset's icon (which will be used as a thumbnail
+    in the AssetLib search results and on the asset's page). Should be an image
+    in either the PNG or JPG format.
+* **License**:
+    The license under which you are distributing the asset. The list
+    includes a variety of free and open-source software licenses, such as GPL
+    (v2 and v3), MIT, BSD and Boost Software License. You can visit `OpenSource.org <https://opensource.org>`_
+    for a detailed description of each of the listed licenses.
+* **Description**:
+    Finally, you can use the Description field for a textual
+    overview of your asset, its features and behavior, a changelog, et cetera. In the
+    future, formatting with Markdown will be supported, but currently, your only
+    option is plain text.
+
+You may also include up to three video and/or image previews, which will be shown
+at the bottom of the asset page. Use the "Enable" checkbox on each of the preview
+submission boxes to enable them.
+
+* **Type**:
+    Either an image, or a video.
+* **Image/YouTube URL**:
+    Either a link to the image, or to a video, hosted on YouTube.
+* **Thumbnail URL**:
+    A URL to an image that will be used as a thumbnail for the
+    preview. This option will be removed eventually, and thumbnails will be automatically
+    computed instead.
+
+Once you are done, press "Submit". Your asset will be entered into the review queue.
+You can check all assets currently pending a review `here <https://godotengine.org/asset-library/asset/edit?&asset=-1>`_ .
+The approval process is manual and may take up to a few days for your asset to be accepted (or rejected), so please
+be patient!
+
+.. note::
+
+    You may have some luck accelerating the approval process by messaging the
+    moderators and AssetLib reviewers on the `Contributors Chat <https://chat.godotengine.org/>`_,
+    or the official Discord server.
+
+You will be informed when your asset is reviewed. If it was rejected,
+you will be told why that may have been, and you will be able to submit it again
+with the appropriate changes.
+
+.. |image0| image:: img/assetlib_submit.png

community/asset_library/using_assetlib.rst

@@ -99,7 +99,7 @@ new functions:
 |image6|
 
 You can learn how to submit assets to the Library, and what the asset submission
-guidelines are, in the next part of this tutorial, :ref:`doc_uploading_to_assetlib`.
+guidelines are, in the next part of this tutorial, :ref:`doc_submitting_to_assetlib`.
 
 In the editor
 -------------

community/channels.rst

@@ -14,16 +14,25 @@ Q&A
 
 - `Official Godot Questions & Answers <https://godotengine.org/qa/>`_
 
+Rocket.Chat
+-----------
+
+- `Godot Contributors Chat <https://chat.godotengine.org/>`_
+
 IRC on Freenode
 ---------------
 
+.. note::
+
+    As of January 2021, core developer chat has moved to the Godot Contributors Chat platform listed above.
+
 - `General: #godotengine <https://webchat.freenode.net/?channels=#godotengine>`_
 - `Engine development: #godotengine-devel <https://webchat.freenode.net/?channels=#godotengine-devel>`_
 - `Documentation: #godotengine-doc <https://webchat.freenode.net/?channels=#godotengine-doc>`_
 - `Pull request meetings: #godotengine-meeting <https://webchat.freenode.net/?channels=#godotengine-meeting>`_
 - `GDNative: #godotengine-gdnative <https://webchat.freenode.net/?channels=#godotengine-gdnative>`_
 - `Website and public relations: #godotengine-atelier <https://webchat.freenode.net/?channels=#godotengine-atelier>`_
-- `IRC logs <https://godot.eska.me/irc-logs/>`_
+- `IRC logs <https://freenode.logbot.info/godotengine-devel>`_
 
 Other chats
 -----------

community/contributing/best_practices_for_engine_contributors.rst

@@ -36,7 +36,7 @@ Best Practices
 Many contributors are extremely creative and just enjoy the process of designing
 abstract data structures, creating nice user interfaces, or simply love
 programming. Whatever the case may be, they come up with cool ideas, which may
-not be actually solving any actual problems.
+or may not be solving any real problems.
 
 .. image:: img/best_practices1.png
 
@@ -90,7 +90,7 @@ to work around it. This difficulty can be expressed as:
 
 If the problem is *too complex* for most users to solve, the software must offer
 a ready-made solution for it. Likewise, if the problem is easy for the user to
-workaround, offering such a solution is unnecessary and it's up to the user to
+work around, offering such a solution is unnecessary and it's up to the user to
 do it.
 
 The exception, however, is when the user stumbles into this problem *frequently
@@ -104,9 +104,9 @@ This is why discussing with other developers (next point) is always advised.
 #4: The solution must be discussed with others
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-It is often the case that, when users stumble upon problems, they are only
-immersed in their own project, so they will naturally try to solve the problem
-from their own perspective, thinking only about their use case.
+It is often the case that when users stumble upon problems, they are only
+immersed in their project, so they will naturally try to solve the problem
+from their perspective, thinking only about their use case.
 
 Because of this, user proposed solutions don't always contemplate other use
 cases that developers are often aware of, so they are often biased towards their
@@ -148,7 +148,7 @@ problems (as described in #2) also make their appearance on stage.
 .. image:: img/best_practices5.png
 
 The main problem is that, in reality, it rarely works this way. Most of the
-time, just writing an individual solution to each problem results in code that
+time, writing an individual solution to each problem results in code that
 is simpler and more maintainable.
 
 Additionally, solutions that target individual problems are better for the
@@ -157,7 +157,7 @@ to learn and remember a more complex system they will only need for simple
 tasks.
 
 Big and flexible solutions also have an additional drawback which is that, over
-time, they are rarely flexible enough for all users, which keep requesting more
+time, they are rarely flexible enough for all users, who keep requesting more
 functions added (and making the API and codebase more and more complex).
 
 #6: Cater to common use cases, leave the door open for the rare ones
@@ -225,7 +225,7 @@ but this path is always the advised one.
 Not every problem has a simple solution and, many times, the right choice is to
 use a third party library to solve the problem.
 
-As Godot requires to be shipped in a large amount of platforms, we just can't
+As Godot requires to be shipped in a large amount of platforms, we can't
 link libraries dynamically. Instead, we bundle them in our source tree.
 
 .. image:: img/best_practices8.png

community/contributing/bug_triage_guidelines.rst

@@ -4,8 +4,9 @@ Bug triage guidelines
 =====================
 
 This page describes the typical workflow of the bug triage team aka
-bugsquad when handling issues and pull requests on Godot's `GitHub <https://github.com/godotengine/godot>`_
-repository. It is bound to evolve together with the bugsquad, so do not
+bugsquad when handling issues and pull requests on Godot's
+`GitHub repository <https://github.com/godotengine/godot>`__.
+It is bound to evolve together with the bugsquad, so do not
 hesitate to propose modifications to the following guidelines.
 
 Issues management
@@ -25,7 +26,7 @@ contributors are welcome to take on any issue, if relevant after mentioning
 it on the issue ticket and/or discussing the best way to resolve it with
 other developers.
 
-For the time being we do not use the project dashboard feature either.
+For the time being, we do not use the project dashboard feature either.
 
 As far as possible, we try to assign labels (and milestones, when relevant)
 to both issues and pull requests.
@@ -39,7 +40,13 @@ The following labels are currently defined in the Godot repository:
 
 -  *Archived*: either a duplicate of another issue, or invalid. Such an
    issue would also be closed.
+-  *Breaks compat*: describes something that can only be fixed by breaking
+   compatibility with existing projects.
 -  *Bug*: describes something that is not working properly.
+-  *Cherrypick*: describes something that can be backported to a stable branch
+   after being merged in the ``master`` branch.
+-  *Crash:* describes a bug that causes the engine to crash.
+   This label is only used for "hard" crashes, not freezes.
 -  *Confirmed*: has been confirmed by at least one other contributor
    than the bug reporter (typically for *Bug* reports).
    The purpose of this label is to let developers know which issues are
@@ -58,11 +65,17 @@ The following labels are currently defined in the Godot repository:
 -  *Enhancement*: describes a proposed enhancement to an existing
    functionality.
 -  *Feature proposal*: describes a wish for a new feature to be
-   implemented.
+   implemented. Note that the main Godot repository no longer accepts
+   feature requests. Please use
+   `godot-proposals <https://github.com/godotengine/godot-proposals>`__ instead.
+-  *For PR meeting*: the issue needs to be discussed in a pull request meeting.
+   These meetings are public and are held on the `Godot Contributors Chat <https://chat.godotengine.org/>`_.
 -  *Junior job*: the issue is *assumed* to be an easy one to fix, which makes
    it a great fit for junior contributors who need to become familiar with
    the code base.
--  *Needs rebase*: the issue need a Git rebase to be merged.
+-  *High priority:* the issue is particularly important as it can
+   prevent people from releasing their projects or cause data loss.
+-  *Needs work*: the pull request needs additional work before it can be merged.
 -  *Needs testing*: the issue/pull request could not be completely tested
    and thus need further testing. This can mean that it needs to be tested
    on different hardware/software configurations or even that the steps to
@@ -97,19 +110,27 @@ feature request, or one that is not precise enough to be worked on.
 -  *Audio*: relates to the audio features (low and high level).
 -  *Buildsystem*: relates to building issues, either linked to the SCons
    buildsystem or to compiler peculiarities.
+-  *Codestyle*: relates to the programming style used within the codebase.
 -  *Core*: anything related to the core engine. It might be further
    split later on as it's a pretty big topic.
--  *Drivers*: relates to issues with the drivers used by the engine.
 -  *Editor*: relates to issues in the editor (mainly UI).
 -  *GDNative*: relates to the GDNative module.
 -  *GDScript*: relates to GDScript.
+-  *GUI*: relates to GUI (Control) nodes.
+-  *Import*: relates to the resource import system.
+-  *Input*: relates to input system.
 -  *Mono*: relates to the C# / Mono bindings.
+-  *Navigation*: relates to the navigation system (including A* and navmeshes).
 -  *Network*: relates to networking.
 -  *Physics*: relates to the physics engine (2D/3D).
 -  *Plugin*: relates to problems encountered while writing plugins.
--  *Porting*: relates to some specific platforms.
+-  *Porting*: relates to some specific platforms or exporting projects.
 -  *Rendering*: relates to the 2D and 3D rendering engines.
--  *VisualScript*: relates to issues with the visual scripting language.
+-  *Shaders*: relates to the Godot shader language or visual shaders.
+-  *Tests*: relates to unit tests.
+-  *Thirdparty*: relates to third-party libraries used in Godot.
+-  *VisualScript*: relates to issues with the visual scripting language (*not* visual shaders).
+-  *XR*: relates to Augmented Reality or Virtual Reality.
 
 Issues would typically correspond to only one topic, though it's not
 unthinkable to see issues that fit two bills. The general idea is that
@@ -125,17 +146,45 @@ If one of the platform labels is used, it is then exclusive and the
 previous assumption doesn't stand anymore (so if it's a bug on e.g.
 Android and Linux exclusively, select those two platforms).
 
+Documentation labels
+~~~~~~~~~~~~~~~~~~~~
+
+In the `documentation repository <https://github.com/godotengine/godot-docs>`__, we
+use the following labels:
+
+-  *Bug*: Incorrect information in an existing page. Not to be used for
+   *missing* information.
+-  *Class reference*: the issue is about the class reference, not a documentation page.
+-  *Discussion*: the issue is not consensual and needs further
+   discussion to define what exactly should be done to address the
+   topic.
+-  *Enhancememnt*: new information to be added in an existing page.
+-  *New page*: a new page to be created.
+-  *Hero wanted!*: contributions for issues with these labels
+   are especially welcome. Note that this **doesn't** mean you can't work
+   on issues without these labels.
+-  *Organization*: The issue involves moving pages around or reorganizing content.
+-  *Redirect*: a redirection needs to be created in the Read the Docs backend.
+   Only administrators can do this.
+-  *Salvageable*: the pull request can't be merged due to design issues or
+   merge conflicts and its author is not active anymore. However, it can still
+   be picked up by an external contributor to bring it to a mergeable state.
+   To do so, you need to open a new pull request based on the original pull request.
+-  *Topic:Mono*: the issue is about C# support in Godot.
+-  *Topic:Website*: the issue relates to the Sphinx/Read the Docs frontend or backend,
+   not the documentation contents.
+
 Milestones
 ~~~~~~~~~~
 
-`Milestones <https://github.com/godotengine/godot/milestones>`_ correspond to planned future versions of Godot for which
-there is an existing roadmap. Issues that fit in the said roadmap should
-be filed under the corresponding milestone; if they don't correspond to
-any current roadmap, they should be left without milestone. As a rule of
-thumb, an issue corresponds to a given milestone if it concerns a feature
-that is new in the milestone, or a critical bug that can't be accepted in any
-future stable release, or anything that Juan wants to work on right now.
-:)
+`Milestones <https://github.com/godotengine/godot/milestones>`_ correspond to
+planned future versions of Godot for which there is an existing roadmap. Issues
+that fit in the said roadmap should be filed under the corresponding milestone;
+if they don't correspond to any current roadmap, they should be left without
+milestone. As a rule of thumb, an issue corresponds to a given milestone if it
+concerns a feature that is new in the milestone, or a critical bug that can't be
+accepted in any future stable release, or anything that Juan wants to work on
+right now. :)
 
 Contributors are free to pick issues regardless of their assigned milestone;
 if a fix is proposed for a bug that was not deemed urgent and thus without

community/contributing/building_the_manual.rst

@@ -21,7 +21,7 @@ install all these tools. It comes pre-installed with `Python
 <https://www.python.org/>`__. Ensure that you install and use Python 3. Here are
 the commands to clone the repository and then install all requirements.
 
-.. note:: You may need to write ``python3 -m pip`` (Unix) or  ``py -m pip`` (Windows) instead of ``pip3``. 
+.. note:: You may need to write ``python3 -m pip`` (Unix) or  ``py -m pip`` (Windows) instead of ``pip3``.
           If both approaches fail, `check that you have pip3 installed <https://pip.pypa.io/en/stable/installation/>`__.
 
 .. code:: sh

community/contributing/class_reference_writing_guidelines.rst

@@ -0,0 +1,254 @@
+.. _doc_class_reference_writing_guidelines:
+
+Class reference writing guidelines
+==================================
+
+This page explains how to write the class reference. You will learn where to
+write new descriptions for the classes, methods, and properties for Godot's
+built-in node types.
+
+.. seealso::
+
+    To learn to submit your changes to the Godot project using the Git version
+    control system, see :ref:`doc_updating_the_class_reference`.
+
+The reference for each class is contained in an XML file like the one below:
+
+.. code-block:: xml
+
+    <class name="Node2D" inherits="CanvasItem" version="4.0">
+        <brief_description>
+            A 2D game object, inherited by all 2D-related nodes. Has a position, rotation, scale, and Z index.
+        </brief_description>
+        <description>
+            A 2D game object, with a transform (position, rotation, and scale). All 2D nodes, including physics objects and sprites, inherit from Node2D. Use Node2D as a parent node to move, scale and rotate children in a 2D project. Also gives control of the node's render order.
+        </description>
+        <tutorials>
+            <link title="Custom drawing in 2D">https://docs.godotengine.org/en/latest/tutorials/2d/custom_drawing_in_2d.html</link>
+            <link title="All 2D Demos">https://github.com/godotengine/godot-demo-projects/tree/master/2d</link>
+        </tutorials>
+        <methods>
+            <method name="apply_scale">
+                <return type="void">
+                </return>
+                <argument index="0" name="ratio" type="Vector2">
+                </argument>
+                <description>
+                    Multiplies the current scale by the [code]ratio[/code] vector.
+                </description>
+            </method>
+            [...]
+            <method name="translate">
+                <return type="void">
+                </return>
+                <argument index="0" name="offset" type="Vector2">
+                </argument>
+                <description>
+                    Translates the node by the given [code]offset[/code] in local coordinates.
+                </description>
+            </method>
+        </methods>
+        <members>
+            <member name="global_position" type="Vector2" setter="set_global_position" getter="get_global_position">
+                Global position.
+            </member>
+            [...]
+            <member name="z_index" type="int" setter="set_z_index" getter="get_z_index" default="0">
+                Z index. Controls the order in which the nodes render. A node with a higher Z index will display in front of others.
+            </member>
+        </members>
+        <constants>
+        </constants>
+    </class>
+
+
+It starts with brief and long descriptions. In the generated docs, the brief
+description is always at the top of the page, while the long description lies
+below the list of methods, variables, and constants. You can find methods,
+member variables, constants, and signals in separate XML nodes.
+
+For each, you want to learn how they work in Godot's source code. Then, fill
+their documentation by completing or improving the text in these tags:
+
+- `<brief_description>`
+- `<description>`
+- `<constant>`
+- `<method>` (in its `<description>` tag; return types and arguments don't take separate
+  documentation strings)
+- `<member>`
+- `<signal>` (in its `<description>` tag; arguments don't take separate documentation strings)
+- `<constant>`
+
+Write in a clear and simple language. Always follow the :ref:`writing guidelines
+<doc_docs_writing_guidelines>` to keep your descriptions short and easy to read.
+**Do not leave empty lines** in the descriptions: each line in the XML file will
+result in a new paragraph, even if it is empty.
+
+.. _doc_class_reference_writing_guidelines_editing_xml:
+
+How to edit class XML
+---------------------
+
+Edit the file for your chosen class in ``doc/classes/`` to update the class
+reference. The folder contains an XML file for each class. The XML lists the
+constants and methods you will find in the class reference. Godot generates and
+updates the XML automatically.
+
+.. note:: For some modules in the engine's source code, you'll find the XML
+          files in the ``modules/<module_name>/doc_classes/`` directory instead.
+
+Edit it using your favorite text editor. If you use a code editor, make sure
+that it doesn't change the indent style: you should use tabs for the XML and
+four spaces inside BBCode-style blocks. More on that below.
+
+To check that the modifications you've made are correct in the generated
+documentation, navigate to the ``doc/`` folder and run the command ``make rst``.
+This will convert the XML files to the online documentation's format and output
+errors if anything's wrong.
+
+Alternatively, you can build Godot and open the modified page in the built-in
+code reference. To learn how to compile the engine, read the :ref:`compilation
+guide <toc-devel-compiling>`.
+
+We recommend using a code editor that supports XML files like Vim, Atom, Visual Studio Code,
+Notepad++, or another to comfortably edit the file. You can also use their
+search feature to find classes and properties quickly.
+
+.. _doc_class_reference_writing_guidelines_bbcode:
+
+Improve formatting with BBCode style tags
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Godot's class reference supports BBCode-like tags. They add nice formatting to
+the text. Here's the list of available tags:
+
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| Tag                        | Effect                               | Usage                             | Result                                            |
++============================+======================================+===================================+===================================================+
+| [Class]                    | Link a class                         | Move the [Sprite2D].              | Move the :ref:`class_Sprite`.                     |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [method methodname]        | Link to a method in this class       | Call [method hide].               | Call :ref:`hide <class_Spatial_method_hide>`.     |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [method Class.methodname]  | Link to another class's method       | Call [method Node3D.hide].        | Call :ref:`hide <class_Spatial_method_hide>`.     |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [member membername]        | Link to a member in this class       | Get [member scale].               | Get :ref:`scale <class_Node2D_property_scale>`.   |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [member Class.membername]  | Link to another class's member       | Get [member Node2D.scale].        | Get :ref:`scale <class_Node2D_property_scale>`.   |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [signal signalname]        | Link to a signal in this class       | Emit [signal renamed].            | Emit :ref:`renamed <class_Node_signal_renamed>`.  |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [signal Class.signalname]  | Link to another class's signal       | Emit [signal Node.renamed].       | Emit :ref:`renamed <class_Node_signal_renamed>`.  |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [b] [/b]                   | Bold                                 | Some [b]bold[/b] text.            | Some **bold** text.                               |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [i] [/i]                   | Italic                               | Some [i]italic[/i] text.          | Some *italic* text.                               |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [code] [/code]             | Monospace                            | Some [code]monospace[/code] text. | Some ``monospace`` text.                          |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [kbd] [/kbd]               | Keyboard/mouse shortcut              | Some [kbd]Ctrl + C[/kbd] key.     | Some :kbd:`Ctrl + C` key.                         |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [codeblock] [/codeblock]   | Multiline preformatted block         | *See below.*                      | *See below.*                                      |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [codeblocks] [/codeblocks] | [codeblock] for multiple languages   | *See below.*                      | *See below.*                                      |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [gdscript] [/gdscript]     | GDScript codeblock tab in codeblocks | *See below.*                      | *See below.*                                      |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+| [csharp] [/csharp]         | C# codeblock tab in codeblocks       | *See below.*                      | *See below.*                                      |
++----------------------------+--------------------------------------+-----------------------------------+---------------------------------------------------+
+
+Use ``[codeblock]`` for pre-formatted code blocks. Inside ``[codeblock]``,
+always use **four spaces** for indentation. The parser will delete tabs. For
+example:
+
+.. code-block:: none
+
+    [codeblock]
+    func _ready():
+        var sprite = get_node("Sprite2D")
+        print(sprite.get_pos())
+    [/codeblock]
+
+Will display as:
+
+.. code-block:: gdscript
+
+    func _ready():
+        var sprite = get_node("Sprite2D")
+        print(sprite.get_pos())
+
+If you need to have different code version in GDScript and C#, use
+``[codeblocks]`` instead. If you use ``[codeblocks]``, you also need to have at
+least one of the language-specific tags, ``[gdscript]`` and ``[csharp]``.
+
+Always write GDScript code examples first! You can use this `experimental code
+translation tool <https://github.com/HaSa1002/codetranslator>`_ to speed up your
+workflow.
+
+.. code-block:: none
+
+    [codeblocks]
+    [gdscript]
+    func _ready():
+        var sprite = get_node("Sprite2D")
+        print(sprite.get_pos())
+    [/gdscript]
+    [csharp]
+    public override void _Ready()
+    {
+        var sprite = GetNode("Sprite2D");
+        GD.Print(sprite.GetPos());
+    }
+    [/csharp]
+    [/codeblocks]
+
+The above will display as:
+
+.. tabs::
+ .. code-tab:: gdscript GDScript
+
+    func _ready():
+        var sprite = get_node("Sprite2D")
+        print(sprite.get_pos())
+
+ .. code-tab:: csharp
+
+    public override void _Ready()
+    {
+        var sprite = GetNode("Sprite2D");
+        GD.Print(sprite.GetPos());
+    }
+
+To denote important information, add a paragraph starting with "[b]Note:[/b]" at
+the end of the description:
+
+.. code-block:: none
+
+    [b]Note:[/b] Only available when using the Vulkan renderer.
+
+To denote crucial information that could cause security issues or loss of data
+if not followed carefully, add a paragraph starting with "[b]Warning:[/b]" at
+the end of the description:
+
+.. code-block:: none
+
+    [b]Warning:[/b] If this property is set to [code]true[/code], it allows clients to execute arbitrary code on the server.
+
+For deprecated properties, add a paragraph starting with "[i]Deprecated.[/i]".
+Notice the use of italics instead of bold:
+
+.. code-block:: none
+
+    [i]Deprecated.[/i] This property has been replaced by [member other_property].
+
+In all the paragraphs described above, make sure the punctuation is part of the
+BBCode tags for consistency.
+
+I don't know what this method does!
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No problem. Leave it behind, and list the methods you skipped when you request a
+pull of your changes. Another writer will take care of it.
+
+You can still look at the methods' implementation in Godot's source code on
+GitHub. If you have doubts, feel free to ask on the `Q&A website
+<https://godotengine.org/qa/>`__ and `Godot Contributors Chat <https://chat.godotengine.org/>`_.

community/contributing/code_style_guidelines.rst

@@ -48,6 +48,11 @@ setup clang-format locally to check and automatically fix all your commits.
              ``/* clang-format off */`` and ``/* clang-format on */`` to tell
              clang-format to ignore a chunk of code.
 
+.. seealso::
+
+    These guidelines only cover code formatting. See :ref:`doc_cpp_usage_guidelines`
+    for a list of language features that are permitted in pull requests.
+
 Using clang-format locally
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -117,9 +122,13 @@ Here is a non-exhaustive list of beautifier plugins for some IDEs:
 - Visual Studio Code: `Clang-Format <https://marketplace.visualstudio.com/items?itemName=xaver.clang-format>`__
 - Visual Studio: `ClangFormat <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat>`__
 - vim: `vim-clang-format <https://github.com/rhysd/vim-clang-format>`__
+- CLion: Starting from version ``2019.1``, no plugin is required. Instead, enable
+  `ClangFormat <https://www.jetbrains.com/help/clion/clangformat-as-alternative-formatter.html#clion-support>`__
 
 (Pull requests welcome to extend this list with tested plugins.)
 
+.. _doc_code_style_guidelines_header_includes:
+
 Header includes
 ~~~~~~~~~~~~~~~
 
@@ -186,7 +195,7 @@ Example:
 
     #include "core/hash_map.h"
     #include "core/list.h"
-    #include "scene/gui/control.h
+    #include "scene/gui/control.h"
 
     #include <png.h>
 
@@ -229,7 +238,7 @@ Example:
     #include "my_new_file.h"
 
     #include "core/math/math_funcs.h"
-    #include "scene/gui/line_edit.h
+    #include "scene/gui/line_edit.h"
 
     #include <zlib.h>
     #include <zstd.h>
@@ -254,7 +263,7 @@ Blacken your Python changes using `Black <https://pypi.org/project/black/>`__.
 Using black locally
 ~~~~~~~~~~~~~~~~~~~
 
-First of all, you will need to install black. Black requires Python 3.6.0+ 
+First of all, you will need to install black. Black requires Python 3.6.0+
 to run.
 
 Installation

community/contributing/content_guidelines.rst

@@ -0,0 +1,97 @@
+.. _doc_content_guidelines:
+
+Content guidelines
+==================
+
+This document is here to help us assess what we should include in the official
+documentation. Below, you will find a couple of principles and recommendations
+to write accessible content.
+
+We want to achieve two goals:
+
+1. **Empathize with our users.** We should write in a way that makes it easy for
+   them to learn from the docs.
+2. **Write a complete reference manual**. Our goal here is not to teach
+   programming foundations. Instead, we should provide a reference for how
+   Godot's features work.
+
+Guidelines and principles
+-------------------------
+
+Below are the guidelines we should strive to follow. They are not hard rules,
+though: exceptionally, a topic will require breaking one or more of these.
+Still, we should strive to achieve the two goals listed above.
+
+Writing complete and accessible documentation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**A feature doesn't exist unless it is documented**. If a user can't find
+information about a feature and how it works, it doesn't exist to them. We
+should ensure that we cover everything Godot does.
+
+.. note::
+
+    When adding or updating an engine feature, the documentation team needs to
+    know about it. Contributors should open an issue on the `godot-docs` repository
+    when their work gets merged and requires documentation.
+
+Do your best to keep documents **under 1000 words in length**. If a page goes
+past that threshold, consider splitting it into two parts if possible. Limiting
+page size forces us to write concisely and to break large documents so they each
+focus on a particular problem.
+
+Make it clear what **problem** each page or section of a page tackles and what
+the user will learn from it. Users need to know if they're reading the correct
+guide to solving problems they encounter. For example, instead of writing the
+heading "Signals", consider writing "Reacting to changes with signals". The
+second title makes it clear what the purpose of signals is.
+
+.. note::
+
+    Long section titles lead to long entries in the side menu, which can make
+    navigation cumbersome. Try to keep headings five words long or less.
+
+If the page assumes specific knowledge of other Godot features, mention it and
+link it to the corresponding documentation. For instance, a page about physics
+may use signals, in which case we could note that the page that introduces
+signals is a pre-requisite.
+
+Limiting cognitive load
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Limit the cognitive load required to read the documentation. The simpler and
+more explicit language we use, the more efficient it becomes for people to
+learn. You can do so by:
+
+1. Introducing only one new concept at a time whenever possible.
+2. Using simple English, as we recommend in our writing guidelines.
+3. Including one or more **concrete usage examples**. Prefer a real-world example
+   to abstract code like ``foobar``.
+
+While many people may understand more complex language and abstract examples,
+you will lose others. Also, understandable writing and practical examples
+benefit everyone.
+
+Always make an effort to **put yourself in the user's shoes**. When we
+understand something thoroughly, it becomes evident to us. We may fail to think
+about details relevant to a newcomer, but **good documentation meets users where
+they are**. We should strive to explain each feature's capabilities or intended
+uses with the most straightforward language possible.
+
+Try to remember what you first needed to know when learning about the feature or
+concept. What new terms did you need to learn? What confused you? What was the
+hardest to grasp? You will want users to review your work, and we recommend you
+practice explaining the feature before writing about it.
+
+.. note::
+
+    Having programming foundations is a pre-requisite to use a complex engine
+    like Godot. Talking about variables, functions, or classes is acceptable.
+    But we should favor plain language over specific terminology like
+    "metaprogramming". If you need to use precise terms, be sure to define them.
+
+When a page assumes knowledge of another engine feature, declare it at the
+beginning and link to resources that cover what users need. You may also link to
+other websites for pre-requisites beyond the documentation's scope. For example,
+you could link to an introduction to programming in the getting started guide, or a
+website that teaches math theory in the math section.

community/contributing/contributing_to_the_documentation.rst

@@ -0,0 +1,188 @@
+.. _doc_contributing_to_the_documentation:
+
+Contributing to the documentation
+=================================
+
+This guide explains how to contribute to Godot's documentation, be it by
+writing or reviewing pages.
+
+.. seealso::
+
+   If you want to translate pages or the class reference from English to other
+   languages, read :ref:`doc_editor_and_docs_localization`.
+
+Getting started
+---------------
+
+To modify or create pages in the reference manual, you need to edit ``.rst``
+files in the `godot-docs GitHub repository
+<https://github.com/godotengine/godot-docs>`_. Modifying those pages in a pull
+request triggers a rebuild of the online documentation upon merging.
+
+.. seealso:: For details on Git usage and the pull request workflow, please
+             refer to the :ref:`doc_pr_workflow` page. Most of what it describes
+             regarding the main godotengine/godot repository is also valid for
+             the docs repository.
+
+.. warning:: The class reference's source files are in the `Godot engine
+             repository <https://github.com/godotengine/godot>`_. We generate
+             the :ref:`Godot API <toc-class-ref>` section of this documentation
+             from them. If you want to update the description of a class, its
+             methods, or properties, read
+             :ref:`doc_updating_the_class_reference`.
+
+What is the Godot documentation
+-------------------------------
+
+The Godot documentation is intended as a comprehensive reference manual for the
+Godot game engine. It is not meant to contain step-by-step tutorials, except for
+two game creation tutorials in the Getting Started section.
+
+We strive to write factual content in an accessible and well-written language. To
+contribute, you should also read:
+
+1. The :ref:`doc_docs_writing_guidelines`. There, you will find rules and
+   recommendations to write in a way that everyone understands.
+2. The content guidelines. They explain the principles we follow to write the
+   documentation and the kind of content we accept.
+
+Contributing changes
+--------------------
+
+**Pull Requests should use the** ``master`` **branch by default.** Only make Pull
+Requests against other branches (e.g. ``2.1`` or ``3.0``) if your changes only
+apply to that specific version of Godot.
+
+Though less convenient to edit than a wiki, this Git repository is where we
+write the documentation. Having direct access to the source files in a revision
+control system is a plus to ensure our documentation quality.
+
+Editing existing pages
+~~~~~~~~~~~~~~~~~~~~~~
+
+To edit an existing page, locate its ``.rst`` source file and open it in your
+favorite text editor. You can then commit the changes, push them to your fork,
+and make a pull request. **Note that the pages in** ``classes/`` **should not be
+edited here.** They are automatically generated from Godot’s `XML class
+reference <https://github.com/godotengine/godot/tree/master/doc/classes>`__.
+See :ref:`doc_updating_the_class_reference` for details.
+
+.. seealso:: To build the manual and test changes on your computer, see
+             :ref:`doc_building_the_manual`.
+
+Editing pages online
+--------------------
+
+You can edit the documentation online by clicking the **Edit on GitHub** link in
+the top-right of every page.
+
+Doing so takes you to the GitHub text editor. You need to have a GitHub account
+and to log in to use it. Once logged in, you can propose change like so:
+
+1. Click the **Edit on GitHub** button.
+
+2. On the GitHub page you're taken to, click the pencil icon in the top-right
+   corner near the **Raw**, **Blame**, and **Delete** buttons. It has the
+   tooltip "Fork this project and edit the file".
+
+3. Edit the text in the text editor.
+
+4. At the bottom of the web page, summarize the changes you made and click the
+   button **Propose file change**. Make sure to replace the placeholder "Update file.rst"
+   by a short but clear one-line description, as this is the commit title.
+
+5. On the following screens, click the **Create pull request** button until you
+   see a message like *Username wants to merge 1 commit into godotengine:master
+   from Username:patch-1*.
+
+Another contributor will review your changes and merge them into the docs if
+they're good. They may also make changes or ask you to do so before merging.
+
+Adding new pages
+----------------
+
+Before adding a new page, please ensure that it fits in the documentation:
+
+1. Look for `existing issues
+   <https://github.com/godotengine/godot-docs/issues>`_ or open a new one to see
+   if the page is necessary.
+2. Ensure there isn't a page that already covers the topic.
+3. Read our :ref:`doc_content_guidelines`.
+
+To add a new page, create a ``.rst`` file with a meaningful name in the section you
+want to add a file to, e.g. ``tutorials/3d/light_baking.rst``.
+
+You should then add your page to the relevant "toctree" (table of contents,
+e.g. ``tutorials/3d/index.rst``). Add your new filename to the list on a new
+line, using a relative path and no extension, e.g. here ``light_baking``.
+
+Titles
+~~~~~~
+
+Always begin pages with their title and a Sphinx reference name:
+
+::
+
+    .. _doc_insert_your_title_here:
+
+    Insert your title here
+    ======================
+
+The reference ``_doc_insert_your_title_here`` and the title should match.
+
+The reference allows linking to this page using the ``:ref:`` format, e.g.
+``:ref:`doc_insert_your_title_here``` would link to the above example page (note
+the lack of leading underscore in the reference).
+
+Write your titles like plain sentences, without capitalizing each word:
+
+-  **Good:** Understanding signals in Godot
+-  **Bad:** Understanding Signals In Godot
+
+Only propers nouns, projects, people, and node class names should have their
+first letter capitalized.
+
+Sphinx and reStructuredText syntax
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Check Sphinx’s `reST Primer <https://www.sphinx-doc.org/en/stable/rest.html>`__
+and the `official reference <http://docutils.sourceforge.net/rst.html>`__ for
+details on the syntax.
+
+Sphinx uses specific reST comments to do specific operations, like defining the
+table of contents (``.. toctree::``) or cross-referencing pages. Check the
+`official Sphinx documentation
+<https://www.sphinx-doc.org/en/stable/index.html>`__ for more details. To learn
+how to use Sphinx directives like ``.. note::`` or ``.. seealso::``, check out
+the `Sphinx directives documentation
+<https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html>`__.
+
+Adding images and attachments
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To add images, please put them in an ``img/`` folder next to the ``.rst`` file with
+a meaningful name and include them in your page with:
+
+.. code:: rst
+
+   .. image:: img/image_name.png
+
+Similarly, you can include attachments, like assets as support material for a
+tutorial, by placing them into a ``files/`` folder next to the ``.rst`` file, and
+using this inline markup:
+
+.. code:: rst
+
+   :download:`myfilename.zip <files/myfilename.zip>`
+
+
+License
+-------
+
+This documentation and every page it contains is published under the terms of
+the `Creative Commons Attribution 3.0 license (CC-BY-3.0)
+<https://tldrlegal.com/license/creative-commons-attribution-(cc)>`_, with
+attribution to "Juan Linietsky, Ariel Manzur and the Godot community".
+
+By contributing to the documentation on the GitHub repository, you agree that
+your changes are distributed under this license.

community/contributing/cpp_usage_guidelines.rst

@@ -0,0 +1,100 @@
+.. _doc_cpp_usage_guidelines:
+
+C++ usage guidelines
+====================
+
+Rationale
+---------
+
+Since Godot 4.0, the C++ standard used throughout the codebase is a subset of
+**C++17**. While modern C++ brings a lot of opportunities to write faster, more
+readable code, we chose to restrict our usage of C++ to a subset for a few
+reasons:
+
+- It makes it easier to review code in online editors. This is because engine
+  contributors don't always have access to a full-featured IDE while reviewing
+  code.
+- It makes the code easier to grasp for beginner contributors (who may not be
+  professional C++ programmers). Godot's codebase is known to be easy to learn
+  from, and we'd like to keep it that way.
+
+To get your pull request merged, it needs to follow the C++ usage guidelines
+outlined here. Of course, you can use features not allowed here in your own C++
+modules or GDNative scripts.
+
+.. note::
+
+    Prior to Godot 4.0, the C++ standard used throughout the codebase was C++03,
+    with a handful of C++14 extensions. If you are contributing a pull request
+    to the `3.x` branch rather than `master`, your code can't use C++17 features.
+    Instead, your code must be able to be built with a C++14 compiler.
+
+    The guidelines below don't apply to third-party dependencies, although we
+    generally favor small libraries instead of larger solutions. See also
+    :ref:`doc_best_practices_for_engine_contributors`.
+
+.. seealso::
+
+    See :ref:`doc_code_style_guidelines` for formatting guidelines.
+
+Disallowed features
+-------------------
+
+**Any feature not listed below is allowed.** Using features like ``constexpr``
+variables and ``nullptr`` is encouraged when possible. Still, try to keep your
+use of modern C++ features conservative. Their use needs to serve a real
+purpose, such as improving code readability or performance.
+
+Standard Template Library
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We don't allow using the `STL <https://en.wikipedia.org/wiki/Standard_Template_Library>`__
+as Godot provides its own data types (among other things).
+See :ref:`doc_faq_why_not_stl` for more information.
+
+This means that pull requests should **not** use ``std::string``,
+``std::vector`` and the like. Instead, use Godot's datatypes as described below:
+
+- Use ``String`` instead of ``std::string``.
+- Use ``Vector`` instead of ``std::vector``. In some cases, ``List`` or
+  ``LocalVector`` can be used as an alternative (ask core developers first).
+- Use ``Array`` instead of ``std::array``.
+
+``auto`` keyword
+^^^^^^^^^^^^^^^^
+
+Please don't use the ``auto`` keyword for type inference. While it can avoid
+repetition, it can also lead to confusing code:
+
+.. code-block:: cpp
+
+    // Not so confusing...
+    auto button = memnew(Button);
+
+    // ...but what about this?
+    auto result = EditorNode::get_singleton()->get_complex_result();
+
+Keep in mind hover documentation often isn't readily available for pull request
+reviewers. Most of the time, reviewers will use GitHub's online viewer to review
+pull requests.
+
+We chose to forbid ``auto`` instead of allowing it on a case-by-case basis to
+avoid having to decide on difficult edge cases. Thank you for your understanding.
+
+Lambdas
+^^^^^^^
+
+Lambdas should be used conservatively when they make code effectively faster or
+simpler, and do not impede readability. Please ask before using lambdas in a
+pull request.
+
+``#pragma once`` directive
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To follow the existing style, please use standard ``#ifdef``-based include
+guards instead of ``#pragma once`` in new files.
+
+.. seealso::
+
+    See :ref:`doc_code_style_guidelines_header_includes` for guidelines on sorting
+    includes in C++ and Objective-C files.

community/contributing/docs_writing_guidelines.rst

@@ -32,6 +32,11 @@ There are 3 rules to describe classes:
     the smallest and clearest sentences possible. These guidelines will help
     you work towards that goal.
 
+.. seealso::
+
+    See the :ref:`content guidelines <doc_content_guidelines>` for information
+    on the types of documentation you can write in the official documentation.
+
 7 rules for clear English
 -------------------------
 
@@ -105,7 +110,7 @@ The progressive forms describe continuous actions. E.g. "is calling",
     Vector2 move ( Vector2 rel_vec )
     Move the body in the given direction, **stopping** if there is an obstacle. [...]
 
-**Do** use simple present, preterit or future.
+**Do** use simple present, past, or future.
 
 ::
 
@@ -295,7 +300,7 @@ The exception is topics that explain static typing concepts to users.
     const MainAttack := preload("res://fire_attack.gd")
     var hit_points := 5
     var name: String = "Bob"
-    var body_sprite := $Sprite as Sprite
+    var body_sprite := $Sprite2D as Sprite2D
 
 
 **Do** write constants and variables with dynamic typing:
@@ -305,14 +310,14 @@ The exception is topics that explain static typing concepts to users.
     const MainAttack = preload("res://fire_attack.gd")
     var hit_points = 5
     var name = "Bob"
-    var body_sprite = $Sprite
+    var body_sprite = $Sprite2D
 
 
 **Don't** write functions with inferred arguments or return types:
 
 ::
 
-    func choose(arguments: PoolStringArray) -> String:
+    func choose(arguments: PackedStringArray) -> String:
         # Chooses one of the arguments from array with equal chances
         randomize()
         var size := arguments.size()

community/contributing/documentation_guidelines.rst

@@ -25,9 +25,11 @@ documentation.
              describes regarding the main godotengine/godot repository is
              also valid for the docs repository.
 
-The README.md file contains all the information you need to get you started,
-please read it. In particular, it contains some tips and tricks and links to
-reference documentation about the reStructuredText markup language.
+.. warning:: The class reference's source files are in the `Godot engine repository
+             <https://github.com/godotengine/godot>`_. We generate the :ref:`Godot API
+             <toc-class-ref>` section of this documentation from them. If you want to update the
+             description of a class, its methods, or properties, read
+             :ref:`doc_updating_the_class_reference`.
 
 .. warning:: If you want to edit the **API reference**, please note that it
              should *not* be done in the godot-docs repository. Instead, you

community/contributing/editor_and_docs_localization.rst

@@ -112,7 +112,7 @@ translation interface where all the work happens:
 On that page, you have:
 
  - A toolbar which lets you cycle through strings of the current list, change
-   to another pre-defined list or do a custom search, etc. There is also a "Zen"
+   to another predefined list or do a custom search, etc. There is also a "Zen"
    editing mode with a simplified interface.
  - The actual string you are working on in the "Translation" panel. By default,
    there should be the English source string and an edit box for your language.
@@ -171,8 +171,8 @@ translating.
   a page that you want to translate, and then translate all the strings with the
   same source string location while comparing with the online version of that
   page in English. An example of source string location could be
-  ``getting_started/step_by_step/scenes_and_nodes.rst`` for the
-  page :ref:`doc_scenes_and_nodes`.
+  ``getting_started/step_by_step/nodes_and_scenes.rst`` for the
+  page :ref:`doc_nodes_and_scenes`.
 - The class reference's translation template is generated from the source XML
   files in **alphabetical order**, which is also the same as the order of the
   table of contents for the online version. You can therefore locate the source
@@ -184,7 +184,7 @@ translating.
 
 A handy tool to locate specific pages/classes is to use Weblate's advanced
 search feature, and especially the "Location strings" query (which can also be
-used with the ``location:`` token, e.g. ``location:scenes_and_nodes.rst``):
+used with the ``location:`` token, e.g. ``location:nodes_and_scenes.rst``):
 
 .. image:: img/l10n_05_search_location.png
 
@@ -194,9 +194,9 @@ used with the ``location:`` token, e.g. ``location:scenes_and_nodes.rst``):
 
     When a given source string is used in multiple source locations, they will
     all be concatenated into one. For example, the above
-    ``location:scenes_and_nodes.rst`` query would land first on the
+    ``location:nodes_and_scenes.rst`` query would land first on the
     "Introduction" source string which is used in dozens of pages, including
-    some that come before ``scenes_and_nodes.rst`` in the template. Clicking the
+    some that come before ``nodes_and_scenes.rst`` in the template. Clicking the
     "Next" button then brings us to the "Scene and nodes" title string displayed
     above.
     So it may happen that a given paragraph or section title is not at the
@@ -243,6 +243,10 @@ The editor translations originate from C++ strings, and may use:
     Scene '%s' is currently being edited.↵
     Changes will only take effect when reloaded.
 
+.. note::
+  Only logical order of the characters matters, in the right-to-left text, format
+  specifiers may be displayed as ``s%``.
+
 Online documentation (RST)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -324,7 +328,7 @@ breaks if they are not part of the original translation.
 .. seealso::
 
     See our documentation for class reference writers for the :ref:`list of
-    BBCode-like tags <doc_updating_the_class_reference_bbcode>` which are used
+    BBCode-like tags <doc_class_reference_writing_guidelines_bbcode>` which are used
     throughout the class reference.
 
 Offline translation and testing