-
Notifications
You must be signed in to change notification settings - Fork 86
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
Add code style and github issue guides #463
Conversation
Codecov Report
@@ Coverage Diff @@
## master #463 +/- ##
=======================================
Coverage 98.42% 98.42%
=======================================
Files 104 104
Lines 3427 3427
=======================================
Hits 3373 3373
Misses 54 54 Continue to review full report at Codecov.
|
contributing.md
Outdated
* Make the title as short and descriptive as possible. | ||
* Make sure the body is concise and gets to the point quickly. | ||
* Check for duplicates before filing. | ||
* For bugs, a good general outline is: problem summary, root cause if known, symptoms and scope, proposed solution(s), and next steps. |
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.
Could also be useful to provide minimal steps to reproduce bug, if possible?
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 good point!
contributing.md
Outdated
* Keep things simple. Any complexity must be justified in order to pass code review. | ||
* Be aware that while we love fancy python magic, there's usually a simpler solution which is easier to understand! | ||
* Make PRs as small as possible! Consider breaking your large changes into separate PRs. This will make code review easier, quicker, less bug-prone and more effective. | ||
* In the name of every branch you create, include your initials and the associated issue number if applicable. |
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.
Is there a particular format we want to enforce for this? I know you usually end up doing initials_pr#_moredescription or something along those lines?
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.
Hmm, on further reflection, I think the branch should include an issue number when relevant, but other than that, I'm down with whatever, don't have a strong opinion haha. Yes, personally, I like to do <initials>_<issue number>_<short description>
.
Ok if I update this to say "In the name of every branch you create, include the associated issue number if applicable" ?
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.
Yup, sounds good :)
This could be a tiny thing but what do you think about choosing a consistent tense for changelog items? Just going through the changelog right now for the release, and thought it'd be nice to have some consistency there! |
contributing.md
Outdated
* If your changes alter the following please fix them as well: | ||
* Docstrings - if your changes render docstrings invalid | ||
* API changes - if you change the API update `docs/source/api_reference.rst` | ||
* Documentation - run the documentation notebooks locally to ensure everything is logical and works as intended | ||
|
||
* Update the "Future Release" section of the changelog (`docs/source/changelog.rst`) to include your pull request. Add a description of your PR to the subsection that most closely matches your contribution: | ||
* Update the "Future Release" section of the changelog (`docs/source/changelog.rst`) to include an entry for your pull request. Write your entry in past tense, i.e. "added fizzbuzz impl." Add a description of your PR to the subsection that most closely matches your contribution: |
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.
@angela97lin FYI
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.
Does this seem ok?
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.
Yup, looks great :D
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.
looks good. only one comment on something to add
contributing.md
Outdated
* If your changes alter the following please fix them as well: | ||
* Docstrings - if your changes render docstrings invalid | ||
* API changes - if you change the API update `docs/source/api_reference.rst` | ||
* Documentation - run the documentation notebooks locally to ensure everything is logical and works as intended | ||
|
||
* Update the "Future Release" section of the changelog (`docs/source/changelog.rst`) to include your pull request. Add a description of your PR to the subsection that most closely matches your contribution: | ||
* Update the "Future Release" section of the changelog (`docs/source/changelog.rst`) to include an entry for your pull request. Write your entry in past tense, i.e. "added fizzbuzz impl." Add a description of your PR to the subsection that most closely matches your contribution: |
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.
can we added info about how/when they should document breaking changes in the changelog?
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.
Done!
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.
🚢
Updated PR to address comments :)
No description provided.