CONTRIBUTING.rst 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112
  1. Introduction
  2. ============
  3. First off, thank you for considering contributing to Solana.Unity.Gum. It's people like you that will make Solana.Unity.Gum a great tool.
  4. Support questions
  5. -----------------
  6. Please don't use the issue tracker for this. The issue tracker is a tool
  7. to address bugs and feature requests in Solana.Unity.Gum itself. Use one of the
  8. following resources for questions about using Solana.Unity.Gum or issues with your
  9. own code:
  10. - The `discussions`_ page
  11. can be used to discuss a number of different questions, including support.
  12. - The email blockmountainresearch(at)protonmail.com can be used for longer term
  13. discussion or larger issues.
  14. .. _discussions: https://github.com/gumhq/Solana.Unity.Gum/discussions
  15. Reporting issues
  16. ----------------
  17. Include the following information in your post:
  18. - Describe what you expected to happen.
  19. - If possible, include a `minimal reproducible example` to help us
  20. identify the issue. This also helps check that the issue is not with
  21. your own code.
  22. - Describe what actually happened. Include the full traceback if there
  23. was an exception.
  24. - List your .NET and Solana.Unity.Gum versions. If possible, check if this
  25. issue is already fixed in the latest releases or the latest code in
  26. the repository.
  27. Submitting pull requests
  28. ------------------
  29. If there is not an open issue for what you want to submit, prefer
  30. opening one for discussion before working on a PR.
  31. You can work on any issue that doesn't have an open PR linked to it or
  32. a maintainer assigned to it. No need to ask if you can work on
  33. an issue that interests you.
  34. Include the following in your patch:
  35. - Include tests if your changes add or change code. Make sure the test
  36. fails without your changes.
  37. - Update any relevant docs pages, docstrings and/or relevant code comments.
  38. - Add an entry in ``CHANGELOG.md``. Use the same style as other
  39. entries. Also include ``.. versionchanged`` inline changelogs in
  40. relevant docstrings.
  41. First time setup
  42. ~~~~~~~~~~~~~~~~
  43. - Clone the repository.
  44. - Build it locally using your favorite IDE.
  45. - Build on top of it.
  46. Start coding
  47. ~~~~~~~~~~~~
  48. - Create a branch to identify the issue you would like to work on. If
  49. you're submitting a bug or documentation fix, branch off of the
  50. latest ".x" branch.
  51. .. code-block:: text
  52. $ git fetch origin
  53. $ git checkout -b your-branch-name origin/2.0.x
  54. If you're submitting a feature addition or change, branch off of the
  55. "main" branch.
  56. .. code-block:: text
  57. $ git fetch origin
  58. $ git checkout -b your-branch-name origin/main
  59. - Using your favorite editor, make your changes,
  60. `committing as you go`_.
  61. - Include tests that cover any code changes you make. Make sure the
  62. test fails without your patch. Run the tests as described below.
  63. - Push your commits to your fork on GitHub and
  64. `create a pull request`_. Link to the issue being addressed with
  65. ``fixes #123`` in the pull request.
  66. .. _committing as you go: https://dont-be-afraid-to-commit.readthedocs.io/en/latest/git/commandlinegit.html#commit-your-changes
  67. .. _create a pull request: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request
  68. Running the tests
  69. ~~~~~~~~~~~~~~~~~
  70. - TBD
  71. Running test coverage
  72. ~~~~~~~~~~~~~~~~~~~~~
  73. - TBD
  74. Building the docs
  75. ~~~~~~~~~~~~~~~~~
  76. - TBD