oceanprotocol/docs
1
0
Fork 0
mirror of https://github.com/oceanprotocol/docs.git synced 2024-11-26 19:49:26 +01:00
Code Releases Activity

more precise branching

Browse Source
This commit is contained in:
Matthias Kretschmann 2021-01-15 09:29:40 +01:00
parent a288e846f2
commit 523a44dd40
Signed by: m
GPG Key ID: 606EEEF3C479A91F
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/contributing.md
View File

@ -33,7 +33,7 @@ Before you start coding right away, please follow those basic guidelines:
A typical code contribution in any Ocean Protocol repository would go as follows: A typical code contribution in any Ocean Protocol repository would go as follows:
1. As an external developer, fork the respective repo and push to your own fork. Ocean core developers push directly on the repo under `oceanprotocol` org. 1. As an external developer, fork the respective repo and push to your own fork. Ocean core developers push directly on the repo under `oceanprotocol` org.
2. We follow [Trunk Based Development](https://trunkbaseddevelopment.com) so work in feature branches. For naming use `feature/your-feature` or `feature/23` for new features and `fix/your-fix` or `fix/23` for bug fixes, referring to the issue number. 2. We follow [Trunk Based Development](https://trunkbaseddevelopment.com) so work in feature branches, branched off from the `main` branch. For naming use `feature/your-feature` or `feature/23` for new features and `fix/your-fix` or `fix/23` for bug fixes, referring to the issue number.
3. To get visibility and Continuous Integration feedback as early as possible, open your Pull Request as a `Draft`. 3. To get visibility and Continuous Integration feedback as early as possible, open your Pull Request as a `Draft`.
4. Give it a meaningful title, and at least link to the respective issue in the Pull Request description, like `Fixes #23`. Describe your changes, mention things for reviewers to look out for, and for UI changes screenshots and videos are helpful. 4. Give it a meaningful title, and at least link to the respective issue in the Pull Request description, like `Fixes #23`. Describe your changes, mention things for reviewers to look out for, and for UI changes screenshots and videos are helpful.
5. Once your Pull Request is ready, mark it as `Ready for Review`, in most repositories code owners are automatically notified and asked for review. 5. Once your Pull Request is ready, mark it as `Ready for Review`, in most repositories code owners are automatically notified and asked for review.