Cleanup various repository documentation files

- Reformat logo license as a plain text file.
- Fix outdated links or references to SFC or Visual Script.
- Tweak contents of `CONTRIBUTING.md` to highlight contributor docs more
  prominently, and make it easier to parse.
- Tweak formatting and contents in `thirdparty/README.md` for consistency.

Author: akien-mga

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -59,7 +59,7 @@ body:
       - A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the `.godot` folder in the archive (but keep `project.godot`).
       - Required, unless the reproduction steps are trivial and don't require any project files to be followed. In this case, write "N/A" in the field.
       - Drag and drop a ZIP archive to upload it. **Do not select another field until the project is done uploading.**
-      - **Note for C# users:** If your issue is *not* Mono-specific, please upload a minimal reproduction project written in GDScript or VisualScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a Mono setup available.
+      - **Note for C# users:** If your issue is *not* C#-specific, please upload a minimal reproduction project written in GDScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a .NET setup available.
       - **If you've been asked by a maintainer to upload a minimal reproduction project, you *must* do so within 7 days.** Otherwise, your bug report will be closed as it'll be considered too difficult to diagnose.
   validations:
     required: true

CONTRIBUTING.md

@@ -1,28 +1,44 @@
-# How to contribute efficiently
+# Contributors guidelines
+
+This document summarizes the most important points for people interested in
+contributing to Godot, especially via bug reports or pull requests.
+
+The Godot documentation has a dedicated [Contributing section](https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html)
+which details these points and more, and is a recommended read.
 
 ## Table of contents
 
 - [Reporting bugs](#reporting-bugs)
 - [Proposing features or improvements](#proposing-features-or-improvements)
 - [Contributing pull requests](#contributing-pull-requests)
-- [Contributing to Godot's translation](#contributing-to-godots-translation)
+- [Contributing to Godot translations](#contributing-to-godot-translations)
 - [Communicating with developers](#communicating-with-developers)
 
 ## Reporting bugs
 
 Report bugs [here](https://github.com/godotengine/godot/issues/new?assignees=&labels=&template=bug_report.yml).
 Please follow the instructions in the template when you do.
 
+Notably, please include a Minimal Reproduction Project (MRP), which is a small
+Godot project which reproduces the issue, with no unnecessary files included.
+Be sure to not include the `.godot` folder in the archive to save space.
+
+Make sure that the bug you are experiencing is reproducible in the latest Godot
+releases. You can find an overview of all Godot releases [on the website](https://godotengine.org/download/archive/)
+to confirm whether your current version is the latest one. It's worth testing
+against both the latest stable release and the latest dev snapshot for the next
+Godot release.
+
+If you run into a bug which wasn't present in an earlier Godot version (what we
+call a _regression_), please mention it and clarify which versions you tested
+(both the one(s) working and the one(s) exhibiting the bug).
+
 ## Proposing features or improvements
 
-**Since August 2019, the main issue tracker no longer accepts feature proposals.**
-Instead, head to the [Godot Proposals repository](https://github.com/godotengine/godot-proposals)
-and follow the instructions in the README file. High-quality feature proposals
-are more likely to be well-received by the maintainers and community, so do
-your best :)
+**The main issue tracker is for bug reports and does not accept feature proposals.**
 
-See [this article](https://godotengine.org/article/introducing-godot-proposals-repository)
-for detailed rationale on this change.
+Instead, head to the [Godot Proposals repository](https://github.com/godotengine/godot-proposals)
+and follow the instructions in the README file and issue template.
 
 ## Contributing pull requests
 
@@ -39,80 +55,41 @@ Similar rules can be applied when contributing bug fixes - it's always best to
 discuss the implementation in the bug report first if you are not 100% about
 what would be the best fix.
 
-[This blog post](https://godotengine.org/article/will-your-contribution-be-merged-heres-how-tell)
-outlines the process used by core developers when assessing PRs. We strongly
-recommend that you have a look at it to know what's important to take into
-account for a PR to be considered for merging.
+You can refer to the [Pull request review process](https://docs.godotengine.org/en/latest/contributing/workflow/pr_review_guidelines.html)
+for insights into the intended lifecycle of pull requests. This should help you
+ensure that your pull request fulfills the requirements.
 
 In addition to the following tips, also take a look at the
 [Engine development guide](https://docs.godotengine.org/en/latest/contributing/development/index.html)
 for an introduction to developing on Godot.
 
 The [Contributing docs](https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html)
 also have important information on the [PR workflow](https://docs.godotengine.org/en/latest/contributing/workflow/pr_workflow.html)
-and the [code style](https://docs.godotengine.org/en/latest/contributing/development/code_style_guidelines.html) we use.
-
-### Document your changes
-
-If your pull request adds methods, properties or signals that are exposed to
-scripting APIs, you **must** update the class reference to document those.
-This is to ensure the documentation coverage doesn't decrease as contributions
-are merged.
-
-[Update documentation XML files](https://docs.godotengine.org/en/latest/contributing/documentation/updating_the_class_reference.html#updating-class-reference-when-working-on-the-engine)
-using your compiled binary, then fill in the descriptions.
-Follow the style guide described in the
-[Writing guidelines](https://docs.godotengine.org/en/latest/contributing/documentation/docs_writing_guidelines.html).
-
-If your pull request modifies parts of the code in a non-obvious way, make sure
-to add comments in the code as well. This helps other people understand the
-change without having to look at `git blame`.
-
-### Write unit tests
+(with a helpful guide for Git usage), and our [Code style guidelines](https://docs.godotengine.org/en/latest/contributing/development/code_style_guidelines.html)
+which all contributions need to follow.
 
-When fixing a bug or contributing a new feature, we recommend including unit
-tests in the same commit as the rest of the pull request. Unit tests are pieces
-of code that compare the output to a predetermined *expected result* to detect
-regressions. Tests are compiled and run on GitHub Actions for every commit and
-pull request.
-
-Pull requests that include tests are more likely to be merged, since we can have
-greater confidence in them not being the target of regressions in the future.
-
-For bugs, the unit tests should cover the functionality that was previously
-broken. If done well, this ensures regressions won't appear in the future
-again. For new features, the unit tests should cover the newly added
-functionality, testing both the "success" and "expected failure" cases if
-applicable.
-
-Feel free to contribute standalone pull requests to add new tests or improve
-existing tests as well.
-
-See [Unit testing](https://docs.godotengine.org/en/latest/contributing/development/core_and_modules/unit_testing.html)
-for information on writing tests in Godot's C++ codebase.
-
-### Be nice to the Git history
+### Be mindful of your commits
 
 Try to make simple PRs that handle one specific topic. Just like for reporting
 issues, it's better to open 3 different PRs that each address a different issue
-than one big PR with three commits.
+than one big PR with three commits. This makes it easier to review, approve, and
+merge the changes independently.
 
 When updating your fork with upstream changes, please use ``git pull --rebase``
 to avoid creating "merge commits". Those commits unnecessarily pollute the git
 history when coming from PRs.
 
 Also try to make commits that bring the engine from one stable state to another
 stable state, i.e. if your first commit has a bug that you fixed in the second
-commit, try to merge them together before making your pull request (see ``git
-rebase -i`` and relevant help about rebasing or amending commits on the
-Internet).
-
-This [Git style guide](https://github.com/agis-/git-style-guide) has some
-good practices to have in mind.
+commit, try to merge them together before making your pull request. This
+includes fixing build issues or typos, adding documentation, etc.
 
 See our [PR workflow](https://docs.godotengine.org/en/latest/contributing/workflow/pr_workflow.html)
 documentation for tips on using Git, amending commits and rebasing branches.
 
+This [Git style guide](https://github.com/agis-/git-style-guide) also has some
+good practices to have in mind.
+
 ### Format your commit messages with readability in mind
 
 The way you format your commit messages is quite important to ensure that the
@@ -121,12 +98,25 @@ message is formatted as a short title (first line) and an extended description
 (everything after the first line and an empty separation line).
 
 The short title is the most important part, as it is what will appear in the
-`shortlog` changelog (one line per commit, so no description shown) or in the
-GitHub interface unless you click the "expand" button. As the name says, try to
-keep that first line under 72 characters. It should describe what the commit
-does globally, while details would go in the description. Typically, if you
-can't keep the title short because you have too much stuff to mention, it means
-you should probably split your changes in several commits :)
+changelog or in the GitHub interface unless you click the "expand" button.
+Try to keep that first line under 72 characters, but you can go slightly above
+if necessary to keep the sentence clear.
+
+It should be written in English, starting with a capital letter, and usually
+with a verb in imperative form. A typical bugfix would start with "Fix", while
+the addition of a new feature would start with "Add". A prefix can be added to
+specify the engine area affected by the commit. Some examples:
+
+- Add C# iOS support
+- Show doc tooltips when hovering properties in the theme editor
+- Fix GLES3 instanced rendering color and custom data defaults
+- Core: Fix `Object::has_method()` for script static methods
+
+If your commit fixes a reported issue, please include it in the _description_
+of the commit (not in the title) using one of the
+[GitHub closing keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
+such as "Fixes #1234". This will cause the issue to be closed automatically if
+the PR is merged.
 
 Here's an example of a well-formatted commit message (note how the extended
 description is also manually wrapped at 80 chars for readability):
@@ -142,23 +132,59 @@ By fixing the regulation system via an added binding to the internal feature,
 this commit now ensures that Godot will not go past the ebullition temperature
 of cooking oil under normal atmospheric conditions.
 
-Fixes #1789, long live the Realm!
+Fixes #1340.
 ```
 
 **Note:** When using the GitHub online editor or its drag-and-drop
 feature, *please* edit the commit title to something meaningful. Commits named
 "Update my_file.cpp" won't be accepted.
 
-## Contributing to Godot's translation
+### Document your changes
+
+If your pull request adds methods, properties or signals that are exposed to
+scripting APIs, you **must** update the class reference to document those.
+This is to ensure the documentation coverage doesn't decrease as contributions
+are merged.
+
+[Update documentation XML files](https://docs.godotengine.org/en/latest/contributing/documentation/updating_the_class_reference.html)
+using your compiled binary, then fill in the descriptions.
+Follow the style guide described in the
+[Documentation writing guidelines](https://docs.godotengine.org/en/latest/contributing/documentation/docs_writing_guidelines.html).
+
+If your pull request modifies parts of the code in a non-obvious way, make sure
+to add comments in the code as well. This helps other people understand the
+change without having to dive into the Git history.
+
+### Write unit tests
+
+When fixing a bug or contributing a new feature, we recommend including unit
+tests in the same commit as the rest of the pull request. Unit tests are pieces
+of code that compare the output to a predetermined *expected result* to detect
+regressions. Tests are compiled and run on GitHub Actions for every commit and
+pull request.
+
+Pull requests that include tests are more likely to be merged, since we can have
+greater confidence in them not being the target of regressions in the future.
+
+For bugs, the unit tests should cover the functionality that was previously
+broken. If done well, this ensures regressions won't appear in the future
+again. For new features, the unit tests should cover the newly added
+functionality, testing both the "success" and "expected failure" cases if
+applicable.
+
+Feel free to contribute standalone pull requests to add new tests or improve
+existing tests as well.
+
+See [Unit testing](https://docs.godotengine.org/en/latest/contributing/development/core_and_modules/unit_testing.html)
+for information on writing tests in Godot's C++ codebase.
+
+## Contributing to Godot translations
 
-You can contribute to Godot's translation from the [Hosted
-Weblate](https://hosted.weblate.org/projects/godot-engine/godot), an open
-source and web-based translation platform. Please refer to the [translation
-readme](editor/translations/README.md) for more information.
+You can contribute to Godot translations on [Hosted Weblate](https://hosted.weblate.org/projects/godot-engine/),
+an open source and web-based translation platform.
 
-You can also help translate [Godot's
-documentation](https://hosted.weblate.org/projects/godot-engine/godot-docs/)
-on Weblate.
+Please refer to our [editor and documentation localization guidelines](https://docs.godotengine.org/en/latest/contributing/documentation/editor_and_docs_localization.html)
+for an overview of the translation resources and what they correspond to.
 
 ## Communicating with developers
 
@@ -171,15 +197,13 @@ or a bug you want to fix), the following channels can be used:
 
 - [Godot Contributors Chat](https://chat.godotengine.org): You will
   find most core developers there, so it's the go-to platform for direct chat
-  about Godot Engine development. Feel free to start discussing something there
-  to get some early feedback before writing up a detailed proposal in a GitHub
-  issue.
+  about Godot Engine development. Browse the [Directory](https://chat.godotengine.org/directory/channels)
+  for an overview of public channels focusing on various engine areas which you
+  might be interested in.
 - [Bug tracker](https://github.com/godotengine/godot/issues): If there is an
-  existing issue about a topic you want to discuss, just add a comment to it -
-  many developers watch the repository and will get a notification. You can
-  also create a new issue - please keep in mind to create issues only to
-  discuss quite specific points about the development, and not general user
-  feedback or support requests.
+  existing issue about a topic you want to discuss, you can participate directly.
+  If not, you can open a new issue. Please mind the guidelines outlined above
+  for bug reporting.
 - [Feature proposals](https://github.com/godotengine/godot-proposals/issues):
   To propose a new feature, we have a dedicated issue tracker for that. Don't
   hesitate to start by talking about your idea on the Godot Contributors Chat

COPYRIGHT.txt

@@ -383,7 +383,7 @@ License: Expat
 Files: ./thirdparty/noise/FastNoiseLite.h
 Comment: FastNoise Lite
 Copyright: 2020, Jordan Peck and contributors
-License: MIT
+License: Expat
 
 Files: ./thirdparty/misc/pcg.cpp
  ./thirdparty/misc/pcg.h
@@ -428,7 +428,7 @@ License: BSD-2-clause
 Files: ./thirdparty/msdfgen/
 Comment: Multi-channel signed distance field generator
 Copyright: 2016-2022, Viktor Chlumsky
-License: MIT
+License: Expat
 
 Files: ./thirdparty/nvapi/nvapi_minimal.h
 Comment: Stripped down version of "nvapi.h" from the NVIDIA NVAPI SDK

LOGO_LICENSE.md

@@ -0,0 +1,5 @@
+Godot Engine Logo
+Copyright (c) 2017 Andrea Calabró
+
+This work is licensed under the Creative Commons Attribution 4.0 International
+license (CC BY 4.0 International): https://creativecommons.org/licenses/by/4.0/

LOGO_LICENSE.txt

@@ -10,25 +10,26 @@
 
 **[Godot Engine](https://godotengine.org) is a feature-packed, cross-platform
 game engine to create 2D and 3D games from a unified interface.** It provides a
-comprehensive set of [common tools](https://godotengine.org/features), so that users can focus on making games
-without having to reinvent the wheel. Games can be exported with one click to a
-number of platforms, including the major desktop platforms (Linux, macOS,
-Windows), mobile platforms (Android, iOS), as well as Web-based platforms
-and [consoles](https://docs.godotengine.org/en/latest/tutorials/platform/consoles.html).
+comprehensive set of [common tools](https://godotengine.org/features), so that
+users can focus on making games without having to reinvent the wheel. Games can
+be exported with one click to a number of platforms, including the major desktop
+platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), as well as
+Web-based platforms and [consoles](https://docs.godotengine.org/en/latest/tutorials/platform/consoles.html).
 
 ## Free, open source and community-driven
 
 Godot is completely free and open source under the very permissive [MIT license](https://godotengine.org/license).
 No strings attached, no royalties, nothing. The users' games are theirs, down
 to the last line of engine code. Godot's development is fully independent and
 community-driven, empowering users to help shape their engine to match their
-expectations. It is supported by the [Software Freedom Conservancy](https://sfconservancy.org/)
+expectations. It is supported by the [Godot Foundation](https://godot.foundation/)
 not-for-profit.
 
 Before being open sourced in [February 2014](https://github.com/godotengine/godot/commit/0b806ee0fc9097fa7bda7ac0109191c9c5e0a1ac),
 Godot had been developed by [Juan Linietsky](https://github.com/reduz) and
-[Ariel Manzur](https://github.com/punto-) (both still maintaining the project) for several
-years as an in-house engine, used to publish several work-for-hire titles.
+[Ariel Manzur](https://github.com/punto-) (both still maintaining the project)
+for several years as an in-house engine, used to publish several work-for-hire
+titles.
 
 ![Screenshot of a 3D scene in the Godot Engine editor](https://raw.githubusercontent.com/godotengine/godot-design/master/screenshots/editor_tps_demo_1920x1080.jpg)
 
@@ -37,7 +38,7 @@ years as an in-house engine, used to publish several work-for-hire titles.
 ### Binary downloads
 
 Official binaries for the Godot editor and the export templates can be found
-[on the homepage](https://godotengine.org/download).
+[on the Godot website](https://godotengine.org/download).
 
 ### Compiling from source
 
@@ -53,6 +54,7 @@ The best way to get in touch with the core engine developers is to join the
 [Godot Contributors Chat](https://chat.godotengine.org).
 
 To get started contributing to the project, see the [contributing guide](CONTRIBUTING.md).
+This document also includes guidelines for reporting bugs.
 
 ## Documentation and demos