VIM-4977: JAM - Updated PR template proposal#125
Conversation
See build details on CircleCI Generated by 🚫 danger |
kevinzetterstrom
left a comment
There was a problem hiding this comment.
This is really great 😄 and I can't wait to start using this everywhere for increased clarity and ease of use. I just have a few small comments.
| @@ -0,0 +1,36 @@ | |||
| #### Ticket (For Vimeo staff only) | |||
There was a problem hiding this comment.
As the first line of the template, do you think non-Vimeo Staff will see this and assume the entire template doesn't apply to them rather than just this section? I have gotten that feeling before when it's been included as the second line as it is within the Android public repos, like this. I'm not sure what the best approach would be to solve this if it is a problem. Perhaps reordering the section down further? - But I like having the ticket number at the top. Perhaps better copy?
|
|
||
| - *Outline the goals of the PR in technical terms. If this branch fixes a bug, state what caused the bug.* | ||
|
|
||
| #### Pull Request Checklist |
There was a problem hiding this comment.
I think it makes sense for Issue Summary to immediately precede Implementation Summary. Pull Request Checklist may make sense to move up or down. I almost feel like moving it up would be better, so reviewers immediately know the state of the PR before investing time reading summaries. What do you think?
|
|
||
| #### Implementation Summary | ||
|
|
||
| - *Identify the core components that were added or changed, and briefly state the reasoning behind these changes.* |
|
|
||
| - *Provide the order in which files or components should be reviewed.* | ||
|
|
||
| - *List general components of the application that this PR will affect.* |
There was a problem hiding this comment.
Not sure the term application applies in this sense, since this is a library itself. Perhaps List general components that this PR will affect. would be better suited.
|
|
||
| - *Identify necessary conditions for testing (e.g. logged out, bad connectivity).* | ||
|
|
||
| - *If a special type of account is needed for log in, contact a developer privately to provide credentials. |
|
Thank you for the helpful feedback @kevinzetterstrom! @ghking @jenniferlim @jasonhawkins @mikew-personal @supperspidey - please take a look at this PR as a proposed template for our public repos. Also please take a glance at the original PR for private repos to confirm new changes are ok. https://github.vimeows.com/MobileApps/Vimeo-iOS/pull/1259 Once we are able to sign off, I'll update all public and private repos. |
|
cc: @fyell |
| #### Pull Request Checklist | ||
|
|
||
| - [ ] Resolved any merge conflicts | ||
| - [ ] No build errors or warnings are introduced |
There was a problem hiding this comment.
Can these 2 be assumed from CI passing?
There was a problem hiding this comment.
@fyell the thought was folks shouldn't expect us to review if a build is broken or has warnings
jasonhawkins
left a comment
There was a problem hiding this comment.
I, along with these two folks –> 🔭👩🏻🔬👨🏻🔬🔬 – both highly respected in their fields – approve this pull request.
|
Looking great! @nicolelehrer. 😊 |
|
Looks fantastic to me 👍 |
Ticket
VIM-4977
Ticket Summary
(1) Update the PR template to facilitate more helpful PR descriptions from developers.
(2) Add a PR checklist for the contributor to fill in prior to requesting PR review
Pain points this is trying to solve
We'd like to identify some expectations we have for devs who don't contribute to our repos regularly by listing them in a PR checklist
Sometimes we copy and paste the ticket description (if applicable) inside Issue Summary. Instead let's translate the ticket / general issue into the technical problem we're trying to solve so we're not trying to figure this out while reading about implementation.
A reviewer should have a big picture idea of how you solved the problem, how your changes relate to each other, and what your code will affect. Let's cover these in Implementation summary and Reviewer tips.
A reviewer shouldn't have to guess if a large chunk of code was copied and pasted or was actually changed. Let's indicate when this case happens inside Reviewer tips.
Let's try to make testing as easy as possible on the reviewer.
The intent of these bullet points is not to make PR descriptions longer, but more specific while remaining concise. These bullet points should be deleted if not applicable.
Implementation Summary
Added bullet points and checklist to help remind developers to provide more specific info on a PR for the reviewer.
How to Test
N/A