|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Thank you for your interest in contributing to Winding Tree! ❤️🌳 |
| 4 | + |
| 5 | +Definitions for "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" are covered in [RFC2119](https://datatracker.ietf.org/doc/html/rfc2119). |
| 6 | + |
| 7 | +# Using the issue tracker |
| 8 | + |
| 9 | +The issue tracker is the preferred channel for [bug reports](#bug-reports), [features requests](#feature-requests), and [submitting pull requests](#submitting-pull-requests), but please respect the following restrictions: |
| 10 | + |
| 11 | +- Please **do not** use the issue tracker for personal support requests (use [Discord](https://discord.gg/wHXzyrC6vA)). |
| 12 | +- Please **do not** derail or troll issues. Keep the discussion on topic and respect the opinion of others. |
| 13 | + |
| 14 | +## Bug reports |
| 15 | + |
| 16 | +A bug is a _demonstrable problem_ that is caused by code in the repository. Good bug reports are extremely helpful - thank you! |
| 17 | + |
| 18 | +Guidelines for bug reports: |
| 19 | + |
| 20 | +1. **Use the GitHub issue search** - check if the issue has _already_ been reported. |
| 21 | +2. **Check if the issue has been fixed** - try to reproduce it using the latest `main` branch in the repository. |
| 22 | +3. **Isolate the problem** - create a reduced test case and a live example. |
| 23 | + |
| 24 | +A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs. |
| 25 | + |
| 26 | +Example: |
| 27 | + |
| 28 | +> Short and descriptive example bug report title |
| 29 | +> |
| 30 | +> A summary of the issue and the browser/OS environment in which it occurs. If suitable, include the steps required to reproduce the bug. |
| 31 | +> |
| 32 | +> 1. This is the first step |
| 33 | +> 2. This is the second step |
| 34 | +> 3. Further steps, etc. |
| 35 | +> <url> - a link to the reduced test case |
| 36 | +> |
| 37 | +> Any other information you want to share that is relevant to the issue being reported. This might include the lines of code that you have identified as causing the bug, and potential solutions (and your opinions on their merits). |
| 38 | +
|
| 39 | +## Feature requests |
| 40 | + |
| 41 | +Feature requests are welcome, but take a moment to find out whether your idea fits with the scope and aims of the project. It's up to _you_ to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible. |
| 42 | + |
| 43 | +# Engineering standards |
| 44 | + |
| 45 | +All ongoing development for an upcoming release gets committed to the **`main`** branch. The `main` branch technically serves as the "development" branch as well, but all code that is committed to the `main` branch should be considered _stable_. |
| 46 | + |
| 47 | +You should ensure any changes are clear and well-documented. When we say "well-documented": |
| 48 | + |
| 49 | +- If the changes include code, ensure all additional code has documentation in and around it. This includes documenting the definitions of functions, statements in code, sections. |
| 50 | +- The most helpful code comments explain why, establish context, or efficiently summarize how. Avoid simply repeating details from declarations. When in doubt, favour overexplaining to underexplaining. |
| 51 | +- Code comments should be consistent with their language conventions. For example, please use [JSDoc](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html) for TypeScript/JavaScript, or [NatSpec](https://docs.soliditylang.org/en/v0.8.13/natspec-format.html) for Solidity. |
| 52 | +- Any new features must have a corresponding **doc** [issue](#using-the-issue-tracker) raised to ensure the creation of user documentation. |
| 53 | +- Commented-out code **shall not** submitted. If the code does not need to be used anymore, please remove it. |
| 54 | +- While `TODO` comments are frowned upon, every now and then it is OK to put a `TODO` to note that a particular section of code needs to be worked on in the future. However, it is also known that "TODOs" often do not get worked on, and as such, it is more likely you will be asked to complete the TODO at the time you submit it. |
| 55 | +- Write clear, descriptive [commit messages](#commit-messages). |
| 56 | + |
| 57 | +Please provide unit tests with your code if possible (**shall be provided for smart-contracts**). If unable to provide a unit test, please provide an explanation as to why in your pull request, including a description of the steps used to manually verify the changes. |
| 58 | + |
| 59 | +You _should_ make atomic changes, as these are preferred over bulk changes of everything. Each commit tells a story about what changes are being made. This makes it easier to identify when a bug is introduced into the codebase, and as such makes it easier to fix. |
| 60 | + |
| 61 | +All commits shall either be rebased in atomic order or squashed (if the squashed commit is considered atomic). Merge commits shall not be accepted. All conflicts must be resolved prior to pushing changes. |
| 62 | + |
| 63 | +**All pull requests should be made to the `main` branch**. All PRs to `main` branch shall be subject to review. Repository restrictions shall be setup to prohibit the merging of code that has not been reviewed. |
| 64 | + |
| 65 | +## Commit Messages |
| 66 | + |
| 67 | +Commit messages **must** be in accordance with [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#specification). See [why we use conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#why-use-conventional-commits). |
| 68 | + |
| 69 | +## Submitting Pull Requests |
| 70 | + |
| 71 | +Good pull requests - patches, improvements, new features - are a fantastic help! They should remain focused in scope and avoid containing unrelated commits. |
| 72 | + |
| 73 | +**Please ask first** before embarking on any significant pull request (e.g. implementing features, refactoring code, porting to a different language), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project. You can find us in [discord](https://discord.gg/Te8YV373Ss) and we will be happy to hear your suggestions. |
| 74 | + |
| 75 | +Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc) and any other requirements (such as test coverage). |
| 76 | + |
| 77 | +Follow this process if you'd like your work considered for inclusion in the project: |
| 78 | + |
| 79 | +1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, and configure the remotes: |
| 80 | + |
| 81 | +```bash |
| 82 | +# Clone your fork of the repo into the current directory |
| 83 | +git clone https://github.com/<your-username>/<repo-name> |
| 84 | +# Navigate to the newly cloned directory |
| 85 | +cd <repo-name> |
| 86 | +# Assign the original repo to a remote called "upstream" |
| 87 | +git remote add upstream https://github.com/<upstream-owner>/<repo-name> |
| 88 | +``` |
| 89 | + |
| 90 | +2. If you cloned a while ago, get the latest changes from upstream: |
| 91 | + |
| 92 | +```bash |
| 93 | +git checkout <dev-branch> |
| 94 | +git pull upstream <dev-branch> |
| 95 | +``` |
| 96 | + |
| 97 | +3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix: |
| 98 | + |
| 99 | +```bash |
| 100 | +git checkout -b <topic-branch-name> |
| 101 | +``` |
| 102 | + |
| 103 | +4. Commit your changes in logical chunks. Ensure that these [git commit message guidelines](#commit-messages) are followed or your code is unlikely to be merged into the `main`. |
| 104 | + |
| 105 | +5. Locally merge (or rebase) the upstream development branch (`main`) into your topic branch: |
| 106 | + |
| 107 | +```bash |
| 108 | +git pull [--rebase] upstream <dev-branch> |
| 109 | +``` |
| 110 | + |
| 111 | +6. Push your topic branch up to your fork: |
| 112 | + |
| 113 | +```bash |
| 114 | +git push origin <topic-branch-name> |
| 115 | +``` |
| 116 | + |
| 117 | +7. [Open a pull request](https://help.github.com/articles/using-pull-requests/) with a clear title and description. |
| 118 | + |
| 119 | +**IMPORTANT**: By submitting a patch, you agree to allow the project owner to license your work under the same license as that used by the project. |
| 120 | + |
| 121 | +# Releases & Versioning |
| 122 | + |
| 123 | +Overall, release tags should attempt to follow the [semantic versioning](https://semver.org/) scheme. Tagging of releases shall be handled by repository maintainers. |
| 124 | + |
| 125 | +# CI/CD Environments |
| 126 | + |
| 127 | +WindingTree makes use of GitHub actions to automate testing, deployment and release cycles. |
| 128 | + |
| 129 | +## Development |
| 130 | + |
| 131 | +The development environment shall deploy on all merged PRs into the `main` branch. |
| 132 | + |
| 133 | +## Production |
| 134 | + |
| 135 | +The production environment shall deploy on all tagged releases from the `main` branch. |
0 commit comments