Skip to content
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

Merged
merged 1 commit into from
Dec 17, 2019

Conversation

nephix
Copy link
Contributor

@nephix nephix commented Dec 17, 2019

Addresses #186 and notes in iteration 22

@codecov
Copy link

codecov bot commented Dec 17, 2019

Codecov Report

Merging #753 into master will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            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
Flag Coverage Δ
#dapp 92.5% <ø> (-0.03%) ⬇️
#sdk 98.13% <ø> (ø) ⬆️
Impacted Files Coverage Δ
raiden-dapp/src/components/AddressInput.vue 98.83% <0%> (-0.04%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 721632b...ab30f3a. Read the comment docs.

@nephix nephix force-pushed the chore/updated-contrib-guide branch 2 times, most recently from cc90874 to 208fca7 Compare December 17, 2019 11:21

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:
Copy link
Contributor Author

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?

Copy link
Contributor

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
Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor Author

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

Copy link
Contributor

@christianbrb christianbrb Dec 17, 2019

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:

  1. In order to make PRs easy-to-read and review, we’ll make them small.
  2. In order to avoid conflicts in our PRs, we’ll make them small.
  3. In order to handle a single responsibility in each of our PRs, we’ll make them small.
  4. In order to promote healthy and constructive discussion in our PRs, we’ll make them small.
  5. In order to make deployments small and easy to grasp in our PRs, we’ll make them small.
  6. 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.

CC @andrevmatos @kelsos

Copy link
Contributor

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.

Copy link
Contributor Author

@nephix nephix Dec 17, 2019

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

@nephix nephix requested a review from kelsos December 17, 2019 11:24
@nephix nephix marked this pull request as ready for review December 17, 2019 11:24
Comment on lines +250 to +251
- **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
Copy link
Contributor Author

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

Copy link
Contributor

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? 🤓

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@nephix nephix force-pushed the chore/updated-contrib-guide branch from 208fca7 to 35ff00c Compare December 17, 2019 12:16
@nephix nephix force-pushed the chore/updated-contrib-guide branch from 35ff00c to ab30f3a Compare December 17, 2019 12:19

## Development environment setup
```html
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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 :)

Copy link
Contributor

@taleldayekh taleldayekh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sehr gut!

Copy link
Contributor

@kelsos kelsos left a 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.

Copy link
Contributor

@kelsos kelsos left a 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.

@nephix nephix merged commit a845236 into raiden-network:master Dec 17, 2019
@nephix nephix deleted the chore/updated-contrib-guide branch December 17, 2019 16:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants