-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated contribution guide #753
Updated contribution guide #753
Conversation
Codecov Report
@@ Coverage Diff @@
## master #753 +/- ##
==========================================
- Coverage 96.44% 96.44% -0.01%
==========================================
Files 90 90
Lines 3459 3456 -3
Branches 788 792 +4
==========================================
- Hits 3336 3333 -3
Misses 70 70
Partials 53 53
Continue to review full report at Codecov.
|
cc90874
to
208fca7
Compare
|
||
For CSS naming we try to follow the [BEM](http://getbem.com/) methodology. Along with the naming, | ||
you should try to scope the styles in their respective components. | ||
When a reviewer starts a review, he should write a comment in the pull request stating he is doing so. For example: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can probably get rid of this, since we never do this anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should start doing this instead of removing the rule :)
|
||
#### Contributing to other people's PRs | ||
#### Contributing to other pull requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we should keep this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why we should remove it. While we don't often do it, there were at least a few times I had to actually do it, so it is still useful to be there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok cool
|
||
- Self-contained. | ||
- As short as possible and address a single issue or even a part of an issue. | ||
Consider breaking long PRs into smaller ones. | ||
Consider breaking long pull requests into smaller ones. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe remove, since we rarely do this too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nephix Thanks for pointing out, that we are not fully sticking to this rule. I think overall we are doing quite good and improving continuously.
We should stick to it and also address it in PRs (example from google)
Makes things much more transparent and faster. I would keep it and stick to the rule :)
See eg. https://medium.com/letgo/the-art-of-the-small-pull-request-303f7ef63901
The Small PR Manifesto
Our goal is to get PRs integrated onto the master branch as fast as possible. Code isn’t useful until it gets into master.
Here’s why:
- In order to make PRs easy-to-read and review, we’ll make them small.
- In order to avoid conflicts in our PRs, we’ll make them small.
- In order to handle a single responsibility in each of our PRs, we’ll make them small.
- In order to promote healthy and constructive discussion in our PRs, we’ll make them small.
- In order to make deployments small and easy to grasp in our PRs, we’ll make them small.
- In order to have fast PRs, we’ll make them small.
There are also tons of articles, which show the benefit of having small pull requests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that we don't do it is wrong. Smaller PRs are always easier to comprehend and review. The bigger a PR is the easier it becomes to miss details.
Also, this guide is not only for internal use but also for possible external contributors.
This clearly states intent and requirement and removing it might create wrong assumptions about what is acceptable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets say we do it very rarely.
And I asked whether we should remove it because it doesn't make sense to write down rules and expect others to follow them while we do what suites us
- **Ready for review**: Means that you consider your work done and it is currently waiting for a review | ||
- **Draft**: Is considered work in progress and it is not yet ready for a review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe remove, since we never adhere this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't even have those labels do we? 🤓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@taleldayekh we removed the labels and instead rely on the Draft and Ready for review feature of the Github Pull Requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I guess you set them when opening the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nephix Can we clarify here that these are not labels, but PR status in the Github PR interface. I actually adhere to this and @andrevmatos is also doing the same from what I remember.
The regular flow should be, I open a draft PR and when I am done I mark it ready for review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my experience we don't do this at all, or it's at least inconsistent.
I mostly do draft/ready for review, but I often see pull requests in ready for review with [wip]
or things like these.
I also very often receive feedback on pull requests that are in draft state.
Because of that, I asked if we should remove it or if we should talk about and align on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before removing maybe we should definitely align and discuss them. However, since discussions take time maybe it is better to clarify the original intent and keep it for now, but also add a point for discussion after everyone will be back.
208fca7
to
35ff00c
Compare
35ff00c
to
ab30f3a
Compare
|
||
## Development environment setup | ||
```html |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nephix don't we also enforce this with eslint? If this is part of the eslint configuration maybe we should remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, could be. I just left it inside because I wasn't sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, time to get rid of it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sehr gut!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some clarification is needed but in general, it looks good. Thank you very much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nephix I am approving and you can merge. We can look into the points after the holidays.
Addresses #186 and notes in iteration 22