first_steps.rst 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129
  1. .. _doc_first_steps:
  2. Contributing code
  3. -----------------
  4. The possibility to study, use, modify and redistribute modifications of the
  5. engine's source code are the fundamental rights that
  6. Godot's `MIT <https://tldrlegal.com/license/mit-license>`_ license grants you,
  7. making it `free and open source software <https://en.wikipedia.org/wiki/Free_and_open-source_software>`_.
  8. As such, everyone is entitled to modify
  9. `Godot's source code <https://github.com/godotengine/godot>`_, and send those
  10. modifications back to the upstream project in the form of a patch (a text file
  11. describing the changes in a ready-to-apply manner) or - in the modern workflow
  12. that we use - via a so-called "pull request" (PR), i.e. a proposal to directly
  13. merge one or more Git commits (patches) into the main development branch.
  14. Contributing code changes upstream has two big advantages:
  15. - Your own code will be reviewed and improved by other developers, and will be
  16. further maintained directly in the upstream project, so you won't have to
  17. reapply your own changes every time you move to a newer version. On the
  18. other hand it comes with a responsibility, as your changes have to be
  19. generic enough to be beneficial to all users, and not just your project; so
  20. in some cases it might still be relevant to keep your changes only for your
  21. own project, if they are too specific.
  22. - The whole community will benefit from your work, and other contributors will
  23. behave the same way, contributing code that will be beneficial to you. At
  24. the time of this writing, over 2,000 developers have contributed code
  25. changes to the engine!
  26. To ensure good collaboration and overall quality, the Godot developers
  27. enforce some rules for code contributions, for example regarding the style to
  28. use in the C++ code (indentation, brackets, etc.) or the Git and PR workflow.
  29. A good place to start is by searching for issues tagged as
  30. `good first issue <https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22>`_
  31. on GitHub.
  32. .. seealso:: Technical details about the PR workflow are outlined in a
  33. specific section, :ref:`doc_pr_workflow`.
  34. Details about the code style guidelines and the ``clang-format``
  35. tool used to enforce them are outlined in
  36. :ref:`doc_code_style_guidelines`.
  37. All pull requests must go through a review process before being accepted.
  38. Depending on the scope of the changes, it may take some time for a maintainer
  39. responsible for the modified part of the engine to provide their review.
  40. We value all of our contributors and ask them to be patient in the meantime,
  41. as it is expected that in an open source project like Godot, there is going to be
  42. way more contributions than people validating them.
  43. To make sure that your time and efforts aren't wasted, it is recommended to vet the idea
  44. first before implementing it and putting it for a review as a PR. To that end, Godot
  45. has a `proposal system <https://github.com/godotengine/godot-proposals>`_. Its
  46. usage is encouraged to plan changes and discuss them with the community. Implementation
  47. details can also be discussed with other contributors on the `Godot Contributors Chat <https://chat.godotengine.org/>`_.
  48. .. note:: Proposals are only required when working on an enhancement or a new feature.
  49. Bug reports are sufficient for fixing issues.
  50. Testing and reporting issues
  51. ----------------------------
  52. Another great way of contributing to the engine is to test development releases
  53. or the development branch and to report issues. It is also helpful to report
  54. issues discovered in stable releases, so that they can be fixed in
  55. the development branch and in future maintenance releases.
  56. Testing development versions
  57. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  58. To help with the testing, you have several possibilities:
  59. - Compile the engine from source yourself, following the instructions of the
  60. :ref:`Compiling <toc-devel-compiling>` page for your platform.
  61. - Test official pre-release binaries when they are announced (usually on the
  62. blog and other community platforms), such as alpha, beta and release candidate (RC) builds.
  63. - Test "trusted" unofficial builds of the development branch; just ask
  64. community members for reliable providers. Whenever possible, it's best to
  65. use official binaries or to compile yourself though, to be sure about the
  66. provenance of your binaries.
  67. As mentioned previously, it is also helpful to keep your eyes peeled for
  68. potential bugs that might still be present in the stable releases, especially
  69. when using some niche features of the engine which might get less testing by
  70. the developers.
  71. Filing an issue on GitHub
  72. ~~~~~~~~~~~~~~~~~~~~~~~~~
  73. Godot uses `GitHub's issue tracker <https://github.com/godotengine/godot/issues>`_
  74. for bug reports. When you start filing a bug report, you’ll be given a form to
  75. fill out. Please try to follow it so that all issues are consistent and provide
  76. the required information.
  77. Contributing to the documentation
  78. ---------------------------------
  79. There are two separate resources referred to as "documentation" in Godot:
  80. - **The class reference.** This is the documentation for the complete Godot API
  81. as exposed to GDScript and the other scripting languages. It can be consulted
  82. offline, directly in Godot's code editor, or online at Godot :ref:`Class Reference
  83. <doc_class_reference>`. To contribute to the class reference, you have to edit the
  84. XML file corresponding to the class and make a pull request.
  85. See :ref:`doc_updating_the_class_reference` and :ref:`doc_class_reference_primer`
  86. for more details.
  87. - **The tutorials and engine documentation and its translations.**
  88. This is the part you are reading now, which is distributed in the HTML format.
  89. Its contents are generated from plain text files in the reStructured Text
  90. (rst) format, to which you can contribute via pull requests on the
  91. `godot-docs <https://github.com/godotengine/godot-docs>`_ GitHub repository.
  92. See :ref:`doc_contributing_to_the_documentation` for more details.
  93. Contributing translations
  94. -------------------------
  95. To make Godot accessible to everyone, including users who may prefer resources
  96. in their native language instead of English, our community helps translate both
  97. the Godot editor and its documentation in many languages.
  98. See :ref:`doc_editor_and_docs_localization` for more details.