You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,7 +63,7 @@ Brainbot labs Establishment have appointed a **data protection officer (DPO)** s
63
63
64
64
**Data handling within the Raiden team**
65
65
- The DPO or his deputy provides the data to the respective developer responsible for analyzing the data.
66
-
- After the analysis the DPO or his deputy will ensure that the data will be deleted from the computers used for the analysis as well as from any email server used by brainbot labs Establishment to forward the information.
66
+
- After the analysis, the DPO or his deputy will ensure that the data will be deleted from the computers used for the analysis as well as from any email server used by brainbot labs Establishment to forward the information.
67
67
68
68
**Personal data collected**
69
69
Due to the fact that the user chooses the content of the files and the databases sent to brainbot labs Establishment, the personal data contained lies in the responsibility of the user who is submitting the data. However, if the user chooses to send standard log-files generated by the Raiden client the personal data will typically comprise:
@@ -102,11 +102,11 @@ When you make a PR that's not ready for a review, open a Draft PR. To open a Dra
102
102
103
103
### Pull Request Reviews
104
104
105
-
It is the responsibility of the author to ask for at least one person to review their Pull Request. That person should know the area of the code being changed. If the chosen reviwer does not feel confident in the review, they can then ask for someone else to additionally look at the code.
105
+
It is the responsibility of the author to ask for at least one person to review their Pull Request. That person should know the area of the code being changed. If the chosen reviewer does not feel confident in the review, they can then ask for someone else to additionally look at the code.
106
106
107
107
All the developers in the team should perform Pull Request reviews. Make it a habit to check [this](https://github.com/raiden-network/raiden/pulls?q=is%3Apr+is%3Aopen+label%3A%22dev%3A+Please+Review%22) link often to help your fellow colleagues who have PRs open pending for review.
108
108
109
-
We have a lot of tools that automatically check the quality of the code (flake8, mypy, pylint). All these are automatically ran by the CI. Therefore fixes related to linting are not part of PR reviews. Additionally reviewers are encouraged to not be nitpicky about the suggested changes they ask from the PR author. If something is indeed nitpicky then the reviewer is encouraged to state it beforehand. Example:
109
+
We have a lot of tools that automatically check the quality of the code (flake8, mypy, pylint). All these are automatically ran by the CI. Therefore fixes related to linting are not part of PR reviews. Additionally, reviewers are encouraged to not be nitpicky about the suggested changes they ask from the PR author. If something is indeed nitpicky then the reviewer is encouraged to state it beforehand. Example:
110
110
111
111
> nitpick: I don't really think XYZ makes sense here. If possible it would be nice to have it changed to KLM
112
112
@@ -212,7 +212,7 @@ tests to run, just use the appropriate directory.
212
212
For a detailed explanation of the different types of tests, see the
213
213
[test suite section](#test-suite) below.
214
214
215
-
### Commiting Rules
215
+
### Committing Rules
216
216
217
217
For an exhaustive guide read [this](http://chris.beams.io/posts/git-commit/)
218
218
guide. It's all really good advice. Some rules that you should always follow though are:
0 commit comments